Instructions, knowledge, and tools all shape an Assistant, but they answer different questions. Instructions define behavior. Knowledge supplies approved, maintained content. Custom tools retrieve live state or perform a narrowly authorized action.
When those jobs are mixed together, an Assistant can answer a current-account question from stale documentation or call an external system for information that should have been maintained as policy. A clearer source model makes answers easier to test, govern, and hand off.
Begin with the Assistant’s scope
An OXVO Console Assistant combines instructions, connected inboxes, knowledge, tools, and operational behavior. Before adding a source, define:
the audience and supported request categories;
the topics it must not answer;
source-of-truth priority;
when to ask a clarifying question;
when to hand off;
prohibited claims and actions;
how personal or sensitive data should be treated.
Keep critical policy in one maintained source. Repeating the same rule across instructions, uploaded documents, FAQs, and tool descriptions creates conflict that is difficult to diagnose.
Use the right layer for the question
Need
Best layer
Why
Tone, scope, formatting, and handoff rules
Assistant instructions
These govern behavior across every answer
Approved product guidance, policies, procedures, or FAQs
Knowledge data
The answer comes from maintained content
Current order, subscription, entitlement, ticket, or account state
Custom tool
The answer must be read from a live system
A reversible external action
Custom tool with confirmation
The backend must authorize and execute the action
A request outside scope or unsupported by evidence
Handoff
The correct outcome is safe transfer, not invention
This separation is a design rule, not a promise that every question fits perfectly. When a request combines stable policy and live state, the Assistant may need both: knowledge for the rule and a tool for the current record.
Put stable, approved content in knowledge
Knowledge data can include website content, supported uploaded documents, and direct FAQ or answer content. Use it for information your organization approves and can maintain: product instructions, support policies, onboarding guidance, and other material that does not require a live account lookup.
Adding a source is only the beginning. Review the processing result, title, owner, accuracy, freshness, intended audience, sensitive content, duplicates, and conflicting sources. A visible source may still be pending, failed, outdated, or attached to the wrong Assistant.
Test retrieval with exact wording, paraphrased wording, ambiguous questions, an intentionally unsupported premise, and information that changed recently. The Assistant should use the right source, express uncertainty when support is missing, and hand off rather than fill a gap with a plausible answer.
Remove obsolete sources and keep one authoritative source for important rules. Reprocess or replace content after material changes according to the current workflow.
Use a custom tool for live state
A custom tool is appropriate when static content cannot answer the question because the result depends on a current record or external operation. Examples in the public OXVO documentation include reading order or subscription status, checking an entitlement or CRM record, and performing a narrowly authorized action with confirmation.
Define the tool around one job. Give it an action-oriented name and explain when it should and should not run. Use an approved HTTPS endpoint, supported request method, authentication, typed parameters, and bounded request or response templates where needed.
The receiving API—not the Assistant—must enforce authorization for the requested account and resource. A customer-provided identifier, a browser event, or a model-selected parameter is not proof of permission.
Return predictable, bounded JSON with an explicit success or error state, stable fields, only the data needed for the answer, no raw secrets, and a correlation identifier that an operator can use for support.
Start read-only and design failure on purpose
Read-only tools are easier to review because a wrong selection cannot change external state. Test them with valid and invalid parameters, authentication failure, timeout, malformed responses, missing records, and unexpected fields.
For an action tool, add explicit confirmation and backend-side authorization. Define idempotency where repeated requests could otherwise create duplicate work. Reject unknown parameters and keep the tool’s purpose narrow enough that the Assistant cannot reinterpret it as a general integration surface.
Treat tool output as untrusted data. An incorrect or compromised API can return content that influences the answer, so tool output must not override the Assistant’s governing policy.
Example: policy plus current entitlement
Consider the question: “Can this account use a particular capability?”
The general eligibility rule belongs in approved knowledge. The customer’s current entitlement belongs in a read-only tool. The Assistant can explain the rule, retrieve the live account state through the authorized backend, and state what the evidence supports.
If the request becomes “Enable it for me,” that is a different job. It requires a separately designed action tool, explicit confirmation, backend authorization, failure handling, and an audit or support trail appropriate to the operation. If those controls do not exist, the Assistant should hand off.
This model avoids two unsafe shortcuts: putting changing account data into static knowledge, or giving a broad action endpoint the job of answering ordinary policy questions.
Test the complete conversation outcome
A representative Assistant test set should include:
a normal supported question;
an ambiguous question;
a request outside scope;
outdated or conflicting knowledge;
a tool failure;
a handoff request;
an attempted instruction override;
a sensitive-account request.
Verify both the answer and the resulting conversation state. A graceful handoff with useful agent context is a successful product path, not a model failure.
Operate sources as part of the product
Assign an owner and review the Assistant after a material change to instructions, model, knowledge, tool, or connected inbox. Watch for unsupported answers, tool errors, unresolved conversations, repeated questions, handoff reasons, and source quality where those signals are available.
A simple source review can ask:
Is this information stable enough for knowledge?
Does this question require live account state?
Can the backend independently authorize the requested resource?
Is the tool read-only unless an action is genuinely required?
Are unsupported and failure cases routed to a clear handoff?
Does one maintained source own each important rule?
The best source architecture is not the one with the most documents or tools. It is the one where each question has a clear authority, each live lookup has a narrow boundary, and uncertainty produces a safe next step.
