A single agent doing a single task is the easy case. The hard case, and increasingly the normal one, is a team of agents: a planner that hands research to a specialist, a specialist that calls a tool, a pool of shared context they all read from and write to. The work gets done by a chain of hand-offs, not one actor.
The tools that orchestrate those teams are excellent at coordination and almost silent on trust. They assume every agent in the workflow already trusts every other one. So when agent A hands work to agent B, nothing checks that A was allowed to delegate, nothing stops a rogue agent from poisoning the memory the others rely on, and nothing can tell you afterwards which agent, acting on whose context, actually made a decision. A team of agents is only as trustworthy as its weakest hand-off, and today most hand-offs are on the honor system.
Today we are shipping the Multi-Agent Fabric: a trust layer that sits underneath whatever orchestrator and memory store you already use. It is built on three capabilities, all live now in the TypeScript and Python SDKs and the API.
Verified hand-off
When one agent hands a task to another, the hand-off carries a verified identity and a strictly narrowed set of permissions. The receiving agent can only ever do less than the sender, never more, and it is checked for trust and standing before it is handed anything. If the receiver cannot be verified or is not in good standing, the hand-off is refused rather than waved through.
This kills a quiet but common failure mode: authority drift, where a sub-agent silently inherits or exceeds the permissions of the agent that called it. In the fabric, every hop can only attenuate. A researcher handed read-only access cannot turn around and grant itself the ability to act, and it cannot pass on more than it holds.
// hand a task to another agent as one auditable operation:
// verify the receiver, delegate a narrowed scope, record it.
const { chain } = await vorim.handOff('agid_planner', {
to: 'agid_researcher',
scopes: ['agent:read'], // researcher gets read-only, nothing more
task: 'gather sources for the Q3 report',
maxChainDepth: 0, // and cannot re-delegate
minTrustScore: 60,
});The whole hand-off, who handed what to whom, with which permissions, is recorded on a signed, tamper-evident trail.
Governed shared memory
A team of agents usually needs a shared pool of context: findings, intermediate results, a common working memory. That pool is also the most dangerous surface in a multi-agent system, because one agent's writes become every other agent's reads. Memory and context poisoning is now a named class of risk in the industry's agentic security guidance, precisely because a single bad entry can cascade through everyone who reads it.
The fabric's shared memory is governed rather than open. Every write is attributed to the agent that made it and cryptographically signed, so a poisoned or suspicious entry is always traceable to its source, and an unverifiable write is rejected at the edge rather than stored. Reads are permission-scoped, not open to every agent by default. You get the benefit of shared context without the shared blast radius.
// an agent writes to the shared pool; the write is attributed + signed
await vorim.writeMemory('agid_researcher', {
namespace: 'q3-report',
key: 'sources',
value: { found: 12, verified: 9 },
});
// another agent reads it, and can see who wrote it and whether it was signed
const entry = await vorim.readMemory({ namespace: 'q3-report', key: 'sources' });The point is not to be another memory database. It is to make the memory a team already shares something you can actually trust: attributed, signed, and permissioned.
Whole-workflow provenance
When a multi-agent workflow produces an outcome, the hardest question to answer is usually the simplest to ask: which agents took part, who authorized whom, and what did each one do? Debugging tools can show you a trace, but a trace is not evidence, it is not tamper-evident and it is not bound to identity.
The fabric reconstructs the full picture as one verifiable record. For any workflow, you can pull the graph of agents that participated, the delegations between them, and the actions each one took, assembled from signed data and verifiable on its own. It is the difference between "the logs suggest agent B did this" and "here is the signed record of exactly which agent did what, and who authorized it." As accountability rules for AI move from principle to requirement, that record stops being a nice-to-have.
It sits under your stack, not in front of it
The fabric is deliberately not another agent framework or another memory store. It works through the same SDKs that already give your agents identity, permissions, and signed audit trails, so you keep the orchestrator and the tools you use today and add the trust layer underneath. The frameworks handle coordination. Vorim handles who is allowed to do what, whether the shared context can be trusted, and what actually happened.
That division is the whole idea. Collaboration between agents is going to be the default, not the exception. When it is, the question is not whether your agents can work together, it is whether you can prove which one did what, and stop a bad one from quietly corrupting the rest.
You can build on the Multi-Agent Fabric today. See how it fits your workflow at vorim.ai/multi-agent, or reach us at team@vorim.ai.
Ready to build with agent identity?
Free plan: 10 agents, 10K auth events/month, full SDK access. No credit card.