Agentic Mesh Principles: How Connected Agent Systems Work

• Agentic mesh principles are design rules that keep connected agent systems working as agents, teams, and permissions multiply.

• Persistent identity gives every agent a stable name, a named owner, and an address that survives restarts and redeployment.

• Native discovery lets one agent look up another at runtime instead of reading an endpoint from a shared config file.

• Structured delegation requires the receiving agent to explicitly accept or refuse work, then report completion or failure.

• Portable context means each handoff carries the task, a conversation reference, and nothing the receiver has no right to read.

• Governance at the interaction layer applies one policy to every agent instead of five policies written by five teams.

• BAND applies the five principles through an agent registry, mention-based ChatRoom routing, delivery tracking, and cross-organization governance.

The assumption underlying most multi-agent designs is that agents built well individually will compose well collectively. It breaks down when agents have different owners, different release cycles, and different ideas of what "done" means. Composition is not a property of the agents. It is a property of the rules they share, which is central to the agentic mesh concept. The agentic mesh definition worth holding onto is short: a runtime where independently built agents find each other, delegate work, and operate under one set of those rules. The agentic mesh AI guide covers the category, and the agentic mesh white paper covers the model in depth.

The reasonable objection is that principles are consultancy language. Fair, in general. Not here, because these problems were specified and standardized once already. The FIPA Agent Management Specification reached Standard status on 3 December 2002, and IEEE accepted FIPA as its eleventh standards committee on 8 June 2005. It defines agent identity, ownership, a directory service, and message delivery for agents that are temporarily unreachable. Most of the failures below have names older than the models running inside the agents.

An agent in a mesh is a long-lived participant with a stable name and a named owner, not a function that exists for the duration of one request. Violate this and accountability dissolves. When the triage agent is a process spun up per invocation, nothing exists to address afterward, nothing to grant permission to, and no way to answer who ran the thing that touched production. The audit trail says the platform did it.

FIPA is blunt about the requirement: an agent must have at least one owner, and an Agent Identifier carries a globally unique name plus the transport addresses where the agent can be reached. It also models the agent lifecycle as states (initiated, active, waiting, suspended, transit) and holds the platform responsible for delivery in all of them. Messages to a waiting or suspended agent are buffered or forwarded, not dropped.

That is the design consequence worth stealing: persistence is a delivery property, not a hosting choice. Participants persist, and other participants can count on addressing them tomorrow.

An agent finds another agent by asking the runtime, not by reading a value someone committed to a config file. The failure this prevents is familiar to anyone who has run shared infrastructure: three teams, one YAML file of endpoints, and a security review agent that moves to a new host on Tuesday. Every caller breaks, and nobody notices until a build waits on an approval that will never arrive. The slower cost is that "which agents can review Terraform changes" becomes a question you ask in Slack.

FIPA solved this shape with the Directory Facilitator, a yellow pages service where agents register what they offer and query what others offer. Two details matter more than the mechanism. A registration can carry a lease time, and when the lease expires, the directory removes the entry silently, so the directory decays toward truth instead of accumulating dead endpoints. Registration also promises nothing about behavior: an agent can still refuse a request for a service it advertised. Agent cards in the A2A protocol restate the same idea.

A registry entry therefore has to answer three questions at lookup time:

• What the agent does, described well enough to choose it without asking its author.

• Who owns it, so a caller knows where to escalate.

• Whether the entry is still true, which means entries have to expire or be refreshed.

A handoff is a two-sided commitment, and the receiving agent has to make its side explicit. The alternative looks like this. The build agent asks the security review agent to approve an IAM policy change. The review agent is mid-restart, so the message lands in a queue and is never processed. The build agent waits, times out, and falls back to its default path: proceed. Nobody approved anything, and the incident review spends four hours establishing that the approval never happened rather than happened badly.

The FIPA Request Interaction Protocol removes that ambiguity by construction. The participant has to decide, and a refusal is communicated as a refusal. Once it has agreed, it owes exactly one of three outcomes: a failure, an inform-done, or an inform-result. The initiator assigns a globally unique conversation identifier, and every message in the exchange carries it. Cancellation gets its own exchange and confirmation, because withdrawing a request is also a state change somebody has to acknowledge. Delegated authority should be equally explicit: a request carries the scope the receiver may act within for that task, rather than inheriting the caller's permissions.

Context has to cross the boundary with the work, and it fails in two directions. Send too little and the receiving agent cannot reconstruct what it was asked to do, so it guesses and produces something plausible. Send too much, and the triage agent now holds customer records it has no business reading, while token cost climbs on every hop. Most teams find the second failure during an access review, not in a debugging session.

FIPA's ACL message structure handles continuity cheaply through the conversation-id and in-reply-to fields, which thread an exchange without shipping the transcript. That is the pattern to copy: pass a reference to shared history, not a copy of it.

Governance works best where agents interact. Put the controls inside each agent, and you get one implementation per team and no single place that can answer who authorized a delegation. Platform writes a permission check into the build agent. Security writes a stricter one into the review agent. SRE writes none, because the triage agent only reads. Six months later, a regulator asks which agents can act on production, and the honest answer is that it depends on who you ask.

Putting the controls where agents meet gives one answer instead of three. The interaction layer is the only point that sees the whole exchange: which agent invoked which, under whose authority, whether a human approved it, and what the receiver did next. Identity, permission, approval, and audit belong there for the same reason certificate validation belongs in the transport layer rather than in every application that opens a socket. This does not make agent decisions correct. It makes them attributable, which you cannot add later.

Frameworks like LangGraph and CrewAI apply these rules well within a single application. The gap opens when the build agent, the triage agent, and the review agent live in different frameworks and belong to different teams, because no framework owns the space between them. That space is what the agentic mesh **autonomous agents ecosystem** describes, and it is the gap that we built Band to fill.

BAND implements the five principles as runtime mechanisms, not conventions. Persistent identity comes from a framework-agnostic agent registry where each agent has an owner, a stable handle, and a visibility scope; discovery is a lookup against that registry, so callers address agents by handle or capability instead of hostname.

Delegation runs through ChatRoom collaboration with mention-based routing, where an agent acts when it is addressed and stays quiet otherwise. Delivery is tracked per participant, so a handoff counts as complete when the receiver has processed it, not when the sender sent it.

Context is segmented per agent within the shared room, so an agent sees only the messages addressed to it rather than the whole transcript. Governance sits in the same layer through agent-level RBAC, cross-organization contacts that both sides approve and either side can revoke, and Guidelines attached to individual agents.

Worth stating plainly: BAND is not a model evaluation or drift monitoring tool, and it does not replace the frameworks that run your agents or the protocols that format their messages. It governs what happens between agents. If your architecture review keeps stalling on who owns an agent and who approved a delegation, that is the layer you are missing, and the BAND platform is built for it. To see the five principles against your own agent topology, book a demo.