Agents on the brain: governed agents that know who owns, approves and decides

Many agent failures in organisations are not failures of language. They are failures of context. An agent reassigns a ticket to a team that was dissolved last quarter, asks a former manager to approve an expense, or changes a system without knowing who owns it. The model was fluent; the organisation was missing.

Four things are needed before an agent acts on anything that matters: the owner of what it is touching, the person who must approve, the scope it is permitted, and the history of what happened before. The brain is designed to supply all four, each with an evidence status, so the agent can tell a verified owner from a guess.

On the roadmap, an agent asks the brain for a context package: the facts and content relevant to its task, assembled for the person it acts for and limited to what that person and the agent are both allowed to see. A Model Context Protocol server is designed to expose the same thing to any agent framework that speaks MCP.

The package carries statuses and ages with every fact, so the agent’s policy can act on them. It is filtered by principals inside the database, and everything in it is treated as untrusted data: retrieved content cannot change the agent’s instructions or its permissions. The context API and the MCP server are not built yet.

Reading is half of it. When an agent needs to do something, the design is an action gateway that offers typed capabilities: reassign a ticket, open a change request, add a comment. Each capability has a defined input, is approved for the agent in advance, can require human approval per call, and is recorded. The gateway is on the roadmap.

There is deliberately no shell capability, no general way to run arbitrary commands. A shell turns every permission question into a question about what a command might do, which nobody can answer in advance. Typed capabilities keep the question small. The appliance’s own edge link already follows this rule: it accepts only signed, typed commands from an allow-list, with no shell.

Consider an agent that routes incoming IT tickets to the right team. It can read the ticket, read the graph for the reporter’s team and manager, look up which group handles each category, and draft a routing note. It can reassign a ticket within the IT queues. It works at L3: it acts within limits, and the service desk lead reviews a sample of its decisions.

It cannot read tickets marked confidential unless the person it acts for could, cannot change anyone’s access, cannot close a ticket, and cannot route to a team whose owner fact is disputed. It requires approval to route anything tagged as a security incident, to reassign a ticket a second time, or to contact anyone outside the organisation.

It records its identity, the ticket and graph facts it read with their statuses, the model it used, its routing decision, any approval and who gave it, the action taken and the outcome when the ticket closes. Studio can build an agent like this and Nexus can trace it and enforce policy on its actions today, but the ticket collector, the brain context and the action gateway it depends on are on the roadmap.

Agents follow the evidence statuses. A routing or approval decision should rest on a verified owner, or at least a corroborated one. When the owner fact is stale or disputed, the agent stops and asks a person rather than choosing. When it is unknown, the agent says so in its output. Inferred facts can inform a recommendation but should not trigger an action on their own.

These rules are written into the agent’s policy using the same verbs as the rest of the platform: allow, deny, warn, filter, escalate and require human approval. A disputed owner escalates. A stale approver requires human approval. The point is that the agent’s caution follows the quality of its evidence, not the confidence of its model.

On the roadmap, what an agent does comes back to the brain as evidence: an approval given, a correction made, a ticket that bounced back to the queue. A routing decision that a person corrected becomes a fact with a status, and the next decision can use it. This is the last edge of the loop, and it is how the organisation gets better at its own work.

An agent can run on a model adapted to your domain. Swfte can host your own weights today in the Model Vault and serve them behind the Connect gateway. Training those models on data chosen from the brain is designed for and on the roadmap. The custom models pages set out what exists and what does not.

Built today: the graph of people, groups, reporting lines and accounts with evidence statuses and history; the local API; the hash-chained audit; the outbound-only link that accepts typed, allow-listed commands and has no shell. Studio builds agents, chatflows and workflows, and Nexus captures agent actions, enforces policy in flight and traces agents.

Designed for and on the roadmap: context packages and the MCP server; the action gateway with approvals; system, code and ticket collectors; outcomes written back as evidence; and the wiring that lets Studio, Nexus and the Nexus harness read the brain. Permission-filtered content search and delegation tokens for acting on a person’s behalf are in progress.