A Trustvice Product
One agent is easy to reason about. It has a task, a set of tools and an owner who watches it. The trouble starts with the second agent, and gets worse with the tenth.
Two coding agents open pull requests against the same file. A cleanup agent deletes a branch that a release agent is about to tag. A cost agent scales down a cluster while a migration agent is still running on it. Each agent did what it was told. Nobody told them about each other.
People who share a resource solve this with a calendar, a lock on the door or a quick message. Agents have none of that by default. They act on shared ground with no shared rules, and the first sign of a conflict is usually the damage.
Intramedial is our answer to that. This post explains what it does, how the parts fit, and what it does not claim.
The idea in one paragraph#
Intramedial is an Agent Coordination Plane. Before an agent acts on something shared, it declares an intent: who it is, what it wants to touch and the verb. The plane answers allow or deny, with a reason, before the action happens. Every answer, and every change to the rules, is written to a record you can read later and hand to an auditor.
The engine that answers is called Intralock. It is a pure function over a compiled policy snapshot. It makes no network call and uses no model, and every admission response says so with llm: false. The same intent against the same snapshot gets the same answer.
Why a plane, and not a smarter agent#
We could have built one more agent that watches the others. We chose a plane for one reason: the rules should not depend on any agent behaving well.
An agent that coordinates other agents is still an agent. It can be wrong, it can be prompted, and its reasons are hard to replay. A plane is boring on purpose. It reads the rules you wrote, applies them the same way every time, and writes down what it decided.
That also means the plane does not need to understand what your agents are for. It needs to know who they are, what they touch and which rules apply.
The parts#
| Part | What it does | Where to read more |
|---|---|---|
| Identity | An agent is its DID (did:web:... or SPIFFE). A new DID is a new agent. | identity.enroll |
| Admission | Intralock answers a declared intent with allow or deny and a stable reason. | coordination.admit |
| Leases |
There are 55 modules in all, in eight groups. They are not separate products. Each one applies the same admission and the same record to another part of a fleet. The modules page lists them.
Start by watching, then enforce#
Nobody should switch on a new set of rules and hope. Each resource class runs at one of four stages: observe, advise, transform or enforce. Only enforce can deny. The earlier stages let the call through and report what enforce would have decided.
So the usual path is to point your agents at the plane in observe, read what it would have refused, fix the mandates, and only then move a resource class to enforce. Protected classes (KMS, identity, ledger and billing) stay at enforce from the start.
A human where it matters#
Some actions should not happen on an agent's word alone. A write or delete without a confirmation token is refused, and the request lands in an approval queue. A signed-in administrator or a granted approver reads it and decides. Nobody can approve their own request, and an API token or an agent cannot approve at all. See coordination.approve.
For the most sensitive scopes there is dual control: eight scopes need two different administrators. And when something goes wrong fast, halt switches and quarantine stop or isolate agents. See coordination.halt.
A record you do not have to take on trust#
A log kept by one side convinces that side. Intramedial's record is built so that someone else can check it.
The audit chain is per workspace and hash-chained in RFC 8785 canonical form with SHA-256. Editing, reordering, inserting or deleting an entry breaks the chain at a named sequence number, and anyone can check that with no key. A range of the chain can be sealed into a ledger bundle: a Merkle-rooted bundle signed with an Ed25519 key for the workspace's jurisdiction. Anyone with the public key can verify it offline, with the open-source verifier or a page of their own code.
We wrote two posts on this: What a ledger bundle proves, and what it does not, and a walk-through of verifying a bundle offline.
What Intramedial does not claim#
We would rather state the limits plainly than have you find them in an incident.
- It does not bind an agent that never calls it. Admission only decides intents it is asked about. Put an enforcement point in the agent's path, such as the MCP gateway or the GitHub write gate.
- It does not prove an agent did what it declared. The record holds the intent and the plane's decision. Whether the work happened is for detection and your own systems to say.
- An allow is not a judgment that the action is wise. It means the action fits the rules you wrote.
- The record is evidence, not a verdict. Whether an auditor, a court or a counterparty accepts it is not for us to say.
- It is not legal advice and carries no certification. We map evidence to controls; we do not certify conformity.
The security model states the same boundaries from the threat-model side.
Start here#
- Read How Intramedial works for the mental model.
- Follow the quickstart to admit your first intent.
- Read Admission and leases, explained for the two calls every agent makes first.
- Tell us what your fleet needs at /contact. We read everything.
Intramedial is operated by Avonao, Inc. The changelog records what changes.
