What Is an Agent Mesh? (And Why Your Org Chart Is the Routing Map)

An agent mesh is a set of scoped AI agents, each holding one role's credentials and one role's authority, that report and delegate along the same lines the company already uses. The org chart is not documentation of the mesh. It is the routing table: it decides which agent receives a task, which agent may approve it, and which decisions never leave the seat that owns them.

We run one. Four agents hold seats at Neogen Media: JARVIS for the founder's office, Kiara for HR, Taurus for operations and Neo for revenue. Each runs in its own container, each carries only its role's keys, and every one was built from the org chart we rewrote on 22 July 2026, the day we decided the chart would be the agents' routing map rather than a diagram of it. The running system is documented in the Neogen AI OS case study. This post is the definition, and the two occasions the definition was tested.

What is an agent mesh?

An agent mesh is a small number of long-lived agents with fixed roles, where the routes between them are inherited from the organisation rather than invented for the software. It is not an orchestrator, which spins up workers for one job and discards them, and not a single assistant with many tools, which has one identity and one blast radius.

Three properties make it a mesh rather than a pile of bots:

• Scope is per seat. On 29 July 2026 our single founder profile became seven scoped profiles carrying 119 skills between them. Verified live that day: the SEO profile could see none of the accounting, ads, CRM or messaging keys, and the operations profile held no write credentials at all, because it acts only through the approval gate.
• Limits live in the tool, not the prompt. Where a role's authority had to be smaller than its credential allowed, the reduction is mechanical: the ads reader issues GET requests only, and the SEO data tool carries an endpoint allowlist, a 25-task cap and a daily spend cap. A prompt saying please do not write is not a control.
• Routes follow the chart. A subordinate agent can send up to the founder agent and nowhere else. The bus refuses peer-to-peer messages with a 403 and refuses any attempt to read another agent's inbox. Delegation moves tasks, never credentials: a delegated task runs with the receiving agent's keys and access, so the channel cannot become a privilege-escalation path.

The containment side of this, one container and one UID per agent and a database no agent can route to, has its own post on AI agent architecture. This one is about the lines between the boxes.

Why is the org chart the routing map, not the documentation?

Because routing is the set of decisions about who receives work, who may approve it and who is told afterwards, and a company has already made those decisions in its reporting lines. A second map for the agents is a second map that drifts. Using the chart means every reporting line has to be precise enough for a machine to execute.

Melvin Conway wrote the general version of this in 1968: organisations "are constrained to produce designs which are copies of the communication structures of these organizations" (How Do Committees Invent?). Conway's law is usually quoted as a warning. In an agent mesh it is the design. If the agents will copy the communication structure anyway, write the structure down first and make it the thing they copy.

Every agent went through the same assembly line: interview the person who holds the seat, define a SOUL file, an operating SOP, a capability-matrix row and a reporting contract, then build, pilot in shadow mode and graduate. The reporting contract is the piece we underwrote, and it is where the mesh first broke.

Delegation itself arrived on the evening of 30 July 2026. Between 21:32 and 22:34 JARVIS designed, deployed and wired the inter-agent bus, with a send tool installed in all four agent containers. Every step went through the approval gate: 13 submissions released by code, 5 genuine failures retried in the open. We reconstructed that hour from the gate's audit log of 219 events, not from the agent's own account of it.

If you are mapping seats to agents for your own company and want the reporting contracts written before the first escalation rather than after it, that is the work our AI agent development team does.

What happens when a reporting line is left undefined?

The agent interprets it downward and asks permission for its own job. On 9 August 2026 the COO agent spent three hours and 17 bus messages asking the founder agent about a naming standard inside our task-management platform, a decision that sits entirely within operations. Five of the replies were policy refusals. The thread ended as a decision memo on my phone, asking me to approve a naming convention.

This is the head of operations. Why is he asking anyone? The cause was not the approval gate. It was three descriptions of the system that disagreed with the system:

• The platform was never in the gate's registry. Taurus held his own API key, and the platform's action catalogue answered him directly with every write action. He could have done all of it without asking.
• His SOUL file said he could not. Rule 6 read "You propose, you don't execute." The gate's self-service list had already granted him every action that rule named. The permission was granted in the gate and withheld in the prose, and the prose is what the agent reads every time it reasons.
• The escalation poller told JARVIS to report any blocker to the founder, with no test for whose decision it was. Every unresolved item became a DM by construction.

Underneath all three was one line. Taurus's SOUL said he "reports up to JARVIS" and never said what reporting means. He read it as asks permission. The fix was a paragraph saying the opposite explicitly: JARVIS does not own delivery, cannot approve an operations decision on the founder's behalf, and asking him converts a call Taurus owns into a delay and then into a message on someone's phone.

The rule we wrote down that day: if an agent's authority is only implied, it will be interpreted downward. Escalating is always the locally safe move, and its cost lands on someone else. The tell was cost, not error. Nothing broke.

The same pass on the other two seats found the same defect twice more. Kiara's rule 6 withheld nine self-service actions she already held. Neo's SOUL said the CRM was read-only while he had held pipeline-update rights for as long as the gate had existed. And 33 of Neo's skill files opened with "You are the COO agent", copied from Taurus's set without changing the header, against a SOUL that told him never to claim to be another agent.

How do you decide which decisions leave a seat?

With a domain test, not an importance test. The old escalation prompt asked whether an item was substantive, and everything substantive reached the founder. The new one asks whose decision this is. If it sits inside the sender's own domain, JARVIS replies that it is theirs and does not relay it. Five categories go up: money leaving the company, client-facing commitments, headcount or pay, irreversible or reputational actions, and genuine gate approvals. Everything else returns silent.

The same day we added a second approver, because the gate had exactly one and every gated action from three agents waited on one phone. JARVIS may now release a named set of actions on the founder's behalf, under one invariant: an agent can never approve its own request. Seven tests on the real path proved it, including the one that matters most: when JARVIS submits a delegated action type himself, it routes to the founder, and his attempt to release it is refused with "you submitted this yourself".

The test for what to delegate was not seniority. It was: can this be undone, and does it leave the company? Seniority would have handed the operations agent everything an operations chief may do, including spend. Reversibility put a container restart and an ad budget change in different buckets regardless of who asked. Pausing an ad stayed self-service, because it only ever stops spend, and the safe direction should never be the slow one. Nothing billable, client-facing, credential-minting or root-level was delegated.

One thing we found while fixing it: the escalation poller had been dead. Its schedule read once every ten years, its display still said every two minutes, and it had fired 866 times before stopping. A longer version of that failure shape, six days of silence with every control passing, is in our post on AI agent observability.

The primitive: a reporting line is a contract, not a caption

Every failure in this post was a description of the system disagreeing with the system. A SOUL rule, a cron prompt, a copied banner, an unstated reporting line. The gate, the keys and the access control were correct throughout. When an agent behaves more timidly than its permissions allow, read what it was told, not what it was granted.

So the org chart in an agent mesh is load-bearing, and "reports to" is the load-bearing line. Written for a machine, it has to say which decisions the seat owns outright, which it must send up and to whom, and who is told afterwards rather than asked beforehand. If a line cannot answer all of that, the agent under it will answer for itself, and it will answer downward every time.

We are building this in the open. The running system is in the Neogen AI OS case study, and the day-to-day operating detail is in running a Hermes agent in production. If you want the seats mapped and the reporting contracts written before your first agent asks permission for its own job, talk to us.

Frequently asked questions about agent meshes

Do the agents need to talk to each other at all?

Not for data. The founder agent can already read everything the HR and operations agents can, under the same host access control. What delegation adds is action and ownership: a request to have Kiara chase something lands in the HR queue with HR's context, instead of the founder relaying it by hand. We deferred the bus on exactly that reasoning.

Can a subordinate agent task another subordinate?

No. The bus enforces that non-super agents can only send to super agents, returning 403 otherwise, and no agent can read another's inbox. Downward delegation is the safe direction; upward and lateral traffic needs an explicit gate. This is enforced in code rather than in a prompt, which is the only place a rule like it holds.

What happens if one person is on more than one agent's allowlist?

In our runtime, all three messaging bots answered as the HR agent. The session lookup keyed on source, user and chat but not on profile, and for a direct message those values are identical across bots, so three agents collapsed onto one session. The rule since 29 July 2026 is one messaging account per bot, and the bug is reported upstream.

Is a mesh the same as a multi-agent framework that fans out sub-agents?

No. Fan-out frameworks solve parallelism inside one request: many short-lived workers, one caller. A mesh is a handful of long-lived agents with seats, where the routes are inherited from the company and the consequences are gated. Ours runs on plain containers, a small bus API and an approval gate, with no orchestrator in the path.