Agent anatomy and ontology: how honesty becomes trust

Read this if you have an agent that sounds capable and then fails in front of a customer. The fix is not a warmer prompt. It is a matching body and world map.

Most “untrustworthy” agents are not lying on purpose. They are assembled incorrectly. The instructions describe work the session cannot do. The model offers a PDF, a live preview, or a refund action that is not turned on. A customer hears confidence, then hits a wall. That is how trust dies — one over-promise at a time.

WisebotAI treats this as an anatomy and ontology problem, not a copywriting problem. Get those two maps right and you also get the definition of an agent harness: the runtime that keeps every turn honest.

We know this from the product you already operate — Agent settings, Knowledge, the playground, Inbox, Connectors, and Channels — not from a hidden recipe. If the dashboard and the agent disagree, the customer will find it first.

Anatomy is the agent's body

Anatomy is how the agent is assembled for this conversation. Same layers, every time:

1. Safety and grounding — do not invent policy; do not ask customers for credentials.
2. Identity — the instructions you write: who the agent is, for whom, in what tone.
3. Capability map — the tools you actually enabled for this agent (see ontology below).
4. Knowledge — what this workspace has indexed, and which folders it may search.
5. Channel — the playground, the widget, and WhatsApp should not speak like a developer console.

On WisebotAI that body is rebuilt from Dashboard → Agent settings for the selected agent (confirm with the agent switcher). Instructions, model, and built-in tools apply to every channel that uses that agent after you save. A support agent and a research agent can share the same workspace and still feel like different people, because the body is per agent, not one global chatbot.

If a tool is off, the agent must not offer it. If an action is not available, the customer should hear a plain sentence — not a request for API keys or “check the dashboard.”

Ontology is the agent's world

Ontology is the session fact sheet: a yes/no map of what this agent may claim.

Not a marketing list of “we can do anything with AI.” A short world that matches Agent settings → Tools:

Knowledge search: yes
Web search: no
Create PDF: yes
Create deck: no
Escalate to a human: yes

Those names are the product names. You turn them on or off per agent. Optional workflow tools (PDFs, decks, browser research, code, and the rest) are opt-in. MCP and custom HTTP tools are installed separately, but they sit in the same map: if it is not enabled, it is a no.

Resolution order a customer can understand:

1. What you enabled on this agent.
2. What the plan allows for the workspace.
3. What is actually available right now.
4. Otherwise they should not hear a yes.

The instructions then only describe the yeses. If someone asks for a no, the agent says it cannot do that here, offers the nearest yes, or tells them to ask the owner to enable it. It does not invent a finished file.

That is the difference between a chatbot that sounds capable and an agent that knows its world.

How this builds trust

Trust is what people feel when three things stay aligned:

• Speech matches tools. The agent does not offer a deck, a sandbox run, or a CRM write you never enabled.
• Knowledge matches answers. Facts come from Knowledge (uploads, crawls, folders), not a guessed policy. If the answer is missing, Inbox can escalate — or you teach the answer back into knowledge. That is better than a fluent fiction.
• Failures stay human. “I can’t create a PDF in this chat right now” is trustworthy. Asking a customer to paste a key is not.

We know the map is working when the playground, Inbox, and approvals match Agent settings. If a tool is off, the UI and the agent agree. That is how we tell a grounded workspace from a lucky demo.

Pair this with system prompts that stay on-script and tool calling that stays gated. Instructions, ontology, and settings have to say the same thing.

The ontology is the harness definition

People say “agent harness” and mean a pile of prompts and tools. That pile only holds if you can answer, for every conversation:

So the harness is not a hidden engine. It is anatomy (how you assemble the agent) + ontology (what it may claim) + the product that enforces both.

On WisebotAI that enforcement is what you already operate:

• Per-agent tools in Agent settings. Disabled tools are not offered.
• Guardrails in instructions — topics, tone, when to hand off.
• Knowledge scoped to the organization, organized in folders.
• Playground — same agent, before the widget or a messaging channel goes live.
• Inbox — escalate and resolve when the map says a human is the next step.

If you cannot write the ontology for an agent on one screen, you do not have a harness yet. You have a prompt.

How we know this holds

We do not ask anyone to trust a slogan. We check the same four places on every workspace:

1. Agent settings — the yes/no map you saved.
2. Playground — a follow-up that asks for a disabled tool, and a follow-up that needs Knowledge.
3. Inbox — threads that should have escalated instead of guessing.
4. Channels — the same agent, after save, on at least one live surface.

When those four agree, the agent knows its world. When they do not, the customer already knows more than the dashboard.

A worked example

A weekly manager report agent — a job many teams run as a workflow that exports a PDF — should look like this:

Anatomy
  Identity: internal ops analyst, concise
  Tools: knowledge search, create PDF
  Knowledge: an ops / weekly folder
  Channels: playground first, then the channel leadership already uses

Ontology
  Knowledge search: yes
  Create PDF: yes
  Create deck: no
  Web search: no

When someone asks for slides, the agent does not pretend it has decks. It offers the report as a PDF, or says the owner can enable decks in Tools. When the folder is thin, it says what is missing instead of padding a section. You can verify that in the playground with a real follow-up, then save.

How to use this on your workspace

1. Name the job. One agent, one ontology. Support, sales, and ops should not share a mega-prompt. Use the agent switcher on purpose.
2. Turn tools off unless the job needs them. Every extra yes is a new way to over-promise.
3. Put facts in Knowledge, behavior in instructions. The ontology is for capabilities; folders are for policy.
4. Test the noes in the playground. Ask for something you disabled. If the agent implies the tool exists, the harness is leaking.
5. Re-test after you save settings. Changes apply across channels for that agent — widget and at least one messaging channel, not only chat on the dashboard.

The companion post is the measurement side: multi-turn evals, namespace chunking, and hybrid retrieval.

Where to go next

• Agent settings
• Built-in AI tools
• Agent chat playground
• Retrieval & RAG