When a WordPress AI chatbot gives a weak answer, the first instinct is often to rewrite its prompt. Add more instructions. Make the tone friendlier. Tell it to be accurate one more time. That work can improve how an answer sounds, but it does not settle the more important question: what is the assistant actually allowed to treat as true?
For a service business, that boundary matters. A pricing page may be current while an old article still describes a discontinued offer. A staff handbook may contain useful internal detail that should never be shown to a visitor. A salesperson may know how to explain an exception, but that does not make the exception a public policy. Better wording cannot repair an unclear source boundary.
MoonPress Chat takes the opposite approach. The product idea is to make knowledge selection and approval visible before a visitor ever sees an answer. The prompt still matters, but it sits downstream of a clearer editorial decision.
A prompt controls behavior, not reality
A system prompt is useful for setting behavior. It can tell an assistant to be concise, avoid legal conclusions, ask a follow-up question when intent is unclear, or hand a conversation to a person. Those are meaningful controls.
What a prompt cannot do by itself is identify which page contains the current policy, whether a draft answer has been reviewed, or whether an internal note is safe to expose. If the model receives contradictory or unapproved material, a carefully written prompt still leaves it choosing between competing versions.
This distinction is easy to miss because both problems appear inside the same chat window. The visitor sees one answer. Behind that answer, however, are two different systems:
- a knowledge system that decides what information is available;
- a behavior system that decides how the assistant uses that information.
Treating those as separate layers makes the assistant easier to reason about. It also gives the team a practical place to work when an answer is wrong. They can inspect the source and its approval state instead of endlessly tuning prose instructions.
Approval should be a product state
Many chat tools ask for a URL, crawl the site, and immediately make the result available to the model. That is convenient, but convenience is not the same as editorial control. A website can contain staging copy, duplicate pages, obsolete campaign landing pages, thin tag archives, and legal wording that only applies in one jurisdiction.
An approval layer turns that ambiguity into a visible workflow. A source can be discovered without being trusted. A draft answer can exist without being publishable. A person can review a piece of knowledge, edit it, approve it, or keep it out of the live assistant.
The important part is not the exact labels. A team might use discovered, reviewed, and approved; another might use draft and live. The important part is that there is a state transition a person can understand. “The crawler found it” must never silently mean “the assistant may say it.”
In the 99Legal pilot that informed MoonPress Chat, this separation was especially important because the assistant had to stay inside explicit claim boundaries. The lesson applies well beyond legal services. Any team with policies, qualifications, exclusions, or human judgment needs a deliberate line between available text and approved knowledge.
Provenance makes correction practical
An approved source set is more useful when the team can see where an answer came from. Provenance does not have to become a long citation list in every visitor message. It does need to be available to the people reviewing conversations and correcting the system.
Suppose a visitor asks whether a service is available in their area. If the answer is wrong, the useful questions are concrete: Which source did MoonPress Chat use? Was that source approved? Did two approved sources disagree? Was the visitor asking about an exception that belongs with a person?
Without provenance, the team is left with “the AI got it wrong.” With provenance, the team can repair the underlying knowledge, adjust a boundary, or add a handoff rule. The correction becomes part of an operating loop instead of a one-off prompt patch.
This also changes how teams review quality. They do not need to read every conversation looking for mysterious model behavior. They can focus on unanswered questions, low-confidence moments, handoffs, and answers tied to sources that have changed.
“I don’t know” can be the correct answer
Website chat is often judged by how often it produces an answer. That metric can reward confident guessing. A controlled assistant needs a different definition of success: give an approved answer when one exists, ask a clarifying question when that can resolve the request, and stop when the available knowledge is not enough.
Stopping does not have to feel like failure. MoonPress Chat can explain that it does not have an approved answer, preserve what the visitor already shared, and bring in a person. The visitor gets an honest next step. The team gets a clear signal that its knowledge or routing needs attention.
That next step works only when the human handoff keeps the conversation intact.
That behavior is only credible when the assistant knows its source boundary. If every crawled sentence is treated as fair game, there is little reason for it to stop. Approval creates the negative space around the answer—the information the assistant must not improvise.
A practical approval loop for WordPress teams
The first version of an approval workflow does not need a large governance program. A small WordPress team can begin with a short operating loop:
- Select the public pages that contain current, visitor-safe information.
- Exclude drafts, campaign remnants, thin archives, and internal material.
- Review the knowledge MoonPress Chat derives from those pages before launch.
- Test common questions, edge cases, and questions the site should not answer.
- Publish only after answer boundaries and handoff behavior are clear.
- Revisit sources when the website or service changes.
The key is that the loop belongs to normal website operations. When a policy page changes, its approved knowledge should be reviewed. When conversations reveal a recurring gap, the team should decide whether to add public content, add approved knowledge, or route the question to a person.
The WordPress AI chatbot plugin launch checklist turns those boundaries into a review the team can complete before publication.
What to carry into your own assistant
A clever prompt is helpful, but it does not make a reliable website assistant. Reliability starts with an explicit answer boundary that the team can inspect and maintain.
- Separate the knowledge layer from the behavior layer.
- Make approval visible; discovery is not permission.
- Keep enough provenance to diagnose and repair weak answers.
- Treat a transparent stop and human handoff as valid outcomes.
- Connect knowledge review to the way the WordPress site already changes.
That is the product principle behind MoonPress Chat: better answers begin before the chat opens, with a team deciding what the assistant is allowed to know.
