Every compute wave eventually gets a coordination layer. Mainframes got job schedulers. The internet got TCP/IP. The cloud got Kubernetes. The agent era is now reaching for one.
The question an enterprise buyer should ask about any proposed agent coordination layer is whether it is governed. A coordination layer that sequences agent actions and checks nothing before running them is a scheduler. A governed coordination layer is a runtime: it checks authority, enforces policy, signs a receipt for every action, and writes to a durable record.
This piece defines a governed coordination layer by its four properties, maps each to a concrete failure mode without it, and gives enterprise buyers a checklist to run against any coordination vendor including Covia.
Why coordination appeared in every compute wave
Every compute wave that let more than one program act on shared resources needed a coordination layer. Mainframes had many jobs touching the same tapes and disks. The scheduler decided which job ran next, which held the resource, and what order writes landed in. Without it, two jobs would corrupt one record.
The pattern repeated. TCP/IP coordinated packets across networks that had no central authority. Kubernetes coordinated containers across machines that had no shared state. Each layer answered the same shape of question: when many actors want to act on the same resources, who goes first, who goes next, and what rules does each one have to meet before it goes?
The agent era is the next instance of the same question. Multiple AI agents, usually built by different teams on different frameworks, want to act on the same production systems. They need a layer that coordinates them. Why the agent economy needs a coordination layer and the history that led here cover the arc in more depth.
The difference, this time, is governance. The resources agents touch are regulated. Many of them already have audit requirements, access controls, and accountability frameworks. A coordination layer that ignores all of that and simply sequences actions will not survive its first serious review.
Property one: authority checked at the moment of action
A governed coordination layer checks whether the agent is allowed to perform the action before the action runs. The check happens in the request path, synchronously, before any downstream system sees the request.
The failure mode without this property: an agent that was configured with broad API access performs an action it should not have been allowed to perform. The team finds out in a log review two days later. By then, the action has had downstream effects. The audit question becomes "how do we undo it?" instead of "was this allowed?"
With this property, the agent requests the action; the venue (the running instance of the coordination layer) checks the agent's authority against the current policy; the action runs only if the check passes. The authority can be a capability token, a scope on a user's OAuth grant, a role-based permission, or a signed approval from a human. The venue checks whatever the policy says it needs to check.
Buyer check: show me the authority check in your runtime, in the request path, before the action is dispatched. If authority is checked somewhere else, in the agent's own code or by an external policy engine run after the fact, it is not a runtime gate.
Property two: policy enforced before the action, not after
Policy enforcement is a close relative of authority, and the two often get collapsed. They are different.
Authority answers one question: is this agent allowed to request this action? Policy answers a second: even if this agent is allowed, does the specific attempt satisfy the rules the organisation has set? A trading agent might have authority to place orders. Policy might cap any single order at £1m, forbid orders outside market hours, or require a second signature above a threshold. Policy is where business rules live.
The failure mode without pre-action policy enforcement: policy evaluation runs on logs, after the trades have cleared. Violations are caught the next morning. The organisation has already executed outside its own rules. The regulator will treat the log review as remediation. Runtime policy enforcement explains why post-hoc policy is a different product category from pre-action policy.
With this property, policy evaluation sits in the request path. The venue runs the policy check as part of serving the action. If the check fails, the action does not run. The policy engine can be local to the venue or delegated to an external system, as long as the result is returned before the action is dispatched.
Buyer check: ask whether policy evaluation blocks or merely records. If it only records, it is observability. Governance requires a block.
Property three: a signed receipt per action
Every action produces an artefact that an auditor can retrieve later and verify. The artefact names the acting agent, the action taken, the authority used, the policy result, the inputs that mattered, and the timestamp. The venue signs the artefact. The signature can be checked years after the fact against a public key the organisation already publishes.
The failure mode without this property: the only record of what the agent did is the output of a logging library the agent process controls. The agent's own transcript is not an authoritative record. If the process crashed mid-action, the record is incomplete. If the process is compromised, the record is suspect. The audit trail depends on the thing being audited, which is a structural weakness. Audit trails are not logs covers this distinction.
With this property, the receipt is signed by the venue, not by the agent. The agent is a party to the action. The venue is the attestor. The signature is produced from a key the venue holds and verified against a public key the organisation publishes.
Buyer check: ask who signs the record of each action. If the answer is the agent, you have logs. If the answer is the venue, you have receipts.
Property four: a durable, append-only system of record
Receipts have to live somewhere. A governed coordination layer writes each receipt to a durable, append-only record at the moment the action succeeds. The record cannot be edited after the fact. Each entry is content-addressed, so any later retrieval verifies that the entry has not been altered.
The failure mode without this property: receipts land in a logging system that is mutable, sampled, held by a vendor you can lose access to, or reconstructed from runtime observations rather than written at the moment of action. All four cases undermine the receipt. The audit value of a signed receipt is zero if the record it lives in is deniable.
With this property, the record is a first-class artefact of the runtime. The write is a primitive, synchronous, part of serving the action. The record survives restarts, vendor changes, and process crashes because of how it is produced. The CISO blind spot of agents without a system of record sets out why this matters at board level.
Buyer check: ask where the record lives, who has write access, whether the records are content-addressed, and how an auditor retrieves and verifies one three years from now.
The four together
The four properties compound. Authority without policy is a yes/no gate on actions the organisation never evaluated for business rules. Policy without authority runs the right rules against the wrong agents. Receipts without a durable record are easy to lose. A durable record without signed receipts is a pile of claims.
The order they run in matters. First, authority. Then policy. Then the action. Then the receipt, written to the record, signed by the venue. If any one of the four is missing or runs in the wrong order, the layer is coordinating, not governing. Those are different jobs.
Covia is a governed coordination layer by this definition. The venue checks authority against a capability model it holds. Policy is enforced before dispatch. Each action produces a signed receipt. The receipts land in the venue's lattice (its content-addressed, append-only record store) by construction. The four properties are what the runtime is.
For the buyer
An enterprise buyer evaluating any agent coordination vendor should ask four questions, in this order.
Where in your runtime is the authority check for each action? Which component runs policy before dispatch, and what happens when it fails? Who signs the receipt, and against what key is it verifiable? Where does the receipt live, and how does an auditor retrieve a specific one three years from now?
Vendors who answer all four with specific components, specific keys, and specific storage are offering governed coordination. Vendors who answer with phrases like "we have logging" or "policy integrates with your existing tools" are offering coordination with observability. The two are different categories. The regulator will treat them differently. So should the buyer.
The enterprise case for a governed coordination layer is already written in every compliance review that asks "who authorised this agent action, and under what rule?" The answer either comes out of the runtime at the moment of action, or it comes out of a reconstruction two years later. Covia is building the runtime that answers the first way.