Keep Site Context current when services change

Sentient Forms Site Context should make an AI form result easier for staff to verify. If it is vague, stale, or written like a sales page, the model may produce confident answers that no longer match the business.

The useful version is a short shared reference: what the site offers, who it serves, which facts affect routing or review, and which claims staff can check. Sentient Forms lets a WebMaster write Site Context manually or generate a starting point with Managed Execution or a configured paid, web-capable OpenRouter model. In either case, a person owns the final text.

Write for the decision, not the brand voice

Start with the form action that will use the context. A lead-routing action may need service areas and department names. A missing-information review may need the minimum facts required for a quote. A suggested reply may need the normal next step and the phrases staff use for it.

Site Context does not need a company origin story unless that story changes the decision. Replace broad claims such as “full-service partner” with facts staff can test: services offered, locations covered, request types handled, and the queue that owns each type.

Separate stable facts from changing facts

Not every fact goes stale at the same speed. Put context into two mental buckets:

Usually stable	Likely to change
Company and service terminology	Current service areas or territories
Normal request categories	Staff owners and escalation contacts
Required facts for a basic handoff	Availability, promotions, or temporary restrictions
Words the business avoids or defines carefully	Pricing, eligibility, or qualification rules

Changing facts need an owner and a review trigger. If a client launches a service, changes territory, removes an offering, or reorganizes the team, updating the website is only half the job. The context used by form actions needs the same review.

Build a compact fact sheet

A practical Site Context draft can cover six things:

1. What the organization does in one plain paragraph.
2. The current services, products, or request types relevant to the mapped forms.
3. The locations, audiences, or account types that change routing.
4. The minimum facts staff need before taking the next step.
5. The names of real queues or teams, without personal secrets or credentials.
6. A short list of claims the action must not invent.

Keep action-specific instructions in the action prompt. Site Context should hold reusable business facts, not become a pile of exceptions for every form.

Keep a source note staff can check

For each fact that affects a route, score, or reply, record where staff can confirm it. The source might be a public service page, an approved internal policy, or the name of the person who owns that rule. This does not need to become a research project. A short source note and review date are enough to expose stale context.

If you generate a starting point from public pages, check every operational claim before saving it. Web search can retrieve current pages, but it can also surface old, incomplete, or irrelevant material. OpenRouter’s web search documentation explains that search results are returned to the model for synthesis; that mechanism is useful grounding, not an approval step.

If staff cannot point to the fact behind a routing rule, the context is not ready.

Leave sensitive and private material out

Site Context is not a password manager, employee directory, contract archive, customer list, or place for private pricing logic. Do not paste credentials, secret URLs, personal data, confidential client terms, or internal material that the action does not need.

Use the same minimum-data rule for submissions. The guide to choosing fields for AI review helps keep form payloads narrow, while the official WordPress privacy guidance provides a starting point for documenting collection and sharing.

Test context with controlled examples

Before using the revised context on a live form, run a small set of examples that staff already understand:

• A normal request that should reach the expected owner.
• A request outside the current service area or offering.
• An incomplete request that should stay in human review.
• A request containing an old service name or ambiguous phrase.

Compare the result with the original submission and the source note. Write prompts staff can verify, and keep an audit trail for form review so a correction can become a context update instead of a repeated workaround.

Refresh on events, not an arbitrary calendar

A quarterly reminder can catch neglect, but business changes are the better trigger. Review Site Context when a service launches or closes, a territory changes, staff ownership moves, a qualification rule changes, or reviewers repeatedly correct the same mistake.

Record the owner, the date, and the reason for each meaningful revision. That makes it easier to roll back a bad change and explain why an action behaved differently after an update.

Measure fewer corrections

The payoff is not a longer context document. It is fewer corrected routes, fewer replies that mention an old service, less time re-explaining the business in individual prompts, and faster staff verification. Track those outcomes on a small sample before and after the update.

Start with one form action

The Sentient Forms WordPress.org listing explains the current Site Context and provider requirements. Then browse the Action Library, choose one action with a clear staff owner, and test the context against real business facts before expanding it.