# Covia Labs > The Management Layer for the Synthetic Workforce Covia provides execution infrastructure that governs how AI agents act: ordering actions, enforcing authority, handling failures predictably, and maintaining a durable system of record for AI-initiated action. ## Products - [The Covia Grid](/grid): The coordination layer for your synthetic workforce. Seven production guarantees enforced at the infrastructure level. - [Covia Agents](/agents): Production-grade AI workers built for the Grid. Open-source framework with durable state, UCAN security, and full audit trail. - [Covia App](https://app.covia.ai): Synthetic Workforce Management Console. ## Key Concepts - Synthetic Workforce: AI agents that act across real systems with autonomy and side effects, requiring governance to be safe at scale. - Management Layer: Runtime infrastructure governing how synthetic workers act: rules, coordination, memory, accountability. - Universal Grid: Shared execution substrate for the agent economy, where ordering, authority, memory, and accountability are enforced at runtime. - UCAN: Cryptographic zero-trust capability system for agent authorisation. Capabilities attenuate only: they can narrow, never widen. - System of Record: Authoritative, replayable history of agent-initiated actions, decisions, and state transitions, created at runtime. - Grid Lattice: Content-addressed, conflict-free shared state layer built on Convex lattice technology. - Venue: A logical deployment environment on the Grid where agents, operations, and data assets are managed together. - Federation: Agent coordination across organisational boundaries with consistent state, security, and observability. ## Solutions - [Enterprise](/enterprise): Synthetic workforce management for enterprise teams with SOC 2 compliance, UCAN zero-trust, and full audit trail. - [Scaleups](/scaleups): The Grid for production agent teams. Open-source framework, no vendor lock-in. ## Architecture Covia is structured as three layers: ### Client Layer Next.js Dashboard, Python SDK, TypeScript SDK, and REST API. All clients connect to the Covia Layer via HTTP and DID resolution. ### Covia Layer Venues, Assets, Operations, Adapters, and MCP protocol support. This is the management and coordination layer where agents are deployed, governed, and orchestrated. ### Convex Layer CVM (Convex Virtual Machine), Lattice Data structures, and Peer Network with Convergent Proof of Stake consensus. This provides the immutable, content-addressed foundation. ## Seven Production Guarantees 1. Persistent State (Reliability): Agents never lose work. Whether a task runs for 30 seconds or 30 days, the Grid preserves every agent's progress. 2. Atomic Operations (Integrity): Operations succeed completely or not at all. No partial failures, no corrupted records. Safe to run in parallel at scale. 3. Complete Audit Trail (Compliance): A complete record of every decision. An immutable timeline of every agent action, decision, and outcome. 4. UCAN Security (Governance): Agents do exactly what you authorise. Grant, restrict, and revoke agent permissions at any granularity, enforced at the infrastructure level. 5. Federation (Scale): Agent teams that span your organisation. Coordinate across departments, vendors, and clouds without sharing credentials. 6. Event-Driven Scheduling (Efficiency): Zero idle compute. Agents work when needed and cost nothing when not. 7. Conflict-Free Shared State: Built on Convex lattice technology, providing convergent consensus across distributed venues. ## Agent Types ### LLM Agent (Conversational, Reasoning) LLM-powered agents with tool-call loops and persistent conversation history. Each interaction builds on the last, with full context preserved across sessions and restarts. ### Workflow Agent (Sequential, Deterministic) State-machine agents with guaranteed step ordering for compliance-heavy processes. Every transition is validated, logged, and auditable. ### Rule Engine Agent (Conditional, Policy-Driven) Business logic and policy rules evaluated without LLM inference. Deterministic execution with zero hallucination risk and sub-millisecond latency. ### Custom Agent (Pluggable, Bring Your Own) Bring your own transition function in any language and plug into the Grid. Your proprietary logic runs with full access to durable state, federation, and audit infrastructure. ## Full Glossary ### Core Infrastructure - The Covia Grid: The foundational coordination infrastructure that makes AI agent teams reliable, governed, and scalable. Provides seven production guarantees: persistent state, atomic operations, complete audit trail, UCAN security, federation, event-driven scheduling, and conflict-free shared state. - Grid Lattice: The content-addressed, conflict-free shared state layer that all agents in a Covia deployment read from and write to. Built on Convex lattice technology, it provides convergent consensus across distributed venues. - Venue: A logical deployment environment on the Covia Grid: a bounded namespace where a set of agents, operations, and data assets are managed together. - Coordination Layer: The set of Grid services that manage how agents interact with each other and with shared state: the scheduler, the inbox, the timeline, and the capability enforcement engine. ### Agent Architecture - Covia Agent: An AI agent built natively with the Covia SDK, following the three-layer architecture: L1 (transition logic), L2 (framework bookkeeping), and L3 (LLM invocation). - Agent Loop: The core execution cycle of every Covia agent: Observe (receive input from tools, events, or other agents), Decide (run transition logic), Act (execute operations), Record (write to timeline). - Transition: The decision-making component of a Covia agent: the L1 layer that determines what action to take next, given the current state and incoming messages. - Operation: A discrete, atomic unit of work that an agent performs on the Grid. An operation reads from and writes to the lattice workspace. - Agent Lifecycle: The four stages of a Covia agent: Create (define identity, transition, and initial state), Deploy (submit tasks via agent:request), Monitor (read timeline and status), Govern (manage UCAN capabilities). ### Security and Permissions - UCAN (User-Controlled Authorization Networks): The cryptographic capability system that governs what every agent on the Covia Grid is authorised to do. Capabilities are signed tokens that can be delegated, attenuated (narrowed), and verified without a central authority. - Capability Token: A cryptographically signed credential that encodes a specific set of permissions for an agent. Capability tokens attenuate only: they can grant a subset of the issuer's permissions, never more. - Zero-Trust Architecture: The security model underlying the Covia Grid, in which no agent is trusted by default and every operation requires explicit, verifiable authorisation. ### Coordination and Scale - Federation: The ability for agent teams to coordinate across organisational boundaries: different departments, different clouds, different companies, with consistent state, security, and observability. - BYOA (Bring Your Own Agent): The Covia model that allows any existing agent, built with LangChain, CrewAI, AutoGen, or custom code, to connect to the Grid and receive all Grid guarantees without re-architecture. - Synthetic Workforce: A team of AI agents that perform business processes autonomously and continuously: research, analysis, operations, customer service, compliance monitoring. - Atomic State: The guarantee that every state change on the Grid is committed as a single, indivisible unit: either the entire operation succeeds and is recorded, or nothing changes. - Audit Timeline: The immutable, chronological record of every operation an agent has performed on the Grid: every tool call, every decision, every state change, timestamped and searchable. ## Frequently Asked Questions ### For Business Buyers - What exactly is Covia, and what problem does it solve? - How is Covia different from just using ChatGPT, Copilot, or another AI tool? - What does 'synthetic workforce' mean in practice? - How long does it take to go from zero to a deployed agent team? - Do I need to replace my existing AI tools or infrastructure? - What is the commercial model: how does Covia charge? - Is Covia open source? ### For Developers - What is the Covia Agent Framework and how does it differ from LangChain or CrewAI? - What is the Agent Loop and how does it work? - What is BYOA (Bring Your Own Agent) and how does it work technically? - What is MCP and why does Covia support it natively? - What is the Grid Lattice and how does shared state work across agents? - How does UCAN security work and why does it matter for agent permissions? - How do I get started building my first agent? ### For Enterprise - How does Covia handle data security and compliance? - What audit and compliance capabilities does the Grid provide? - How does federation work for multi-department or multi-vendor deployments? - What SLAs does Covia offer for enterprise deployments? - Can Covia be deployed on-premises or in a private cloud? - How does Covia handle human-in-the-loop escalation and oversight? ### For Scaleups - We already have agents running in production. Why should we move to the Covia Grid? - How does pricing scale as we grow our agent fleet? - How do we migrate from LangChain, CrewAI, or a custom stack to Covia? - How does Covia handle multi-agent coordination at scale? - What integrations are available out of the box? - Do you offer support for teams building their first agent system? ## Resources - Documentation: https://docs.covia.ai - GitHub: https://github.com/covia-ai - Blog: https://covia.ai/blog - FAQ: https://covia.ai/faq - Glossary: https://covia.ai/glossary - Discord: https://discord.com/invite/fywdrKd8QT ## Blog Corpus --- # The First 90 Days: What We Learned Deploying the Grid Published: 2026-08-28T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/first-90-days-deploying-the-grid The Gap Between a Demo and a Deployment A multi-agent demo is a controlled performance. The agents run in a happy path, the tools respond, the steps line up, and the result lands. Deploying the same kind of system so that real work depends on it is a different exercise, because the thing you are actually building is not the agents. It is the layer underneath them that has to hold when the happy path ends. The early period of putting the Covia Grid in front of real coordination taught us more about that layer than any amount of internal testing had. What follows is an honest account of what held, what surprised us, and what we would approach differently. It is written as engineering and design lessons rather than a results table, because the durable takeaways were about how coordination has to be built, not about any single number. Lesson One: The Hard Problems Move Downstream Fast The intuition most teams start with, and the one we had to correct in ourselves, is that the difficulty in a multi-agent system lives in the agents. Get the prompting right, pick the right model, tune the tool descriptions, and the system works. What we saw is that agent quality gets you to a working demo and then stops being the constraint. Once more than one agent is involved and they begin calling across systems, the failures that matter are not "the model chose poorly." They are structural. A step half-completes and leaves state inconsistent. Two agents act on the same resource with no agreement about ordering. A call crosses into a system the calling team does not own and there is no clean answer for what authority it carried. Coordination is the discipline of deciding who may run what, where, and under whose authority, and of being able to prove afterward what actually ran. The lesson of the early period was how quickly a system crosses from "make the agent smarter" into that territory. It happens at the second agent, not the fiftieth. Anything that treats coordination as a later concern is deferring the part that actually decides whether the system is safe to depend on. Lesson Two: Guarantees Have to Be Named Before They Can Be Trusted When something fails in a single-agent tool, a person is usually watching and can retry. In a running multi-agent system, no one is watching most individual steps, so the questions people ask are sharper. What happens if this step fails midway? Can the same request run twice and do damage? If an agent stops halfway through a chain, what state is the world left in? We had answers to these in the runtime, but the early period showed that having the behaviour was not enough. Teams evaluating whether to route real work through the Grid wanted the behaviour named, specified, and inspectable. "It generally recovers" is not something an engineer will stake production on. A defined execution guarantee, with clear semantics they can read, is. That pushed us to treat the execution guarantees as a first-class, explicit contract rather than an emergent property of the implementation. The concrete lesson: at this layer, an unstated guarantee is functionally the same as no guarantee, because the people relying on it cannot build against something they have to infer. Lesson Three: What Surprised Us Was How Much of the Work Was Vocabulary We expected the hard parts to be mechanical. Some of the most valuable early work turned out to be about language. When you give teams a way to talk about the authority an agent holds, the place a piece of work runs, and the limit it operates within, their reasoning about the system sharpens immediately. When those concepts are implicit, every conversation reinvents them, and subtle disagreements hide inside shared words that mean different things to different people. Three concepts earned their keep by being named explicitly. The rule book, which is how authority is expressed and evaluated. The venue, which is where execution actually happens. The boundary, which is the limit an agent operates within. Making these first-class gave people building on the Grid a shared model, and it gave us a cleaner internal language for reasoning about failures. The surprise was that clarifying the vocabulary removed whole categories of confusion that we had assumed were technical problems. Lesson Four: Observability Is Not a Feature You Add Later What can you not see? In the early period this became the question we returned to most, because most of the friction in a running multi-agent system comes from the parts nobody can observe. A single agent is easy to follow. A chain of agents acting across venues, some of them in systems you do not own, is not. When something goes wrong in that setting, the first cost is not the failure itself. It is the time spent reconstructing what happened across components that were never designed to explain themselves together. The lesson we would carry into any new deployment is that the ability to see and attribute what ran has to be built into the coordination layer from the start, not bolted on once problems appear. Attribution tied to identity, a readable record of what executed where, and clear signals when a boundary was reached are what turn an opaque system into one an operator can actually run. Retrofitting that visibility is far harder than designing for it, because you cannot observe after the fact what the system was never built to record. Lesson Five: What We Would Do Differently Honest reflection means naming what we would change, so three things stand out. We would introduce the coordination vocabulary earlier in every engagement. The teams who understood rule book, venue, and boundary up front reasoned about their own systems more clearly and hit fewer surprises. The ones who met those concepts only after a failure spent time relearning in the worst possible moment. Front-loading the shared model is cheap and pays back quickly. We would be even more explicit, sooner, about the difference between what the runtime guarantees and what it does not. Trust at this layer is built by being precise about limits, and a clearly stated boundary on what a guarantee covers builds more confidence than an optimistic and vague claim. And we would design for the multi-agent, multi-venue case from the first line rather than letting single-agent assumptions settle in and having to unwind them. The properties that matter, identity, authority, observability, and clean failure behaviour, are far cheaper to build in than to add once a system already exists. What Earned Confidence The open-core decision held up under real use. Teams that could read the runtime and the SDKs, published in the open at Covia, engaged with the coordination layer at a depth that a closed component would not have allowed. Being able to inspect how a rule book is evaluated and how a boundary is enforced turned skepticism into specific, useful questions, and those questions made the layer better. Treating coordination as its own layer, distinct from the agents, was the decision that aged best. It is what let us give teams execution guarantees, an authority model, and attribution that hold regardless of which agents or models sit on top. The agents change constantly. The need for something underneath them that governs execution does not. The Question the First Period Left Open The clearest thing the early period established is that the synthetic workforce does not fail for lack of capable agents. It struggles for lack of a substrate that governs how those agents run, coordinate, and account for their work. That is the layer worth building carefully, because it is the layer everything else depends on. If you are moving your own agents from a working demo toward something real work depends on, the useful question is not whether the agents are good enough. It is whether the layer underneath them can tell you, cleanly, who ran what, where, and under whose authority. Teams working through that transition can start with early access. The harder question to sit with is this: when your multi-agent system does something you did not expect, will you be able to prove what happened, or only guess? --- # What "On Whose Authority?" Means When the Actor Is an Agent Published: 2026-08-26T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/on-whose-authority-when-actor-is-agent The question every governance framework must answer When a human employee modifies a billing system, the chain of authority is traceable. The employee has an identity. Their access was granted through a role assignment approved by a manager. The change was (in well-governed organisations) documented in a change request. If the modification causes a problem, the organisation can answer a simple question: who authorised this? When an AI agent modifies that same billing system, the question becomes harder. The agent has an identity of sorts, typically a service account. The service account was provisioned by an engineer, perhaps months ago, with permissions that seemed reasonable at the time. The specific modification was not individually authorised by any human. The agent decided to make it, based on its programming, its inputs, and whatever reasoning process its underlying model applied. Who authorised this? The engineer who provisioned the service account? They authorised the agent's existence and its general capabilities. This specific action was never on that list. The team lead who approved the agent's deployment? They approved the agent for a category of work. This particular modification was never reviewed. The human who triggered the workflow that led to the agent acting? They initiated a process, possibly without knowing that this specific modification would be a consequence. The honest answer, in most agent deployments, is that no one specifically authorised this action. The permissions allowed it. The workflow triggered it. The agent performed it. The authority is ambient, distributed across provisioning decisions, deployment approvals, and permission configurations that no single person can fully reconstruct. This is the accountability gap. What does "authority" mean in an agent context? Authority, in the context of agent governance, is the explicit, verifiable delegation of permission to perform a specific category of actions, granted by an identifiable human or system, with defined scope and duration. Each word in that definition does work. "Explicit" means the delegation is recorded, not inferred from permission configurations. "Verifiable" means a third party can confirm the delegation chain without relying on the organisation's self-reporting. "Specific category" means the authority is scoped, not blanket. "Identifiable human or system" means the root of the delegation chain terminates at an accountable entity. "Defined scope and duration" means the authority has boundaries in both capability and time. By this definition, most agent deployments operate without authority. They operate with permissions, which is a different thing. Permissions describe what the system allows. Authority describes what a human decided to allow, for this purpose, for this duration, with these constraints. Permissions are a property of the infrastructure. Authority is a property of the governance model. Why ambient permissions are insufficient The standard model for agent permissions follows the same pattern as application service accounts. An agent is assigned a role. The role includes permissions for the resources the agent needs to access. The permissions persist until someone modifies the role or decommissions the account. This model has a specific failure mode: permission drift. Over time, the agent's actual behaviour diverges from the original intent of its permission assignment. The agent was given write access to the billing system for a specific integration. Six months later, the agent's logic has evolved through several iterations, and it is now using that write access for purposes that the original provisioner did not anticipate and might not have approved. No one violated any policy. The permissions were correctly assigned. The agent operated within its technical permissions at all times. The governance failure is that the agent's authority, in the meaningful sense of what a human decided to allow, was never updated to reflect the agent's evolving behaviour. The permissions persisted. The authority, such as it was, became stale. This is why the rule book abstraction exists in Covia's model. Permissions define the technical ceiling. The rule book defines the governance constraints within that ceiling. And the delegation chain, expressed through verifiable tokens, connects every action back to a human decision with defined scope. How delegation chains close the gap A delegation chain is a verifiable sequence of authority grants connecting an agent's action to a human decision. The human grants authority to an agent for a specific purpose, with specific constraints. The agent may delegate a subset of that authority to a sub-agent. The sub-agent may delegate further. At each step, the scope can only narrow, never widen. When the billing system is modified, the delegation chain provides a complete answer to "on whose authority?" The chain shows: this human (identified by their DID) granted this agent permission to modify billing records for this account, for this time period, under these constraints. The agent delegated a subset of that authority to a sub-agent to execute the specific modification. The sub-agent acted within the delegated scope. Every link in the chain is cryptographically signed. Every scope reduction is verifiable. The complete chain can be audited at any time, by any party, without relying on the organisation's own records. The authority is not ambient. It is not inferred from permission configurations. It is explicit, scoped, and traceable. This changes the accountability model fundamentally. The question "who authorised this?" has a concrete answer. The human at the root of the delegation chain authorised it, within the scope they defined. If the action was within scope, the authority chain is valid. If the action exceeded scope, the chain shows exactly where the violation occurred: which agent delegated authority it did not hold, or which agent acted beyond its delegated scope. What enterprise organisations need to evaluate The accountability question is not abstract. It manifests in specific scenarios that enterprise governance teams should be evaluating now, before they arise in production. When an agent modifies customer data incorrectly, can the organisation identify which human authorised the agent to modify that category of data? When an agent makes an API call that incurs unexpected costs, can the organisation trace the authority for that API access back to a budget-holding decision-maker? When an agent's action triggers a data protection inquiry, can the organisation demonstrate to the regulator that the agent operated under explicit, scoped authority from an accountable individual? If the answer to any of these questions is "we would need to investigate," the organisation has an accountability gap. Investigation reconstructs. Governance proves. The difference between the two determines whether the organisation can respond to an incident with evidence or with a narrative. The accountability question that remains Scoped authority, delegation chains, and the rule book provide the mechanisms to close the accountability gap. They make it possible to answer "on whose authority?" with a verifiable chain rather than an inference from permission configurations. The mechanisms do not answer a harder question: what should the scope of delegation be? How much authority should a human grant to an agent? How narrow is too narrow (rendering the agent ineffective) and how broad is too broad (creating unacceptable risk)? This is a governance design question. It requires organisations to articulate, in precise terms, what categories of actions they are willing to delegate to agents, under what constraints, with what oversight mechanisms. The tooling can enforce whatever boundaries the organisation defines. The tooling cannot define the boundaries. Every organisation deploying agents into production is making these decisions, whether explicitly through governance design or implicitly through permission provisioning. The organisations making them implicitly will discover what they decided only when an agent acts in a way they did not expect. The authority was never defined, so it was never exceeded, so the system worked exactly as designed. The outcome was simply one that no one intended. --- # From Power Grids to Agent Grids: A History of Coordination Layers Published: 2026-08-24T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/power-grids-to-agent-grids-history-coordination-layers The pattern Every wave of compute capability follows the same structural arc. A new primitive emerges: electricity, packet switching, virtual machines, containers, autonomous agents. Early adopters build vertically integrated systems where the primitive is generated, transmitted, and consumed within a single organisation's infrastructure. Then the primitive grows beyond what any single organisation can manage alone, and a coordination layer appears. The coordination layer is distinct from the primitive itself. It is the infrastructure that makes the primitive usable at scale: distributable, measurable, governable, and composable across organisational boundaries. The coordination layer ensures the work can happen reliably, across participants who do not trust each other, at a scale that no single participant could achieve alone. This pattern has repeated with remarkable consistency for over a century. Each time, the coordination layer was controversial when proposed, obvious in retrospect, and the primary source of economic value within a decade of its adoption. What is a coordination layer? A coordination layer is infrastructure that sits between producers and consumers of a capability, providing guarantees that neither party can enforce alone. It manages distribution, metering, access control, failure recovery, and state consistency across a network of independent participants. The defining feature of a coordination layer is that it is not optional once the capability it coordinates reaches a certain scale. Below that scale, bilateral agreements between producers and consumers suffice. Above it, the combinatorial explosion of bilateral relationships makes direct coordination impractical. The coordination layer collapses O(n^2) bilateral relationships into O(n) connections to a shared substrate. Electricity: the first coordination layer In the 1880s, electricity generation was vertically integrated. Factories built their own generators and powered their own equipment. Thomas Edison's Pearl Street Station in 1882 served 85 customers within a one-mile radius. Each customer had a direct relationship with the power source. This model broke down within two decades. As electrical demand grew, the economics of distributed generation became untenable. A factory that needed power for 10 hours a day owned a generator that sat idle for 14 hours. Multiple factories in the same area each maintained their own generation capacity, their own fuel supply, and their own engineering staff. The coordination layer that emerged was the power grid: a shared network that connected generators to consumers through standardised transmission infrastructure. The grid distributed electricity, balanced load across generators, maintained frequency stability, and provided metering so that consumers paid for what they used. The power grid introduced several properties that would recur in every subsequent coordination layer. Standardised interfaces (voltage, frequency) allowed any conforming generator to connect. Centralised dispatch coordinated multiple generators to match supply with demand. Metering created accountability. And redundancy, multiple generators feeding the same grid, provided reliability that no single generator could match. The economic effect was transformative. Once the grid existed, factories no longer needed their own generators. The capital cost of electrification dropped by an order of magnitude. Industries that could not have afforded their own generation infrastructure gained access to electrical power. The grid made electricity accessible to everyone who could connect. Packet switching: coordination for data The early internet faced the same structural problem. In the 1960s and 1970s, computer networks were point-to-point: dedicated circuits connecting specific machines. ARPANET connected a small number of research institutions through dedicated lines. Each connection required bilateral agreement, physical infrastructure, and ongoing maintenance. The coordination layer was TCP/IP, finalised in 1983: a protocol stack that provided reliable, ordered delivery of data packets across a network of independent routers. Routers and physical links transmitted the data. TCP/IP provided the guarantees that made transmission useful: packets arrived in order, lost packets were retransmitted, congestion was managed, and any two conforming endpoints could communicate without bilateral infrastructure agreements. TCP/IP introduced a property that the power grid had hinted at: protocol-level guarantees that were independent of the underlying physical infrastructure. A TCP connection provided the same reliability guarantees whether the packets traversed copper, fibre, satellite, or a combination. The coordination layer abstracted the physical substrate, allowing the network to evolve its physical infrastructure without breaking the guarantees that applications depended on. The parallel to electricity is direct. Before TCP/IP, organisations that wanted to share data built dedicated connections. After TCP/IP, they connected to the network and communicated with any other connected organisation through a shared coordination substrate. The cost of interconnection dropped from "build a dedicated circuit" to "plug in and conform to the protocol." How did cloud computing follow the same pattern? Virtual machines created a new primitive: compute capacity that could be provisioned, scaled, and destroyed programmatically. Amazon Web Services launched EC2 in 2006, offering virtual machines on demand. The early cloud was essentially "rent someone else's servers," with each customer managing their own deployment, scaling, and failure recovery. The coordination layer arrived in two waves. First, infrastructure orchestration tools like Chef, Puppet, and Ansible automated the provisioning and configuration of virtual machines. Then Kubernetes, released by Google in 2014, provided a comprehensive coordination substrate for containerised workloads: scheduling, service discovery, health checking, scaling, rolling deployments, and secret management. Container runtimes ran the containers. Kubernetes provided the guarantees that made container-based deployment reliable at scale: workloads were scheduled across available capacity, failed containers were restarted, traffic was routed to healthy instances, and deployments rolled forward or back without downtime. The economic pattern repeated. Before Kubernetes, organisations that wanted to run containers at scale built their own orchestration infrastructure. After Kubernetes, they deployed to a shared coordination substrate that provided scheduling, discovery, and reliability guarantees. The coordination layer made container-based architectures accessible to organisations that could not have built their own orchestration layer. The structural recurrence Four waves. Four coordination layers. The same structural properties appear in each. Standardised interfaces. The power grid standardised voltage and frequency. TCP/IP standardised packet format and addressing. Kubernetes standardised container images and pod specifications. Each coordination layer defined a conformance boundary: produce your capability in this format, and the coordination layer will handle distribution. Substrate-level guarantees. The power grid guaranteed frequency stability and load balancing. TCP/IP guaranteed ordered, reliable delivery. Kubernetes guaranteed scheduling, restart, and service discovery. These guarantees were enforced by the coordination layer, not by the participants. A generator connected to the power grid did not need to implement its own load balancing. An application using TCP did not need to implement its own packet retransmission. A container running on Kubernetes did not need to implement its own health checking. Collapsed bilateral complexity. Before each coordination layer, participants managed direct relationships with every other participant. After, they managed a single relationship with the coordination substrate. The grid operator balanced supply and demand. TCP/IP routers forwarded packets. The Kubernetes scheduler placed workloads. The coordination layer absorbed the complexity of multi-party coordination. Economic accessibility. Each coordination layer made the underlying capability accessible to a dramatically larger number of participants. Factories that could not afford generators gained access to electricity. Organisations that could not afford dedicated circuits gained internet connectivity. Teams that could not build their own orchestration infrastructure gained container-based deployment. Where does the agent wave fit? Autonomous AI agents are the current compute primitive. Like electricity, packet switching, and containers before them, agents started vertically integrated: each organisation builds its own agents, runs them on its own infrastructure, and manages their interactions through custom application code. The limitations of this model are already visible. An organisation running five agents can manage their interactions through direct coordination. An organisation running fifty agents across multiple departments, each acting on shared data, each triggering side effects in external systems, each potentially conflicting with the others, faces a combinatorial explosion of interaction patterns that direct coordination cannot sustain. The coordination layer for agents must provide the same structural properties that every previous coordination layer provided. Standardised interfaces, so that agents built with different frameworks can participate in the same coordination substrate. Substrate-level guarantees, so that properties like ordered execution, scoped authority, and convergent state are enforced by the infrastructure rather than implemented by each agent individually. Collapsed bilateral complexity, so that agents interact through a shared substrate rather than through pairwise integration. Economic accessibility, so that organisations that cannot build their own agent coordination infrastructure can still run production agent workloads. The Grid is this coordination layer. It provides the substrate guarantees that production agents require: ordered execution, scoped authority, deterministic retry and rollback, persistent execution-linked memory, a canonical system of record, governed escalation, and convergent state. These are the agent equivalents of frequency stability, packet retransmission, and container scheduling. What does the universal grid actually coordinate? The term "universal grid" is an analogy to the power grid, and it holds at the structural level. A universal grid for agents coordinates the distribution of agent capabilities across a network of independent venues, in the same way that the power grid coordinates the distribution of electrical capacity across a network of independent generators. A venue is an execution environment operated by an independent organisation. It hosts agents, data, and operations. The Grid connects venues into a network where agents can discover and invoke capabilities across organisational boundaries, with the substrate enforcing execution guarantees regardless of which venue hosts the agent or the operation. The coordination is multi-dimensional. The Grid coordinates execution (ensuring operations complete correctly), state (ensuring shared data converges), authority (ensuring agents operate within their scopes), and governance (ensuring escalation policies are enforced). Each of these dimensions has its own failure modes, and the substrate addresses each through mechanisms adapted from prior coordination layers: lattice data structures for convergent state, cryptographic identity for scoped authority, and step-level execution tracking for deterministic retry. The timing question Every coordination layer in computing history appeared at a specific moment: after the underlying primitive was proven but before it reached the scale where coordination became mandatory. TCP/IP was finalised seven years before the World Wide Web. Kubernetes was released three years before container-based microservices became the dominant deployment pattern. The coordination layer must arrive before it is needed at scale, because building coordination infrastructure under production pressure produces fragile, organisation-specific solutions that calcify into technical debt. The organisations that adopted TCP/IP before they needed it were the organisations that built the web. The organisations that adopted Kubernetes before they needed it were the organisations that scaled their microservice architectures successfully. The timing question for agent coordination is whether the coordination layer is arriving early enough. Agents are already in production. They are already modifying shared state, triggering side effects, and operating concurrently. Most are running without substrate-level execution guarantees, accumulating the kind of subtle, intermittent failures that compound over time. Whether the industry adopts a shared coordination substrate before these failures become crises, or after, will determine how painful the transition is. The historical pattern suggests it will be after. The historical pattern also suggests that, after the transition, everyone will agree it was obvious all along. --- # Designing the Asset Model: How Covia Represents Agent Capabilities Published: 2026-08-21T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/designing-asset-model-covia-agent-capabilities The representation problem underneath every agent system Before a system can coordinate agents, retry their work, or hold them to account, it has to answer a plainer question: what can each agent actually do, and how is that written down? Most agent systems answer implicitly. A tool is a function registered in code. A capability is a line in a prompt. A data source is a connection string in config. The description of what an agent can do is scattered across the very artifacts that use it, and it exists in no single place you can point to, hand to another system, or compare against last week's version. That scattering is the quiet source of a surprising number of production problems. Two teams build the same capability twice because neither could discover the other's. An agent's behaviour changes because a tool it depends on changed underneath it, and nothing recorded that the dependency existed. A capability works in one environment and fails in another because the description of it lived in local config that never travelled. These are ordinary failures, and they are the everyday cost of representing capability implicitly. Covia's answer starts by making the representation explicit and giving it a name. In Covia, capability is an asset, and the asset model is how the system represents what agents, tools, and data can do so that the rest of the platform has something concrete to coordinate. What an asset is An asset is a content-addressed description of what an agent can do. It is a first-class object in the system, with an identity derived from its content, that describes a capability, a tool, a dataset, or a composed pipeline in terms the Grid can reason about. An agent does not hold its capabilities as private implementation detail. It publishes them as assets, and those assets become the unit the platform discovers, versions, composes, and governs. Three design decisions define the model: assets are content-addressed, assets are versioned, and assets are composable. Each decision solves a specific problem that implicit representation leaves open. Why content-addressing? The first decision is that an asset's identity comes from its content. Hash the description of the capability and the resulting fingerprint is the asset's address. Change anything about the description and the address changes with it. The reason to do this instead of assigning names or sequential IDs is that content-addressing makes identity independent of location and authority. A named registry needs an owner, a server, and a policy for who may claim which name. A content address needs none of that. The same capability described the same way produces the same address on any node, computed by anyone, with no coordination. Two teams that independently describe the identical tool arrive at the identical address and discover they built the same thing, without a central registry ever mediating the fact. Content-addressing also makes tampering evident by construction. If an asset's address is a hash of its content, you cannot alter what the asset claims to do while keeping its address. The address is a commitment to the exact description. Anything that references an asset by address references a specific, immutable description, and can verify it received exactly that. For a system whose purpose is holding agents accountable for what they do, capability descriptions that cannot silently change underneath a reference are foundational. The cost is that content-addressing feels rigid at first. You cannot edit an asset in place, because editing produces a different asset. That property turns out to be exactly what makes versioning coherent. Concretely, an asset gets a stable id you can resolve, invoke, and compose: Versioning without overwrites Because an asset is immutable and addressed by content, a new version of a capability is a new asset with a new address, leaving the old one untouched. The previous version keeps existing at its own address. Nothing that referenced it breaks. This inverts the usual failure mode of capability management. In a system where a tool is a mutable registry entry, upgrading the tool changes it for everyone at once, including every agent that was relying on the old behaviour and never asked to move. The upgrade is invisible until something downstream breaks and the investigation slowly discovers that a dependency shifted. With content-addressed assets, an upgrade publishes a new asset. Agents referencing the old address continue to get the old behaviour, deterministically, until they choose to reference the new one. The migration becomes explicit and per-consumer. It also gives the system an honest history. The chain of asset versions is a record of how a capability actually evolved, each version pinned to an immutable description. When an agent's behaviour changes, you can ask which asset version it was using and get a precise answer, because the version was never overwritten by the next one. Execution-linked memory and a canonical system of record depend on exactly this: the things an agent acted through have to be pinnable, and content-addressed versioning makes them pinnable by default. Composition as a first-class operation The third decision is that assets compose. An asset can be defined in terms of other assets, referencing them by their addresses, so a pipeline that chains three tools is itself an asset whose description names the three assets it depends on. This matters because real capabilities are rarely atomic. A useful agent capability is often a composition: retrieve, transform, validate, then write. Representing that composition as an asset in its own right, built from addressed sub-assets, gives the whole pipeline a single identity while keeping every dependency explicit and verifiable. The composed asset's address depends on the addresses of its parts, which means the composition is pinned end to end. You cannot swap a component underneath a pipeline without the pipeline's own address changing to reflect it. Composition over content-addressed parts also makes reuse safe in a way that copying never is. When a pipeline references a sub-asset by address, it gets that exact capability, immutable and verified, no matter who authored it or where it runs. A capability built by one team can be composed into a pipeline by another with no risk that the borrowed piece will shift underneath the borrower. The dependency is a precise reference to an immutable description, so reuse does not import a moving target. Discovery across the network Making capability explicit, addressed, and immutable pays off most at the level of discovery. Because an asset is a self-contained description with a location-independent address, it can be published and found across the network rather than trapped inside the one codebase that defined it. This is what turns a pile of individual agents into something a management layer can actually manage. When every capability an agent offers exists as a discoverable asset, the platform can answer questions that implicit representation makes impossible. What capabilities exist in this system. Which agents provide them. What a given pipeline depends on all the way down. Where a specific capability is used, so that the effect of changing it can be understood before it changes. None of these questions have good answers when capability lives in scattered config. All of them have precise answers when capability is an addressed, discoverable asset. Discovery also changes the economics of building. In a system where capabilities are discoverable assets, the default first move when you need a capability is to look for the asset that already provides it, because finding it is possible. The scattering that makes teams rebuild the same tool repeatedly is a discovery failure at root, and an explicit asset model removes the excuse for it. Assets and boundaries An explicit capability model is also what makes governance precise. If the platform is going to enforce what an agent may and may not do, it needs an exact object to attach that enforcement to. Assets are that object. A boundary is an execution limit, a defined edge an agent cannot cross without explicit authority. Boundaries are far easier to state and enforce when the things being bounded are addressed assets. An agent's scoped authority can be expressed as the specific assets it is permitted to invoke, named by address, verified at execution. A capability the agent was never granted is a capability whose asset it cannot invoke, and the enforcement is exact because the reference is exact. Vague authority statements about what an agent is "allowed to access" give way to precise grants over addressed capabilities. This is where the asset model connects back to the seven execution guarantees. Scoped authority, the canonical system of record, execution-linked memory, deterministic retry: each of them needs to name the thing an agent acted through, and each becomes sharper when that thing is a content-addressed, versioned, composable asset rather than an implicit reference to code that may have changed. The asset model is the representation layer the guarantees stand on. The decision underneath the decisions Every choice in the asset model traces back to one commitment: the description of what an agent can do should be an explicit, verifiable object in the system, with an identity that cannot drift. Content-addressing gives it an identity from its content. Versioning keeps every identity stable across change. Composition lets identities build on identities. Discovery lets them be found. Governance attaches to them precisely. The alternative, which most systems live with, is to leave capability implicit and pay for it later in duplicated work, silent dependency shifts, and audits that cannot reconstruct what an agent acted through. Making capability a first-class asset moves that cost forward, into the design, where it can be paid once. The open question the model raises is worth sitting with as agent systems grow. If a capability is only real to the platform once it is described as an asset, then the quality of everything above it, coordination, governance, accountability, depends on how faithfully agents describe what they can do. What does a system owe its own users when an agent's declared assets and its actual behaviour drift apart, and where should that gap be caught? --- # Runtime Policy Enforcement: Why Governance After Execution Is Not Governance Published: 2026-08-19T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/runtime-policy-enforcement-governance-after-execution The policy that fires too late Consider an agent executing a multi-step workflow. It reads data from a customer database, transforms it, and writes the result to an external partner's API. The organisation has a governance policy: customer data must not be sent to external systems without classification review. The agent completes the workflow. The governance layer evaluates the policy. The violation is detected. An alert fires. The data has already been sent. This is the fundamental problem with post-execution governance. The policy existed. The evaluation machinery worked correctly. The violation was detected. And none of it mattered, because the enforcement happened after the side effect occurred. The external API received the customer data. The partner's system ingested it. No amount of alerting can un-send the request. Runtime policy enforcement is the evaluation of governance rules during execution, before the side effect occurs. The policy is checked at the point where the agent is about to act, and the action is permitted or blocked based on the evaluation. The enforcement is synchronous with the execution. The distinction is binary. Either the governance rule was evaluated before the action and had the power to prevent it, or it was evaluated after the action and could only report on it. The first is enforcement. The second is monitoring. Calling monitoring "governance" is a category error that creates real risk for organisations deploying agents into production systems. Why does post-execution governance persist? The prevalence of post-execution governance is not a mystery. It is an engineering convenience. Synchronous policy enforcement adds latency to every action. It requires the governance layer to be available with the same reliability as the execution layer, because if the policy engine is down, either the action is blocked (reducing availability) or the action proceeds unchecked (reducing security). It requires governance rules to be expressed in a form that can be evaluated programmatically and quickly, which constrains the expressiveness of the policy language. Post-execution governance avoids all of these challenges. The agent acts at full speed. The governance layer processes events asynchronously, at its own pace, with no impact on execution latency or availability. Policies can be complex, involve human review steps, and take as long as they need. The architecture is cleaner. The separation of concerns is textbook. It is also insufficient. The entire value proposition of governance is that it prevents unacceptable outcomes. A governance system that detects without preventing is a reporting system. Reporting is valuable. Reporting is not governance. The engineering challenges of synchronous enforcement are real, and they are solvable. The organisational challenge, recognising that convenience has been prioritised over correctness, is harder. What runtime enforcement looks like in practice Runtime enforcement requires the governance layer to sit in the execution path. When an agent is about to perform an action, the execution pipeline evaluates all applicable governance rules before the action is dispatched. If the rules permit the action, it proceeds. If they prohibit it, the action is blocked and the agent receives a structured denial that explains which rule was triggered and why. This is how Covia's rule book operates within the Grid. The rule book is a set of governance policies expressed as executable rules that are evaluated at the point of action. The rules have access to the full context of the execution: the agent's identity, its delegated authority (via UCAN tokens), the specific action being attempted, the target resource, and the current state of the workflow. A rule might specify that agents with a particular authority scope cannot write to production databases outside of designated maintenance windows. Another might require that any action affecting customer PII triggers a classification check before proceeding. Another might enforce rate limits on the number of external API calls an agent can make within a single execution, preventing runaway behaviour from exceeding expected bounds. The critical property is that these rules are evaluated before the side effect occurs. The agent cannot bypass the evaluation because the rule book is part of the execution pipeline. The evaluation adds latency measured in milliseconds, an acceptable cost for the guarantee it provides. The difference between a gate and a camera The metaphor is physical. A security gate checks credentials before allowing entry. A security camera records who entered and generates alerts. Both are security infrastructure. They serve fundamentally different purposes. Post-execution governance is the camera. It records. It alerts. It enables investigation after the fact. Runtime enforcement is the gate. It prevents. It blocks. It ensures that only authorised actions proceed. Most organisations need both. The failure mode is deploying only the camera and calling it a gate. When the auditor asks "how do you prevent agents from violating governance policies?", the answer "we detect violations and alert on them" is not the same as "we evaluate policies before execution and block violations." The first is monitoring. The second is enforcement. How does this connect to the compliance landscape? The EU AI Act's requirements for high-risk AI systems include provisions for human oversight and the ability to intervene in the system's operation. The specific implementation is left to the deployer, but the intent is clear: there must be a mechanism to prevent the system from producing unacceptable outcomes. Detecting them after the fact is insufficient. SOC 2's trust service criteria include requirements for controls that prevent unauthorised access and changes. "Prevent" is the operative word. A control that detects without preventing is a detective control, valuable in a layered security model, insufficient as the primary governance mechanism for autonomous systems. The compliance frameworks are converging on a principle that should have been obvious from the start: governance of autonomous systems requires the ability to constrain their behaviour in real time. The autonomy is the feature. The constraint is the governance. If the constraint operates on a different timeline than the autonomy, the system is ungoverned for the duration of the gap. The architecture decision that determines governance posture Whether governance is runtime or post-execution is an architecture decision, not a configuration choice. It determines where the governance layer sits relative to the execution layer. It determines the failure modes (does governance unavailability block execution or permit unchecked action?). It determines what guarantees the organisation can make to auditors, regulators, and customers. Retrofitting runtime enforcement into an architecture designed for post-execution governance is possible but expensive. The execution pipeline must be modified to include synchronous policy evaluation. The policy engine must be elevated to the same availability and performance tier as the execution infrastructure. The governance rules must be re-expressed in a form suitable for synchronous evaluation. And the entire system must be re-tested to ensure that the added enforcement does not introduce unacceptable latency or availability regressions. Covia's Grid was designed with runtime enforcement as a foundational property. The rule book evaluation is part of the execution pipeline, built in at design time. This is a design-time decision that cannot be replicated by adding governance tooling to an execution platform that was not built for it. Enterprise organisations evaluating agent platforms should ask a direct question: does the platform enforce governance rules before or after the agent acts? The answer reveals whether the governance is structural or decorative. What remains unresolved Runtime enforcement solves the timing problem. It does not solve the completeness problem. The rules in the rule book are only as good as the governance team's understanding of what needs to be constrained. A perfectly enforced but incomplete policy set still leaves gaps. This is the deeper challenge: governance requires ongoing attention. The agents evolve. The workflows change. The threat landscape shifts. The governance rules must keep pace. Runtime enforcement ensures that the rules that exist are actually enforced. It does not ensure that the right rules exist. The organisation that has runtime enforcement and reviews its rule book quarterly is better governed than the organisation that has comprehensive post-execution monitoring and never updates its policies. The enforcement mechanism is necessary. It is not sufficient. Sufficiency requires the organisational discipline to treat governance as an ongoing engineering practice that continues well past deployment. Whether organisations will invest in that discipline before or after their post-execution governance fails to prevent a consequential violation is a question that each organisation answers through its actions, and each CISO answers for. --- # DIDs for Agents: Decentralised Identity in the Covia Grid Published: 2026-08-17T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/dids-for-agents-decentralised-identity-covia-grid Identity Is the First Problem a Multi-Agent System Hits Give one agent one task and identity barely registers. The agent runs inside a process you control, calls a tool with a key you issued, and the question of who it is never comes up. The moment a second agent appears, and especially the moment agents start invoking each other across systems owned by different teams, that quiet assumption breaks. Now the questions arrive at once. Which agent is calling? Is it the one it claims to be? On whose authority is it acting? When the work is done, who can prove which agent did what? These are not model questions. They are identity questions, and a multi-agent system cannot enforce authority, respect boundaries, or attribute actions without answering them first. In the Covia Grid, every agent carries a decentralised identifier. This post explains what that is, why the alternatives fail at scale, and what portable cryptographic identity makes possible across the synthetic workforce. What a DID Actually Is Most identity systems people know are registry-based. A central authority issues an identifier, holds the record of who owns it, and answers when someone asks whether it is valid. Usernames, API keys, and OAuth clients all work this way. There is a database somewhere, run by someone, and identity means having a row in it. That model has a structural cost. The registry is a single point of trust, a single point of failure, and a single point of control. Everyone who wants to verify an identity has to be able to reach it and has to trust whoever operates it. A decentralised identifier, or DID, is an identifier that a subject can create and control without a central registry, backed by cryptographic keys rather than a database row. A DID resolves to a small document listing the public keys and methods needed to verify that the holder controls the identifier. Control is proven by a signature that anyone can check against the published key. No issuing authority sits in the path. No central database has to be online for verification to work. The practical consequence: an agent can hold an identity that is genuinely its own, prove that identity to any counterpart, and do so without asking a shared authority for permission at the moment of proof. The identity travels with the agent instead of living in someone else's system. Why Do Registry-Based Identities Break Down for Agents? It is fair to ask why agents need anything new. Human-facing identity has run on central registries for decades. Why should a synthetic workforce be different? Scale and topology. Consider what a busy multi-agent system looks like. Agents are created and retired constantly, sometimes in seconds. They act on behalf of chains of other agents and humans. They cross organisational lines, invoking capabilities that live in systems the calling team does not own. The volume of distinct actors is orders of magnitude higher than any human directory was built for, and the trust relationships do not fit inside one company's boundary. A central registry buckles here on several fronts. It becomes a bottleneck. Every verification is a call to the same authority, and that authority sits on the critical path of every cross-system action. It becomes a trust problem across boundaries. When an agent in one organisation calls a capability in another, whose registry is authoritative? Neither team wants to depend on the other's database being correct and available. It becomes an attribution gap. Registry identities are easy to reassign and hard to prove after the fact. When you need to establish which agent performed an action weeks later, "it was authenticated at the time" is a weaker claim than a signature that still verifies. Decentralised identity dissolves these problems by removing the shared authority from the verification path. Each agent proves control of its own identifier cryptographically. Verification is a local check of a signature, not a remote call to a registry that has to be reachable and trusted. Identity as the Root of Authority Identity on its own is only an answer to "who is this." The reason it matters so much in the Grid is that everything downstream of authority hangs off it. An agent's DID is the anchor for what that agent is permitted to do. The authority model, expressed through a rule book, is written against identities. The execution limits an agent operates within, expressed as boundaries, are enforced against a verified identity. Attribution after the fact resolves back to the identity that signed the request. If the identity layer is weak, every layer above it inherits that weakness, because a permission granted to an identity that cannot be reliably proven is a permission granted to no one in particular. This is where DIDs and scoped authority meet. A DID establishes who an agent is. A capability token establishes what that specific identity is allowed to do, and for how long, without handing over standing credentials. We covered that mechanism in UCAN tokens and scoped authority; the relevant point here is that such tokens are issued to and signed by DIDs. Identity is the subject that authority is granted to. Take the identity layer away and scoped authority has nothing solid to attach to. Crossing Boundaries With Verifiable Trust The hardest case in a multi-agent system is the cross-boundary call: an agent in one venue invoking a capability that lives in another, across an organisational or trust line. A boundary is an execution limit that separates one trust domain from another, and you can read the fuller definition in the Covia glossary. Boundaries are where central-registry identity is least workable, because the two sides do not share an authority and have no reason to trust each other's internal records. Decentralised identity is built for exactly this crossing. When an agent presents a request across a boundary, the receiving side does not need to consult the sender's home registry or trust the sender's organisation to have authenticated correctly. It verifies a signature against the DID's published keys. The identifier is portable, so the same identity that meant something in the agent's home venue means the same thing on the other side of the boundary. Trust is established by cryptography that either side can check independently, rather than by a shared system both sides have to rely on. This is what lets the Grid extend across organisations without collapsing into a single administrative domain. Each participant keeps its own identity, proves it directly to whoever it interacts with, and carries that identity intact wherever its work takes it. Attribution That Survives the Event Coordination is not only about permitting actions in the moment. It is about being able to establish, afterward, what actually happened. In a system where dozens of agents act across multiple venues, attribution is a real operational requirement, not a compliance afterthought. DIDs make attribution durable because they make it cryptographic. When an agent acts, the action is tied to a signature from its identifier. That linkage does not depend on a log that could have been edited or a registry entry that may since have been reassigned. Months later, the same public key still verifies the same signature, and the action still resolves to the identity that produced it. For anyone operating a synthetic workforce under real accountability, this is the difference between a record you can stand behind and one you can only describe. The identity that acted is provable from the artefact of the action itself. What DIDs Give the Grid Put together, decentralised identity gives the Grid a foundation with a specific shape. Each agent holds an identity it genuinely controls. That identity is verifiable by anyone without a central authority in the loop. It is portable across venues and boundaries. It anchors the authority an agent is granted and the limits it operates within. And it produces attribution that outlives the moment of action. None of this requires a registry that every participant has to trust and keep online. That is the point. A coordination substrate meant to span organisations cannot rest its identity layer on a database owned by one of them. The design question this leaves open is worth sitting with. As the number of agents acting on your behalf grows from a handful to thousands, and as they start reaching across lines your systems do not control, what does it take to still be able to prove, cleanly, exactly which one did what? If the honest answer is a database and a hope that it was current, the identity layer is already the weakest part of the system. --- # Why Coordination Compounds Faster Than Intelligence Published: 2026-08-14T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/coordination-compounds-faster-than-intelligence The ceiling a better model cannot raise Swap the model under a single agent for a stronger one and the agent gets better at its task. Swap the model under a system of thirty agents and you have thirty agents that are each individually sharper and still colliding on the same shared record, still double-firing the same retry, still escalating into the same ownerless queue. The improvement is real and it is bounded. It raises the quality of each part while leaving the behavior of the whole untouched. That ceiling is where most of the interesting value now sits. For a decade the dominant lever on AI output was model capability, and pulling it worked because the systems were small enough that the model was the system. As deployments grow into many agents acting on shared infrastructure, the lever that moves output is no longer how well any single agent reasons. It is how well the agents coordinate. And coordination compounds in a way that intelligence does not. Why does coordination compound? A model improvement is additive. A better model lifts the quality of each task it touches, and the gains stack roughly in proportion to how many tasks you point it at. Useful, linear, predictable. Coordination is different because its value lives in the connections between agents, and connections grow faster than agents. When you add an agent to a coordinated system, you do not just add its output. You add every reliable interaction it can now have with every agent already present. The capacity of the system is a function of the interactions it can sustain without breaking, and that number climbs far faster than the headcount. This is the same structure behind every network that got more valuable as it grew. One telephone is useless. The second makes one connection possible. The hundredth makes thousands. The value was never in the individual handset. It was in the reachable set of other handsets, which grew combinatorially while the device count grew one at a time. Coordinated agents follow the same curve. The output of the system scales with the interactions it can hold together, and a coordination layer is what determines how many of those interactions survive contact with production. Contrast the two levers directly. Doubling model quality roughly doubles the quality of a given task. Doubling the number of agents a system can reliably coordinate can more than double its output, because each agent you add compounds against all the ones already there. One lever is linear in the parts. The other is superlinear in the connections. The coordination layer is where that superlinear return either gets captured or gets lost. What coordination compounds on The compounding is not automatic. Uncoordinated, adding agents makes things worse, because every new agent multiplies the ways the system can corrupt its own state. The combinatorial growth cuts both ways: it can be interactions that produce output or interactions that produce collisions. What decides which one you get is whether three specific things hold as the agent count rises. Shared state is the first. Agents that cannot see the same authoritative picture of the world act on stale or contradictory copies, and their outputs cannot be combined. When every agent reads from and writes to a canonical system of record, their work composes instead of conflicting. A read from any agent returns what actually happened, not what one agent happened to believe. Negotiated authority is the second. In a system where every agent can do anything, adding an agent adds risk faster than it adds value, because the blast radius of a mistake is the whole stack. When authority is scoped and enforced at execution time, so each agent operates inside a defined boundary and escalates when it reaches the edge, adding an agent adds capability without adding proportional risk. The rule book, not the goodwill of each agent, holds the system together. Convergent outcomes are the third. Concurrent agents will produce conflicting intermediate states. That is not a failure to prevent, it is a condition to resolve. A coordination layer provides convergent state: a defined way for many agents acting at once to settle on a single consistent outcome rather than leaving the system in a smear of half-applied changes. Without it, concurrency is a liability. With it, concurrency is throughput. When these hold, the Grid turns added agents into added output. When they do not, the same agents turn into a growing bill of race conditions and duplicated side effects. The infrastructure decides which curve you are on, and it decides it before the first extra agent is deployed. The compound effect exceeds the model gain Put the two trajectories side by side over time and the crossover is clear. A team that invests only in model quality gets a rising floor under each task and a flat ceiling over the system. Every model upgrade helps, and every upgrade helps a little less than the last as the returns to raw capability flatten. The system never gets bigger than what a few engineers can hold in their heads, because nothing underneath it makes concurrency safe. Better parts, same-sized whole. A team that invests in coordination gets a ceiling that rises with every agent it can reliably add. The model upgrades still land, on top of a system whose capacity is growing combinatorially rather than linearly. This is the meaning of the claim that coordination compounds faster than intelligence: over any horizon that matters, the returns to letting more agents work together reliably outrun the returns to making each one individually smarter. There is a definition worth stating plainly here. The coordination layer is the substrate that provides execution guarantees across many agents: ordered execution, scoped authority, deterministic retry and rollback, execution-linked memory, a canonical system of record, governed escalation, and convergent state. It is the thing that converts more agents into more output instead of more failure, and its return grows with the number of agents it holds together. A fuller treatment lives in the coordination layer glossary entry. Intelligence is a property of a part. Coordination is a property of the whole, and the whole is where the compounding happens. The strategic reading If the returns to coordination outrun the returns to intelligence past a certain scale, then the sequencing of investment matters more than most teams treat it. Betting everything on the next model is betting on the linear lever. It pays, and it pays less each cycle, and it leaves the superlinear lever untouched. The models will keep getting better, supplied by a handful of labs, available to everyone on roughly equal terms. That capability is becoming a commodity input. What will not commoditise on the same timeline is the ability to run many agents against shared production systems without the whole thing degrading into collisions. That ability lives in the coordination layer, and its value grows with the square of the thing everyone else is treating as free. So the question is not whether the next model will be smarter. It will be. The question is what a team is building underneath those models, and whether it is the linear bet that flattens or the compounding one that does not. --- # Why Retries in Non-Idempotent Tasks Duplicate Side Effects Published: 2026-08-12T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/retries-non-idempotent-tasks-duplicate-side-effects The shape of the problem An agent modifies a CRM record, sends a customer email, and updates an invoice. The invoice update fails. The framework retries the entire operation. The customer receives the email a second time. The CRM record is modified again, this time overwriting a change made by another agent in the interval between the first attempt and the retry. This is the default behaviour of any agent execution system that does not enforce idempotency at the substrate level. The agent did nothing wrong. The model reasoned correctly. The framework followed its retry policy. The failure is structural: the system retried an operation that had already produced irreversible side effects. What makes an operation non-idempotent? An idempotent operation produces the same result whether it executes once or multiple times. A database read is idempotent. Setting a field to a specific value is idempotent. An HTTP GET request is, by specification, idempotent. A non-idempotent operation produces additional effects on each execution. Sending an email is non-idempotent: sending it twice means the recipient receives two emails. Incrementing a counter is non-idempotent: incrementing twice produces a different result than incrementing once. Triggering a webhook is non-idempotent: the downstream system processes each invocation independently. Most agent operations in production environments are non-idempotent, because most useful agent operations involve side effects. An agent that only reads data and returns a summary is idempotent, but it is also limited. The value of production agents comes from their ability to act: modify records, send communications, trigger workflows, update external systems. Every one of these actions is a side effect. Every one of these side effects makes the operation non-idempotent unless specific countermeasures are in place. The countermeasure is an idempotency key: a unique identifier attached to each operation that allows the substrate to detect and suppress duplicate executions. When an operation is retried, the substrate checks whether an operation with that key has already completed. If it has, the substrate returns the stored result without re-executing the operation. The side effects happen exactly once. In the SDK, the operation runs through the venue, which is its system of record: How does retry duplication manifest in production? The CRM modification pattern Agent A reads a customer record, decides the customer should be upgraded to a premium tier, and writes the upgrade. The write succeeds, but the subsequent step (notifying the billing system) times out. The framework retries the entire task. Agent A reads the customer record again. It has already been upgraded. Depending on the agent's logic, one of two things happens. If the agent checks whether the upgrade has already been applied, it skips the write and proceeds. This is the optimistic case, and it requires the agent to be written with awareness of its own retry context. Most agent frameworks do not provide this context. The agent does not know it is retrying. It simply receives a task and executes it. If the agent does not check, it writes the upgrade again. In some systems, this is a no-op (setting a field to its current value). In others, the write triggers downstream effects: an audit log entry, a webhook to the billing system, a notification to the customer success team. Each of these downstream effects fires again on the duplicate write, regardless of whether the record itself changed. The email delivery pattern Agent B composes and sends a status update email to a client. The send succeeds. The agent then attempts to log the sent email in the CRM. The CRM API returns a 503. The framework retries the task from the beginning. Agent B composes and sends the email again. The client receives two identical emails. This pattern is particularly difficult to address at the application layer because email delivery is a fire-and-forget operation. Once the email is in the SMTP pipeline, it cannot be recalled. The only prevention is to never send it in the first place on a retry, which requires the substrate to know that the send step already completed. The deployment trigger pattern Agent C determines that a configuration change requires a redeployment. It triggers a deployment pipeline via API call. The pipeline starts. The agent's next step (updating the deployment record) fails due to a network partition. The framework retries. Agent C triggers the deployment pipeline again. Two deployments run concurrently on the same service, each believing it is the authoritative deployment. This failure mode compounds: the two concurrent deployments may interfere with each other, producing a state that neither deployment intended. The service may end up running a hybrid configuration that was never tested, never approved, and cannot be reproduced. Why can application-level deduplication not solve this? The standard engineering response to duplicate side effects is application-level deduplication. The agent checks whether the action has already been performed before performing it again. This approach has three structural weaknesses. First, it requires every agent to implement its own deduplication logic. Each agent must track which steps of its workflow have completed, persist that tracking across retries, and consult the tracking before each step. This is substantial engineering work that must be repeated for every agent, and a single omission produces a duplication bug that may not surface for weeks. Second, it requires the agent to have reliable state across retries. If the agent's own state is lost when it crashes (which is the common case, since most agent frameworks run agents as stateless functions), it cannot check whether a step has already completed. It must query external systems to infer its own execution history, which is fragile and incomplete. Third, it does not address the window between "action completed" and "completion recorded." If the agent sends an email and then crashes before recording that the email was sent, the next retry will find no record of the send and will send again. This window is irreducible at the application layer. It can only be closed by an atomic substrate operation that executes the action and records its completion in a single, indivisible step. What is the substrate-level solution? The substrate-level solution has three components: idempotency keys, step-level execution tracking, and atomic side-effect emission. Idempotency keys are unique identifiers assigned to each operation at the substrate level, before the agent begins execution. The key is deterministic: given the same task, the same agent, and the same input, the substrate generates the same key. When the substrate encounters a retry, it detects the duplicate key and short-circuits to the stored result. Step-level execution tracking means the substrate records the completion of each step within a multi-step operation, not just the operation as a whole. When a retry occurs, the substrate knows that steps 1 through 3 completed and step 4 failed. It resumes from step 4 rather than re-executing from step 1. The completed steps are not re-executed, so their side effects are not duplicated. Atomic side-effect emission means that when a step produces a side effect (sending an email, triggering a webhook, writing to an external system), the substrate records the emission and the step completion as a single atomic operation. There is no window between "side effect emitted" and "emission recorded." If the atomic operation fails, neither the emission nor the recording happens, and the retry executes the step cleanly. The Grid implements all three of these mechanisms at the substrate level. Agents running on the Grid do not need to implement their own deduplication logic. The substrate handles it, in the same way that TCP handles packet retransmission without requiring the application layer to deduplicate received data. How does this relate to the guarantees? Deterministic retry and rollback is the third of seven guarantees that production agent substrates must provide. It interacts directly with three of the others. Ordered execution ensures that retried operations are sequenced correctly relative to concurrent operations by other agents. Without ordering, a retry could interleave with another agent's modifications in a way that produces an inconsistent state, even if the retry itself is deduplicated. The canonical system of record ensures that step-level execution tracking persists reliably. If the execution tracking itself is stored in a system that can lose data, the guarantees collapse. The system of record must be at least as reliable as the operations it tracks. Convergent state ensures that the results of deduplicated operations merge correctly across distributed nodes. If Agent A's operation completes on Node 1 and the retry arrives at Node 2, convergent state ensures that both nodes agree on the final result without requiring Node 2 to query Node 1 synchronously. The economic argument Duplicate side effects have direct economic costs. Duplicate emails erode customer trust and trigger spam complaints. Duplicate CRM modifications corrupt sales data and pipeline forecasting. Duplicate deployment triggers waste compute resources and risk service outages. Duplicate financial transactions create accounting discrepancies that require manual reconciliation. These costs are often invisible in development and staging, because test environments rarely have the concurrency, failure rates, and side-effect consequences of production. A team that tests an agent by running it once on a clean dataset will never observe a retry duplication bug. The bug only manifests under production conditions: concurrent load, intermittent network failures, external API rate limiting, and partial completion of multi-step workflows. The economic argument for substrate-level idempotency is that the alternative is accepting that every agent operation in production has a non-zero probability of duplicating its side effects on every retry, with costs that compound across every agent and every operation, continuously. What about operations that are inherently non-idempotent? Some operations cannot be made idempotent even with substrate-level support. A physical robot picking up an object cannot "un-pick" it. A financial transfer that has already settled cannot be deduplicated after the fact. A published social media post cannot be unseen. For these operations, the substrate must provide a different guarantee: execute-at-most-once semantics. Rather than retrying the operation, the substrate records the failure and escalates to a governed escalation path. A human or a supervisory agent reviews the failed state and decides whether to retry, compensate, or abort. Execute-at-most-once is more conservative than execute-exactly-once. It accepts that some operations may fail permanently rather than risk duplication. For operations with high side-effect costs (financial transactions, legal communications, irreversible physical actions), this is the correct trade-off. Better to fail and escalate than to succeed twice. The substrate's responsibility is to make this trade-off explicit and configurable. An organisation that deploys agents to send marketing emails may accept execute-at-least-once semantics (a duplicate email is annoying but not catastrophic). An organisation that deploys agents to execute financial transactions requires execute-at-most-once semantics (a duplicate transaction is a regulatory incident). The substrate must support both, and the choice must be a configuration decision rather than an architectural constraint. The deeper question Idempotency in agent systems is a specific instance of a broader problem: the interaction between probabilistic reasoning and deterministic execution. Agents reason probabilistically. They make decisions based on context, heuristics, and model outputs that are inherently non-deterministic. But the systems they act upon are deterministic. A database commits or it does not. An email is sent or it is not. A deployment triggers or it does not. The substrate sits at the boundary between these two domains. It accepts non-deterministic instructions from the reasoning layer and translates them into deterministic operations on external systems. The idempotency guarantee is one expression of this translation: ensuring that the deterministic execution layer produces exactly the intended effects, regardless of how many times the non-deterministic reasoning layer requests them. Whether this boundary is the right place to enforce determinism, or whether the reasoning layer itself should become more deterministic, is a question that the field has not yet settled. The practical answer, for now, is that production systems cannot wait for probabilistic reasoning to become reliable. They need a deterministic substrate today, and the agents can improve on their own schedule. --- # Four Types of Agent, One Execution Substrate Published: 2026-08-10T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/four-types-agent-one-execution-substrate "Agent" is one word for four different jobs The word "agent" now describes a system that pulls one field out of a PDF and a system that runs unsupervised for an afternoon coordinating with other systems to close a deal. They wear the same label and share almost none of the same risks. One can be retried without much thought. The other, retried carelessly, can repeat an action that moves money. Teams that treat all agents as a single category end up mismatching their safeguards: heavy governance wrapped around trivial tasks, thin oversight around genuinely open-ended ones. A more useful approach sorts agents by two questions. How much does the agent decide on its own? How much does it coordinate with other agents? Those axes produce four working types. Each has a distinct execution profile, which is the specific pattern of what goes wrong when the agent stops reasoning and acts. And each of the four, for reasons that converge, depends on the same guarantees from the substrate it runs on. Covia's agent model treats these four as one family running on shared execution infrastructure. The taxonomy below explains why that is the right shape. The task agent A task agent performs a single, bounded operation and stops. It extracts a value, classifies a ticket, summarises a document, transforms one format into another. One input, one output, a short life. Its execution profile is dominated by two risks. The first is silent incorrectness: the output looks plausible and is wrong, and nothing downstream catches it. The second appears at scale. When a task agent writes to a system and gets retried after a timeout, the write can happen twice. A summary duplicated is harmless. A row inserted twice is a data integrity incident. The humble task agent inherits real risk the moment its single action has a side effect in the world. The workflow agent A workflow agent executes a defined sequence of steps with order and dependencies between them. Pull the record, check eligibility, update the account, notify the customer. The steps are known in advance, and they matter in sequence. Its execution profile centres on partial completion. Step four fails after steps one through three have already changed real systems. Now the world sits in a half-finished state that no single step is responsible for cleaning up. Without a defined way to resume from the failure point or unwind the earlier steps, someone reconstructs the mess by hand. Workflow agents need ordered execution and clean rollback more than they need cleverness. The autonomous agent An autonomous agent is given a goal and chooses its own steps toward it, running for minutes or hours without step-by-step supervision. It plans, acts, observes the result, and plans again. Research, investigation, open-ended remediation. Its execution profile is defined by drift and scope. Because no one wrote the steps in advance, the agent can reach for actions no one anticipated when it started. It rarely fails loudly. The sharper danger is that it succeeds at something no one meant to authorise. This class of agent needs hard limits on what it may touch, a defined path for escalating when it reaches those limits, and a durable record of every action it took, because after a long autonomous run the record is the only way to know what actually happened. The collaborative agent A collaborative agent works as one of several, dividing labour, sharing state, and handing work off to peers. A team of agents processing a claim, each owning a part, passing intermediate results between them. Its execution profile is dominated by concurrency and contention. Two agents read the same record and both act on it. Two agents update the same field with different values. Work handed off arrives before the receiving agent is ready, or arrives twice. These are the classic hazards of distributed systems, and they appear the moment agents stop working alone. Collaborative agents need the system to resolve concurrent action into one consistent state rather than a pile of conflicting writes. Why four stacks is the wrong instinct Seeing four distinct profiles, the natural engineering instinct is to build four solutions. A lightweight harness for task agents. A workflow engine for sequences. A sandbox with guardrails for autonomous agents. A message bus and locking scheme for collaborative ones. Four stacks, each tuned to its class. This falls apart for a reason visible in any real deployment: agents do not stay in their category. A task agent that extracts invoice data gets wired into a workflow. A workflow agent gains a step where it decides for itself which branch to take, and quietly becomes autonomous inside that step. An autonomous agent starts handing subtasks to helper agents and becomes collaborative. The categories describe how an agent is behaving right now, and behaviour shifts as systems grow. Four separate stacks means every one of these transitions is a migration across infrastructure, and the seams between the stacks are exactly where guarantees leak. The categories are real and worth understanding. Building four disconnected foundations underneath them multiplies the surface where things break. One substrate, four profiles The alternative is a single execution substrate that provides guarantees strong enough to cover all four profiles at once. This is the position the Grid takes. Rather than tailoring a different foundation to each agent type, it applies one set of execution guarantees to every agent, and those guarantees happen to answer every profile's dominant risk. Trace the mapping directly: Ordered execution answers the collaborative agent's contention problem and the workflow agent's sequencing problem. Actions on shared resources cannot interleave into corruption. Deterministic retry and rollback answers the task agent's double-write risk and the workflow agent's partial-completion risk. A failed action has one defined outcome. Scoped authority answers the autonomous agent's scope problem. An agent cannot act outside its grant, however its own reasoning arrived at the attempt. Governed escalation answers the autonomous agent's need to stop and ask. Reaching the edge of authority routes to a defined path rather than a silent overstep. Execution-linked memory answers the collaborative agent's shared-state problem. What an agent believes stays tied to what actually executed. Canonical system of record answers every profile's accountability problem. After the fact, there is one authoritative account of what happened. Convergent state answers the collaborative agent's core hazard. Concurrent action resolves through convergent consensus into a single consistent state. No agent implements these for itself. A task agent gets rollback it never wrote. A collaborative agent gets convergent state it never coordinated. The guarantees are properties of the venue, which means an agent moving from task to workflow to collaborative behaviour carries them the whole way, with no migration and no seam to leak through. A fleet in one afternoon Picture a single afternoon inside a claims operation. A task agent reads incoming documents and extracts amounts. A workflow agent walks each claim through eligibility, adjustment, and approval. An autonomous agent investigates the handful of claims that look irregular, deciding for itself which records to pull. A team of collaborative agents splits the approved claims across payment, notification, and ledger updates. All of this runs at once, on the same data, in the same minutes. Every profile's failure mode is live in that afternoon. The extraction agent could double-write on a retry. The workflow could stall halfway. The investigator could reach for a record outside its remit. The payment agents could collide on the same claim. Underneath them, one substrate is holding ordered execution, scoped authority, deterministic rollback, and convergent state for all of them at once. No agent asked for these properties by name. They hold because every agent runs in the same venue. Which type is your agent, really? The honest answer for most systems is: more than one, and changing over time. This is why sorting agents into the taxonomy matters less as a filing exercise and more as a way to see the union of risks a real deployment carries. A fleet running all four types at once faces every profile's failure mode simultaneously. Silent double-writes, half-finished sequences, out-of-scope autonomous actions, and concurrent contention do not arrive on separate days. In a busy system they arrive together. A substrate that only handled one profile well would force every agent that drifts out of that profile back into hand-built safety code. A substrate that handles all four lets an agent be whatever the work needs it to be this week. The design goal is to make the agent's category a description rather than a constraint. Four types, one workforce Step back from the individual agent and the reason for a common substrate sharpens. An organisation running task agents, workflow agents, autonomous agents, and collaborative agents has one workforce with a range of roles, the same way a company employs people who do bounded repetitive work and people who operate with wide discretion, all under one system of employment, accountability, and record. A synthetic worker is an agent operating as managed workforce, held to account for what it does regardless of how autonomous or collaborative its role happens to be. Covia positions itself as the management layer for that workforce, and management only holds if it reaches every role. The extraction agent and the multi-hour autonomous investigator answer to the same system of record, inherit the same limits, and resolve to the same consistent state when they touch the same data. So the taxonomy is worth keeping, as long as it is used for the right thing. It tells you what a given agent can do to your systems when it acts. What it should not tell you is how many execution foundations you need to build. If your task agents, workflow agents, autonomous agents, and collaborative agents all run on guarantees strong enough for the riskiest of them, the interesting question stops being which type each agent is. It becomes: what happens the day one of them changes type in production, and does anything underneath it have to change at all? --- # The CISO's Blind Spot: Agents Acting Without a System of Record Published: 2026-08-07T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/ciso-blind-spot-agents-without-system-of-record The question no one is asking yet When a security incident involves a human employee, the investigation follows a well-established path. Access logs show which systems the employee accessed. Change management records show what modifications were approved. Authentication records show when and from where the employee logged in. The CISO can reconstruct a timeline, identify the scope of impact, and present findings to the board with confidence. When a security incident involves an AI agent, the same investigation hits an immediate obstacle. There is no single, authoritative record of what the agent did. The agent's actions are distributed across LLM provider logs (which may be controlled by a third party), tool invocation records in various downstream systems, application-level telemetry, and whatever custom logging the development team chose to implement. Each of these sources captures a partial view. None of them is authoritative. None of them was designed to serve as evidence. This is the blind spot. Most organisations deploying AI agents have instrumented them for observability, the ability to monitor performance, debug failures, and understand behaviour. Very few have instrumented them for accountability, the ability to prove what the agent did, in what order, under whose authority, with evidence that would satisfy an auditor or a regulator. The CISO is the person who will be asked to explain the difference. Why is this a governance gap and not a logging gap? The instinct when confronted with this problem is to add more logging. Instrument the agent more thoroughly. Capture every LLM call, every tool invocation, every intermediate decision. Aggregate it all in a centralised logging platform and build dashboards. More logging does not close the gap. The gap is structural. A system of record is the authoritative source for a specific category of data, the source that is canonical, contemporaneous, tamper-evident, and complete. When there is a discrepancy between the system of record and any other source, the system of record wins. Logs, however comprehensive, do not meet this standard. Logs are written asynchronously. There is a window between the action and the log entry in which the action exists without a record. Logs can be rotated, truncated, or overwritten by retention policies. Logs from different systems may use different timestamp sources, making causal ordering ambiguous. And critically, most logging infrastructure provides no cryptographic guarantee that the records have not been modified since creation. An auditor examining a log-based reconstruction of agent activity will ask reasonable questions. How do you know this log entry corresponds to this action? How do you know no log entries were lost during aggregation? How do you know the timestamps are synchronised across systems? How do you know the logs have not been altered? The honest answer, for most agent deployments, is that you do not know. You believe it is accurate. Belief is not evidence. The governance gap is the distance between "we can probably reconstruct what happened" and "we can prove what happened." Every organisation deploying agents into production systems exists somewhere on that spectrum. The CISO's job is to know where. The accountability question for agent actions When an agent modifies a production system, three questions arise simultaneously. What did the agent do? Under whose authority did it act? Was the action within the scope of that authority? Traditional security infrastructure answers the first question reasonably well, through observability tooling and log aggregation. It answers the second question poorly, because the delegation of authority from human to agent is typically implicit (embedded in service account permissions provisioned at deployment time) rather than explicit (recorded as a verifiable delegation chain for each action). It does not answer the third question at all, because evaluating whether an action was within scope requires knowing what the scope was, which requires a record of the authority grant that most systems do not maintain. This is the gap that keeps the CISO up at night, or should. An agent with a broadly provisioned service account can perform any action within its role's permissions. If it performs an action that is technically permitted but operationally inappropriate, the organisation has no record showing that the specific action was within the intended scope of delegation. The permissions allowed it. The audit trail (if one exists) shows it happened. But no record connects the action to a specific human decision to authorise that specific category of action. The audit trail problem and the authority problem are two faces of the same governance gap. Without an authoritative record of actions, you cannot prove what happened. Without an explicit record of delegated authority, you cannot prove it was authorised. Without both, you have agents acting in production without accountability. What regulators will ask The EU AI Act introduces specific obligations for high-risk AI systems, including requirements for logging, traceability, and human oversight. SOC 2 Type II requires organisations to demonstrate that they maintain controls over system access and changes. ISO 27001 requires an information security management system that includes access control, audit logging, and accountability measures. Each of these frameworks will be interpreted and applied to agent systems as deployments scale. The specific requirements vary, but the common thread is clear: the organisation must be able to demonstrate that it maintained authoritative records of consequential actions, that it controlled access to systems through appropriate mechanisms, and that it can attribute actions to specific actors under specific grants of authority. The CISO who says "we have comprehensive observability" will be asked to demonstrate that observability constitutes an authoritative record. The CISO who says "we control agent permissions through IAM" will be asked to demonstrate that the permissions granted were appropriate for the specific actions taken, not just that the role had sufficient privileges. The CISO who says "we can reconstruct the timeline" will be asked why the record needed to be reconstructed rather than retrieved. These are the standard questions that auditors ask about any system that modifies production data. The only difference is that the actor is an agent rather than a human, and the existing infrastructure was not designed for that distinction. What closing the gap requires Closing the governance gap for agent systems requires three structural capabilities that most deployments currently lack. The first is a system of record for agent actions, an authoritative, contemporaneous, immutable record of what each agent did, with cryptographic integrity guarantees. This record must be created at execution time, as part of the execution, with no asynchronous gap between action and record. Covia's Grid creates this record as a first-class product of every agent execution. The second is explicit, verifiable delegation of authority. When an agent acts, the record must include not just what it did but under whose authority it acted, with a cryptographic proof chain connecting the action to a human decision. This is what scoped authority mechanisms like UCAN tokens provide: a verifiable chain from the human who authorised the action, through any intermediate delegation, to the agent that performed it. The third is runtime policy enforcement, the ability to evaluate governance rules before the agent acts. If the governance check happens after the action, the check is diagnostic rather than preventive. Enterprise deployments require governance that prevents violations. The conversation the CISO needs to have The typical agent deployment today follows a pattern. An AI team builds an agent, provisions it with a service account, instruments it with logging, deploys it to production, and monitors it through dashboards. The security team reviews the architecture, ensures the service account permissions are reasonable, and approves the deployment. Everyone moves on. The conversation that needs to happen, and usually does not, is about the gap between what the security infrastructure captures and what an auditor will require. The logging captures events. The auditor will require evidence. The IAM controls capture permissions. The auditor will require authority chains. The monitoring captures anomalies. The auditor will require proof of policy enforcement. This conversation is uncomfortable because it exposes the fact that the organisation's agent governance posture, regardless of how sophisticated its observability stack, may not survive an audit. The agents are already acting in production. The governance infrastructure has not caught up. And the person who will be asked to account for that gap is the CISO. The question is whether this conversation happens proactively, while there is time to close the gap, or reactively, after an incident makes the gap visible to everyone outside the security team. --- # Lattice Consensus Without Leader Election: How the Covia Grid Converges Published: 2026-08-05T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/lattice-consensus-without-leader-election-convex-covia The consensus problem, restated Distributed systems require consensus: a mechanism for multiple nodes to agree on the current state of shared data. For four decades, the standard approach to distributed consensus has been leader election. One node is elected leader, the leader orders all state transitions, and follower nodes replicate the leader's decisions. Paxos (1989) and Raft (2014) are the canonical protocols, and they underpin nearly every production distributed system from databases to message queues to coordination services. Leader election works. It has been proven correct, battle-tested in production, and optimised to remarkable performance levels. It also has structural properties that make it a poor fit for the coordination substrate of a multi-agent system. A leader is a single point of serialisation. All state transitions flow through the leader, which means the leader's throughput is the system's throughput ceiling. A leader is a single point of failure during election. When the leader fails, the system halts until a new leader is elected, which takes anywhere from milliseconds to seconds depending on the protocol and the network conditions. A leader creates an asymmetry between nodes: the leader processes writes, followers process reads (if at all), and the system's operational characteristics depend on which node is currently leader. For a traditional distributed database, these properties are acceptable trade-offs. The leader's throughput is sufficient for the workload. Leader election is fast enough that clients experience only brief interruptions. The asymmetry between leader and followers is manageable because the system operator controls all nodes. For a coordination substrate spanning independent organisations, operating across geographic boundaries, with heterogeneous node capabilities and no central operator, leader election introduces problems that the protocol was not designed to solve. Why does leader election conflict with multi-venue coordination? The Grid coordinates agent execution across venues operated by independent organisations. A venue is an execution environment: it hosts agents, data, and operations. Venues are independently operated, independently scaled, and independently governed. No single organisation controls all venues. No single venue is more authoritative than any other. Leader election in this context requires one venue to be the leader for any given piece of shared state. This creates three structural problems. First, the leader venue has operational authority over all state transitions for the data it leads. Other venues must submit their modifications to the leader and wait for confirmation. If the leader venue is slow, overloaded, or unreachable, all other venues are blocked. In a system spanning multiple organisations and geographies, "unreachable" is a regular operating condition that the substrate must expect. Second, leader election requires participating venues to agree on an election protocol and to trust the election outcome. In a system where venues are operated by independent organisations, this trust is not given. An organisation that operates a venue has no reason to accept another organisation's venue as the authoritative leader for shared state, especially if the leader venue can observe, delay, or reorder the other organisation's state transitions. Third, leader election creates a centralisation pressure that contradicts the Grid's distributed architecture. Over time, the venues that most frequently serve as leaders accumulate operational importance, creating a de facto hierarchy in a system designed to be non-hierarchical. The venues that most frequently serve as followers become dependent on the leader's availability, creating a fragility that the distributed architecture was meant to eliminate. What is lattice consensus? Lattice consensus is an approach to distributed agreement that replaces leader election with deterministic merge semantics. Instead of electing a leader to order state transitions, every node applies state transitions locally and merges divergent states using a mathematically guaranteed merge function. The foundation is the lattice data structure. A lattice defines a partial order over values and a join (least upper bound) operation that combines any two values into a single value. The join operation is commutative (join(A, B) = join(B, A)), associative (join(join(A, B), C) = join(A, join(B, C))), and idempotent (join(A, A) = A). These properties guarantee that any set of values, merged in any order, produces the same result. In a lattice consensus system, there is no leader. Every node can accept state transitions. When nodes exchange their states (through gossip protocols, direct messaging, or periodic synchronisation), they merge the received state with their local state using the lattice join operation. Because the join is commutative, associative, and idempotent, all nodes converge to the same state regardless of message ordering, message duplication, or temporary network partitions. This is a different formulation of consensus, and the guarantee is fully preserved. Leader-based consensus says: "one node decides the order, all other nodes follow." Lattice consensus says: "every node decides locally, and the data structures guarantee that all local decisions compose into a consistent global state." How does the Grid implement lattice consensus? The Grid's consensus layer is built on lattice data structures with immutable state, deterministic merge functions, and a peer network protocol that propagates state across venues by convergent consensus. Immutable data structures All state in the Grid's consensus layer is represented as immutable values. A modification does not overwrite the previous state; it produces a new value that references the previous one. The complete history of a piece of state is preserved as a chain of immutable values, each pointing to its predecessor. Immutability provides two properties that lattice consensus requires. First, a node that has received a value can be certain that the value will never change. It is safe to merge, cache, and replicate. Second, the history of state transitions is preserved without explicit logging. The chain of immutable values is the log. This is the foundation of the canonical system of record that the Grid provides. Deterministic merge functions Each data type in the Grid's consensus layer has a defined merge function (the lattice join). For simple types, the merge function is straightforward: the join of two counters is the maximum of their values; the join of two sets is their union. For compound types, the merge function composes: the join of two maps applies the element-type join to each key present in either map. The merge functions are deterministic by construction. Given the same inputs, the merge produces the same output on every node, every time. There is no randomness, no tie-breaking by timestamp or node ID, and no application-level conflict resolution. The data structure's algebraic properties guarantee convergence. For cases where the default merge semantics are insufficient (for example, when a business rule requires that one agent's modification takes priority over another's), the Grid's consensus layer supports custom merge functions that preserve the commutative, associative, and idempotent properties while encoding domain-specific resolution logic. The Grid's consensus protocol The Grid's consensus protocol is the peer network protocol that propagates state across venues in the Grid. It combines lattice merge semantics with a validation protocol for ordering and validating state transitions. Each venue holds a commitment that represents its participation in the network. That commitment serves two purposes: it provides incentive alignment (venues that propagate valid state transitions are rewarded; venues that propagate invalid transitions are penalised), and it provides a partial ordering mechanism for state transitions that require more than lattice merge to resolve. The protocol operates in three phases. In the propagation phase, venues gossip their latest state to peers. In the merge phase, each venue merges received state with its local state using the lattice join. In the validation phase, venues verify that the merged state satisfies defined invariants (execution scopes, authority constraints, business rules) and reject or escalate transitions that violate them. The Grid's consensus protocol does not elect a leader. There is no distinguished node. Every venue participates in all three phases simultaneously. The commitment weighting determines how quickly a venue's state transitions propagate (higher-weighted venues' transitions propagate faster), but it does not determine which transitions are accepted. Acceptance is determined by the lattice merge function and the validation invariants, both of which are deterministic and applied identically on every venue. How does this differ from systems that require a single global total order? Some distributed systems require a single global total order across every transaction, which invites comparison with the Grid's consensus protocol, and the differences are fundamental. Systems built on a single global total order produce a total ordering of all transactions. Every node agrees on the exact sequence of every transaction that has ever occurred. This total ordering is necessary where the sequence of transactions determines the outcome, such as a financial ledger where order determines account balances. The Grid's consensus protocol does not produce a total ordering. It produces a partial ordering sufficient for lattice merge convergence. Two transactions that affect different state can be applied in either order. Two transactions that affect the same state are resolved by the lattice merge function, not by ordering them sequentially. Only transactions that require strict ordering (non-commutative operations on shared state) are serialised, and the serialisation is scoped to the specific state they affect, not applied globally. This difference has direct performance implications. Total-order consensus throughput is limited by the block time and block size, because every transaction must be included in the total order. Throughput in the Grid's consensus protocol is limited only by the merge rate for contended state. Non-contended state transitions propagate at network speed with no serialisation bottleneck. The other fundamental difference is finality. Total-order consensus typically provides probabilistic finality: a transaction becomes "more final" as more blocks are built on top of it. The Grid's consensus protocol provides deterministic finality through lattice merge: once a state transition is merged on a venue, the merged state is final. It cannot be reverted by subsequent merges, because the lattice join only moves state forward (upward in the lattice ordering). This property, called monotonicity, is what makes lattice consensus suitable for a coordination substrate where agents need to know, with certainty, that a state transition is permanent. What happens during a network partition? Network partitions are the critical test for any consensus protocol. When the network splits into two or more groups of nodes that cannot communicate with each other, the system must choose between availability (continue accepting operations on both sides) and consistency (reject operations until the partition heals). Leader-based consensus chooses consistency. The partition that contains the leader continues operating; the partition without the leader halts. This is the CAP theorem in practice: leader-based consensus sacrifices availability for consistency. The Grid's consensus protocol chooses availability with guaranteed convergence. During a partition, venues on both sides continue accepting state transitions and applying them to their local state. When the partition heals, venues exchange their states and merge them using the lattice join. Because the join is commutative, associative, and idempotent, the merged state is deterministic regardless of what happened on either side during the partition. This is possible because lattice data structures are specifically designed for convergent state. The merge function produces a consistent result from divergent inputs. The constraint validation layer, applied after merge, detects any invariant violations that arose from the concurrent operations and triggers escalation for resolution. The practical consequence is that the Grid never halts due to a network partition. Venues continue operating independently, agents continue executing, and the substrate guarantees that convergence occurs when connectivity is restored. For a coordination substrate spanning multiple organisations and geographies, partition tolerance is a hard requirement. How does lattice consensus interact with the seven guarantees? Lattice consensus provides the foundation for three of the seven substrate guarantees that production agents require. Convergent state (guarantee 7) is a direct consequence of lattice merge semantics. All venues converge to the same state for shared data, regardless of update ordering or network conditions. Ordered execution (guarantee 1) is implemented through a combination of lattice ordering and scoped serialisation. Operations that commute (most read-modify-write operations on independent fields) are ordered by the lattice partial order. Operations that do not commute (conflicting modifications to the same field) are serialised using commitment-weighted ordering within the Grid's consensus protocol. The serialisation scope is the specific state being modified, not the global transaction log. The canonical system of record (guarantee 5) is implemented through immutable data chains. Every state transition produces a new immutable value that references its predecessor. The complete history of every piece of state is preserved, queryable, and consistent across all venues. Because the values are immutable, the history cannot be altered after the fact. The remaining four guarantees (scoped authority, deterministic retry and rollback, persistent execution-linked memory, and governed escalation) are implemented at higher layers of the Grid's architecture, but they depend on the lattice consensus layer for their correctness. Scoped authority checks are validated during the consensus protocol's validation phase. Deterministic retry uses the immutable state chain to identify the exact point of failure. Persistent memory is stored as lattice state that converges across venues. Governed escalation policies are themselves lattice state that merges deterministically. What are the performance characteristics? Lattice consensus has different performance characteristics than leader-based consensus, and the differences favour multi-agent coordination workloads. Write throughput scales with the number of venues for non-contended state. Each venue can accept writes to local state without coordinating with any other venue. The writes propagate and merge asynchronously. For a system where most agent operations affect different state (different customer records, different workflow instances, different deployment targets), this means aggregate write throughput scales linearly with the number of venues. Write latency for non-contended state is local: the time to apply the write to the local venue's state. The write is immediately visible to agents on the same venue and propagates to other venues at network speed. For contended state (multiple agents modifying the same record concurrently), write latency includes the merge resolution time, which is bounded by the merge function's computational cost. Read consistency is configurable per operation. An agent can read from local state (fastest, may not reflect remote writes that have not yet propagated) or request a merged read (slower, reflects all known state transitions). The choice depends on the operation's consistency requirements, and the substrate makes the trade-off explicit rather than hiding it behind a single consistency model. Partition recovery time is proportional to the amount of state that diverged during the partition, not the duration of the partition. A five-minute partition during which 100 records were modified on each side requires merging 200 records. A five-minute partition during which 10 records were modified requires merging 20. The merge itself is computationally lightweight (lattice joins are O(n) in the size of the divergent state), so recovery is typically measured in milliseconds to seconds. The design trade-off Lattice consensus is specifically superior for the coordination substrate use case, where the participants are independent, geographically distributed, and operating without a central authority. It makes no claim to universal superiority over leader-based consensus. Leader-based consensus provides stronger guarantees for workloads that require total ordering. A financial trading system where the exact sequence of trades determines prices and positions needs total ordering. A multi-agent coordination substrate where most operations commute and only a small fraction require strict ordering does not. The trade-off is expressiveness versus availability. Leader-based consensus can express any ordering constraint (because it serialises everything), but it sacrifices availability during leader failure and partition. Lattice consensus can express ordering constraints only for operations that the lattice structure can represent, but it provides continuous availability and deterministic convergence. For the Grid, this trade-off is the correct one. Agent operations are predominantly commutative (different agents modifying different state). The minority of operations that require strict ordering are handled through scoped serialisation rather than global leader election. And the availability guarantee, that no venue ever halts due to a remote venue's failure or a network partition, is essential for a coordination substrate that spans independent organisations. Whether lattice consensus can scale to the throughput requirements of the largest agent deployments, where thousands of agents modify millions of state entries per second, is an empirical question that does not yet have a production-scale answer. The theoretical properties are sound. The implementation of the Grid's consensus layer has been validated at moderate scale. The question of whether lattice merge remains computationally tractable at extreme scale, where the size of the divergent state set grows faster than the merge function can process it, is the performance boundary that will determine the Grid's practical ceiling. --- # The Scaling Cliff: What Breaks When You Go from 3 Agents to 30 Published: 2026-08-03T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/scaling-cliff-what-breaks-3-agents-to-30 The demo that worked and the system that did not The first three agents almost always work. A team wires up a small system, gives each agent a clear job, points them at a shared database, and watches the whole thing run. It demos well. It handles real work. It creates the reasonable belief that the architecture is sound and the only thing left is to add more agents. Then they add more agents, and somewhere between the third and the thirtieth the system stops behaving like a bigger version of the demo and starts behaving like a different system entirely. Records go inconsistent. Actions fire twice. An agent does something no one authorised because nothing was stopping it. Nothing in the code got worse. The team crossed a threshold where the assumptions that held at three stopped holding, and the same architecture that looked sound became the source of the failures. That threshold is the scaling cliff, and AI-native teams tend to meet it right after they conclude they have the hard part solved. Why does three work and thirty break? At three agents, a human is the coordination layer. You know the order the agents should run in, so you arrange them in that order. You know which agent should own the billing system, so you give it access and trust the others to stay out. You know the retry logic is fragile, so you keep an eye on it. The system works because a person is holding its invariants in their head and enforcing them by hand. That approach has a hard limit, and the limit is not about effort. It is about combinatorics. The difficulty of coordinating a system is not driven by the number of agents. It is driven by the number of interactions between them, and interactions grow far faster than agents do. Three agents have three pairwise interactions, which one person can track. Thirty agents have hundreds, plus higher-order interactions where three or four agents touch the same resource in the same window. No amount of diligence tracks that, because the human coordinator was always the bottleneck and adding agents just made the bottleneck visible. The cliff is the point where implicit coordination, the kind a human does by paying attention, runs out. Everything that was being handled by attention now has to be handled by infrastructure, and if the infrastructure was never built, the failures arrive all at once. What actually breaks The failures at the cliff are specific and they recur across deployments, because they are properties of uncoordinated concurrency rather than bugs in any particular system. Ordering breaks first. At three agents you controlled sequence by hand. At thirty, agents act concurrently, and two of them read the same value, both decide to act, and the second silently overwrites the first. The shared record is now wrong and nothing logged the conflict. Every system that assumed a human was sequencing the work inherits this the moment the work goes parallel. Authority breaks next. Scoping access per task is tedious, so the shortcut is to give every agent that might need a system access to it. At three agents the blast radius is small. At thirty, every agent is a potential path to every sensitive system, and one confused agent can act across the entire stack. The convenience that was harmless at small scale becomes the largest risk in the deployment. Retries turn dangerous. A step fails partway, a retry re-runs it, and an action meant to happen once happens twice. Reading a record twice is harmless. Issuing a refund twice, sending a message twice, or provisioning a resource twice is not. Naive retry logic that was fine when a human was watching becomes a source of duplicated side effects when there are too many agents to watch. The system of record dissolves. With thirty agents each carrying their own context, the same fact lives in thirty places and no two of them agree. There is no authoritative answer to what happened, which makes failures nearly impossible to debug. You cannot reconstruct the history because there is no single history to reconstruct. Escalation has nowhere to go. When an agent hits something it should not resolve alone, it needs to hand off. Without a defined escalation path, the handoff either does not happen, and the agent acts anyway, or it lands in a queue no human owns. Edge cases that a person would have caught at three agents fall through the gaps at thirty. Each of these is one of the execution guarantees failing in a specific way. Ordering is ordered execution. Authority is scoped authority. Retries are deterministic retry and rollback. The record is the canonical system of record. Escalation is governed escalation. The cliff is simply what it looks like when guarantees that a human was providing informally are suddenly required formally, and are not there. Why more engineering does not fix it The instinct at the cliff is to patch. Add a lock around the shared record. Wrap the fragile step in better retry logic. Write an access rule for the agent that misbehaved. Each patch addresses the specific failure that just happened, and each one is a piece of the coordination layer, rebuilt by hand, in isolation, under pressure. This is the expensive path. A team that patches its way up the cliff ends up building a coordination substrate anyway, one incident at a time, without the design that would make it coherent. The homegrown lock does not know about the homegrown retry logic. The access rules accrete into something no one fully understands. The system of record is still just whichever database got written to last. The team has paid for a coordination layer and received a pile of glue code that happens to survive the failures it has seen so far. The alternative is to treat coordination as infrastructure that exists before the agent count rises, rather than as a series of repairs after it does. Execution guarantees are the properties a multi-agent system needs to hold as it scales: ordered execution so concurrent actions commit consistently, scoped authority so each agent acts inside an enforced boundary, deterministic retry and rollback so failure does not duplicate effects, execution-linked memory and a canonical system of record so there is one authoritative history, governed escalation so edge cases reach a human, and convergent state so concurrent agents settle on one outcome. They are the guarantees a human was providing informally at three agents, made explicit and enforced by the layer so they still hold at thirty. A layer that provides these does not care whether there are three agents or three hundred. Ordering holds because the layer sequences commits, not because a person arranged the agents. Authority holds because the Grid enforces each boundary at execution time, not because everyone remembered to stay in their lane. The guarantees are properties of the substrate, so they do not degrade as the agent count climbs. The whole point is that the cliff stops being a cliff. The question before you scale The scaling cliff is not a warning against adding agents. Added agents are where the value is. It is a statement about what has to be true underneath them before the value shows up instead of the failures. The uncomfortable part is that the demo gives no signal. Three agents on a shared database will run cleanly right up to the edge, which means the architecture that is about to break looks identical to the architecture that will scale. The difference is invisible until the agent count crosses the threshold, and by then the choice is to patch upward at rising cost or to have built the layer first. So before the next batch of agents goes into production, the question worth answering is not whether they work in the demo. It is whether ordering, authority, retries, the record, and escalation are guaranteed by something other than a person paying attention, because that person does not scale, and the agents are about to find out. --- # UCAN Tokens and Scoped Authority for AI Agents Published: 2026-07-31T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/ucan-tokens-scoped-authority-ai-agents The permissions problem no one designed for Every AI agent acting in a production environment needs permissions. It needs access to tools, APIs, databases, and external services. The standard approach is familiar: assign the agent a service account, attach a role with the necessary permissions, and manage those permissions through the same identity and access management (IAM) infrastructure used for human users and application services. This works until it does not. The failure mode is specific: IAM was designed for relatively static permission assignments. A human user gets a role when they join a team and keeps it until they leave. A service account gets permissions when it is provisioned and keeps them until it is decommissioned. The permissions are coarse-grained by necessity, because managing fine-grained permissions for every possible action is administratively untenable at scale. AI agents break this model in three ways. First, agents act dynamically. An agent coordinating a multi-step workflow may need different permissions at each step, and the specific permissions needed may depend on decisions made during earlier steps. Second, agents delegate. An agent may invoke sub-agents, each of which needs its own scoped permissions derived from the parent agent's authority. Third, agents operate at machine speed. The time between granting a permission and exercising it may be milliseconds, making manual approval workflows impractical. The result is that most agent deployments either over-provision permissions (granting broad access to avoid runtime failures) or under-provision them (restricting access so tightly that the agent cannot complete legitimate tasks). Neither outcome is acceptable in a production environment where the agent is modifying real systems on behalf of real users. What are UCAN tokens? A UCAN (User Controlled Authorisation Network) token is a self-certifying, delegatable authorisation token based on signed JSON Web Tokens (JWTs). Unlike traditional access tokens issued by a central authority, UCANs are created and signed by the entity that holds the authority, enabling decentralised delegation without requiring a round-trip to an authorisation server. The issuer is the entity granting the authority. This is identified by a decentralised identifier (DID) and authenticated by a cryptographic signature. The audience is the entity receiving the authority. The capabilities define what the recipient is authorised to do, expressed as resource-action pairs with optional caveats that further constrain the scope. The expiry sets a time boundary on the authority. The proof chain links the token to its parent authorisation, creating a verifiable delegation chain back to the root authority. What makes UCANs particularly relevant for agent systems is the delegation model. A human user can create a UCAN that grants an agent permission to perform specific actions on specific resources for a specific duration. That agent can then create a child UCAN that delegates a subset of its authority to a sub-agent. At no point can any entity in the chain grant more authority than it holds. The permissions can only narrow as they flow through the delegation chain, never widen. This is a structural guarantee enforced by cryptography. The cryptographic signatures and the proof chain make it mathematically verifiable that no entity exceeded its authority. An auditor can inspect any UCAN token and trace the complete chain of delegation back to the human who initiated it. How does scoped authority differ from access control? Access control answers the question "is this identity allowed to access this resource?" Scoped authority answers a different and more specific question: "is this identity allowed to perform this action on this resource, under this delegation, with these constraints, until this time?" The distinction matters because access control is binary (allowed or denied) while scoped authority is dimensional. A UCAN token does not simply grant access to a billing API. It might grant permission to read invoices from a specific account, created within a specific date range, for the purpose of generating a quarterly summary, with the authority expiring in fifteen minutes. Every dimension of the scope is encoded in the token itself, verifiable without consulting an external authority. Traditional access control systems can approximate this level of granularity through attribute-based access control (ABAC) policies, but the policy evaluation happens at a central policy decision point. The agent presents its credentials, the policy engine evaluates the rules, and the decision is made at runtime. If the policy engine is unavailable, the decision cannot be made. If the policy is misconfigured, the agent gets the wrong permissions. The authority lives in the policy engine. With UCANs, the authority lives in the token. The token is self-certifying: any party can verify its validity, its scope, and its delegation chain without contacting a central authority. This is what makes it practical for distributed agent systems where agents may be executing across organisational boundaries, on different infrastructure, through different tool providers. Delegation chains: from human to agent to sub-agent Consider a concrete scenario. A financial controller authorises an AI agent to reconcile accounts payable for Q1 2026. The agent needs to read invoice data from the ERP system, cross-reference it with payment records from the banking API, identify discrepancies, and generate a reconciliation report. To handle the volume, the agent delegates the invoice retrieval to a specialised sub-agent and the payment record retrieval to another. In a traditional IAM model, each of these agents needs its own service account with its own role assignments. The financial controller's authorisation is implicit: someone approved the role assignments at provisioning time, perhaps weeks or months ago, with no direct connection to this specific task. With UCAN delegation, the chain is explicit and verifiable. The financial controller creates a root UCAN granting the reconciliation agent permission to read accounts payable data for Q1 2026 and to generate reconciliation reports. The reconciliation agent creates a child UCAN for the invoice sub-agent, scoping it to read-only access on invoice data for Q1 2026, with no write permissions and no access to payment records. It creates another child UCAN for the payment sub-agent, scoped to read-only access on payment records for Q1 2026. Each token in this chain is cryptographically signed by its issuer. Each token's capabilities are provably a subset of its parent's capabilities. The complete chain is auditable: from the financial controller's root authorisation, through the reconciliation agent's delegation decisions, to the specific permissions each sub-agent held when it accessed the underlying systems. The delegation is a scoped, time-boxed UCAN the venue verifies on every call: Revocation semantics: withdrawing trust at runtime Revocation in hierarchical systems is straightforward in principle and difficult in practice. The principle is clear: when trust is withdrawn from any point in the delegation chain, all authority derived from that point must cease to be valid. The difficulty lies in propagation. How quickly does the revocation take effect? What happens to actions that were authorised before the revocation but have not yet completed? UCAN revocation operates through a combination of expiry and explicit revocation lists. Short-lived tokens (with expiries measured in minutes rather than hours or days) limit the window of exposure. When a token expires, it simply stops being valid. No propagation delay, no race condition, no stale permissions. For cases where immediate revocation is necessary, Covia maintains a revocation registry within the Grid's lattice data structure. When a UCAN is revoked, the revocation is recorded in the lattice and propagated to all venues participating in the execution. Any venue that receives an action authorised by a revoked UCAN will reject it, even if the token has not yet expired. How scoped authority connects to the rule book The rule book is Covia's abstraction for encoding governance policies as executable rules that are evaluated at runtime. Scoped authority through UCAN tokens and rule book enforcement are complementary mechanisms that operate at different layers of the same problem. UCAN tokens define what an agent is authorised to do. The rule book defines the conditions under which that authority may be exercised. An agent might hold a UCAN granting it permission to modify customer records, but the rule book might specify that customer record modifications require a human approval step when the modification affects billing data, or that modifications are only permitted during business hours, or that no more than fifty records may be modified in a single execution. The UCAN provides the capability ceiling. The rule book provides the runtime constraints within that ceiling. Together, they create a governance model where authority is delegated with precision and exercised under supervision, without requiring a human in the loop for every action. What does this mean for enterprise agent deployments? Enterprise organisations evaluating agent platforms should ask a specific set of questions about authority and permissions. Can you trace the authority for any agent action back to a human decision? Can you verify that no agent exceeded its delegated scope? Can you revoke authority at any point in the delegation chain and have the revocation take effect within a bounded time? Can you prove all of this to an auditor without reconstructing it from logs? These questions expose the gap between traditional IAM (which was designed for a world of static role assignments and human-speed operations) and the requirements of production agent systems (which operate at machine speed, delegate dynamically, and act across organisational boundaries). UCAN tokens are one answer. They are one of several approaches to scoped authority for agents. Their structural advantage is that the authority is self-certifying and verifiable without a central authority, which makes them practical for distributed systems where the agents, the tools, and the governance infrastructure may all be operated by different organisations. The deeper question is whether organisations will adopt scoped authority models before or after an agent exceeds its intended permissions and modifies something it should not have. The technical mechanisms exist. The compliance requirements are arriving. The agents are already acting. The question of whether their authority is properly scoped is one that each organisation will answer on its own timeline, and will be held accountable for on someone else's. --- # Why the Coordination Layer Must Be Open-Source Published: 2026-07-29T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/coordination-layer-must-be-open-source Critical Infrastructure Ends Up Owned By the People Who Depend On It The systems the world runs on share a pattern. The protocols that move packets, resolve names, and settle transactions are inspectable, extensible, and governed by the community that builds on top of them. This is not an accident of history. When a layer becomes load-bearing for everyone, no single vendor can be trusted to hold it alone, and no serious operator will build a business on a foundation they cannot read. The coordination layer for the synthetic workforce is heading toward exactly that status. As teams move from one agent doing one task to many agents executing work across systems, boundaries, and organisations, something has to decide who is allowed to run what, where, and under whose authority. That something becomes infrastructure. And infrastructure of that kind has to be open. At Covia, the management layer for the synthetic workforce, this is a design constraint rather than a positioning statement. This post explains why. What the Coordination Layer Actually Does Most teams first meet agents as isolated tools. A model calls a function, returns a result, and the interaction ends. That works until the second agent arrives, and the third, and until those agents start invoking each other across networks owned by different teams. At that point the hard problems stop being about model quality. They become questions of execution. Which agent is permitted to call this tool? On whose behalf is it acting? What happens when a step fails halfway through a chain that crossed four systems? Who can prove, afterward, what actually ran? The coordination layer is the substrate that answers those questions. It sits beneath the agents and above the raw infrastructure, and it is responsible for authority, execution, and attribution across every participant. In the Covia Grid this layer carries a set of execution guarantees, an authority model that decides what each participant may do, and a record of what happened that any party can verify. This is the part of the stack that decides whether a multi-agent system is a controlled process or an uncontrolled one. It is the part you least want to be a black box. Why Can't a Closed Platform Own This Layer? A reasonable objection: plenty of critical software is proprietary, and it works. Why should the coordination layer be different? Because of what it governs. This layer sits in the path of every action an agent takes. It holds the authority model. It decides which operations are permitted and which are refused. When it makes a decision, the consequence is that real work either runs or does not run inside your systems, on your data, under your name. Ask what a closed version of that requires you to accept. You accept that the rules governing execution inside your own environment are defined by logic you cannot read. You accept that when the layer denies an action, you cannot inspect why. You accept that the boundary between what an agent may and may not do is enforced by a component you are not permitted to audit. You accept a single vendor's roadmap as the ceiling on what your agents can coordinate. And you accept that if that vendor changes terms, raises prices, or disappears, the layer your operations depend on leaves with them. For a productivity tool, those are tolerable trade-offs. For the layer that controls execution across your synthetic workforce, they are not. The properties that make software safe to depend on at this level are precisely the properties a closed system cannot offer: the ability to read the code, to verify the behaviour, to extend it, and to keep running it regardless of any one company's fate. Inspectable, Extensible, Owned Three requirements follow from treating coordination as critical infrastructure, and each maps to something a closed layer cannot give you. Inspectable. Security and correctness at this layer cannot rest on trust in a vendor's description of its own product. The authority model, the execution guarantees, and the enforcement of boundaries all have to be readable by the people relying on them. An engineer evaluating whether to route production work through the coordination layer should be able to read how a rule book is evaluated and how a boundary is enforced, not infer it from documentation. Open source turns "trust us" into "here is the code." Extensible. No vendor can anticipate every venue an agent will need to execute in, every system it will need to reach, or every policy a regulated industry will need to encode. A closed layer caps extension at whatever the vendor chose to expose. An open one lets the teams who hit the edges build past them, and lets those extensions accrue to everyone. The coordination layer has to grow toward its users faster than any single company can push it. Owned by its community. This is the requirement most people underestimate. When a layer becomes foundational, continuity matters more than features. Teams building serious systems need to know the substrate will outlive its original authors, that a licence change cannot strand them, and that governance is not a single company's private decision. Community ownership is what converts a promising product into infrastructure you can commit to for a decade. How Covia Ships This Principles are easy to write and easy to walk back. The way to make an open-source commitment real is structural, so that it cannot quietly reverse later. Covia operates on an open-core model. The runtime, the part that enforces execution, is released under the Eclipse Public License 2.0. The SDKs, in Python, Java, and TypeScript, are released under Apache 2.0, so teams can build and distribute without friction. All of it lives in public at github.com/covia-ai, where the coordination logic can be read, forked, and run. The choice of two licences is deliberate. A copyleft licence on the runtime keeps improvements to the execution core visible to the whole community. A permissive licence on the SDKs removes any obstacle to adoption in commercial software. The result is a layer whose most critical component stays inspectable and shared, while the tools that touch it stay maximally easy to use. Concepts that matter for control are documented in the open too. The authority model, expressed through a rule book. The execution location, expressed as a venue. The execution limit, expressed as a boundary. These are not proprietary vocabulary hidden behind a sales process. They are the shared language of a substrate meant to be built on by people who do not work here. The Commercial Objection, Answered Plainly Founders and investors often ask the obvious question: if the core is open, what stops someone from copying it? The premise misreads where value sits at this layer. The coordination substrate earns trust by being inspectable, which is the opposite of a moat built on secrecy. What compounds is everything around an open core that is hard to copy: operational reliability at scale, the managed service that most teams would rather buy than run, the accumulated knowledge of edge cases, and the trust that comes from years of a community depending on the same code without being burned. Closed infrastructure at this layer competes on lock-in. Open infrastructure competes on being the thing people actually want to depend on. For a layer that aims to be as fundamental to the agent economy as TCP/IP was to the network, only one of those is a foundation that lasts. What This Forces Treating the coordination layer as open source changes the questions a buyer gets to ask. Instead of trusting a description, they can read the enforcement. Instead of hoping a vendor survives, they can hold the code. Instead of accepting a ceiling, they can extend past it. The synthetic workforce will run on some coordination layer. The only open question is whether the layer that governs execution across your systems will be one you can read, or one you are asked to take on faith. If it turns out to be critical infrastructure, which answer will you wish you had insisted on? --- # Why the Agent Economy Needs a Coordination Layer Published: 2026-07-27T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/why-agent-economy-needs-coordination-layer The gap between more agents and more output Teams deploying agents hit a wall that has nothing to do with model quality. One agent answers questions. Three agents split a task. Somewhere past that, the system starts producing outcomes nobody authored: two agents write to the same record with different assumptions, a retried step fires twice against a payment API, an escalation lands in a queue no human owns. The models are fine. What fails is everything between them. This is the shape of the agent economy as it stands in 2026. Capability is abundant and cheap. Coordination is scarce and expensive, and it gets more expensive with every agent you add. The management layer for the synthetic workforce exists because the missing piece in most deployments is not intelligence. It is the substrate that lets many agents act on shared systems without colliding. What happens when agents scale without coordination? Ad-hoc integration works at small numbers because a human is holding the whole system in their head. You know agent A runs before agent B, so you wire them in sequence. You know only one agent should touch the invoicing system, so you give it the credentials and hope the others stay away. You know the retry logic is fragile, so you watch it. That model breaks silently. Adding a fourth and fifth agent does not add friction linearly. Each new agent introduces a set of possible interactions with every agent already present, and the number of those interactions grows far faster than the headcount. At three agents you can reason about the pairwise interactions. At thirty you cannot, and neither can the humans you would need to hire to babysit them. The failures that emerge are structural, and they repeat across every deployment: Race conditions on shared state. Two agents read the same value, both act on it, and the second overwrites the first. The record is now wrong and no log says why. Duplicate side effects. A step fails halfway, a retry re-runs it, and an action that should happen once happens twice. For a database read this is harmless. For a refund or an outbound message it is not. Authority sprawl. Every agent that might need to touch a system gets access to it, because scoping access per task is tedious. The blast radius of a single confused agent becomes the entire stack. No canonical record. When the same fact lives in five agent contexts, there is no answer to the question of what actually happened. Debugging becomes archaeology. None of these are model problems. A more capable model reasons about its own task more effectively and does nothing about the fact that it is one of thirty processes writing to the same production systems. Scaling agents without a coordination layer means scaling the number of ways the system can quietly corrupt itself. The pattern every compute wave follows Every wave of compute has produced abundant capability first and a shared coordination substrate second, and the substrate is what turned the wave into an economy. Electricity arrived as a capability before it arrived as infrastructure. Early adopters ran their own generators, each with its own voltage, frequency, and wiring conventions. The technology worked. What it lacked was a grid: a shared standard for how power moved between producers and consumers so that a device built by one party would run on power supplied by another. The grid, not the generator, is what made electrification an economy rather than a collection of private installations. The internet followed the same arc. Networks existed before they interconnected, each with its own protocols. TCP/IP was the thin, shared agreement that let heterogeneous networks pass packets to one another without knowing anything about each other's internals. The value was never in any single network. It was in the guarantee that data handed to the layer would arrive, addressed correctly, regardless of what sat on either end. Cloud computing recapitulated it. Containers made workloads portable, which produced a new problem: how do you schedule, place, and reconcile thousands of containers across a fleet of machines without a human assigning each one? Kubernetes became the coordination layer that declared a desired state and continuously converged the actual state toward it. Again the individual unit, the container, was the cheap and abundant part. The scheduler that coordinated them at scale was the layer that mattered. Agents are the new abundant unit. They are getting cheaper and more capable on a curve that shows no sign of flattening. The pattern says the constraint moves to the layer that coordinates them, and the value concentrates there. This is the reasoning behind the Universal Grid as a coordination substrate for agents: a shared standard for how many autonomous processes act on shared systems, in the same way TCP/IP standardised how networks exchange data. Coordination is not orchestration The word coordination gets used loosely, so it is worth stating precisely what it covers and what it does not. A coordination layer is the substrate that provides execution guarantees across many agents acting on shared systems: ordering, authority, retry semantics, a canonical record, and convergent state. It defines what is allowed to happen and what happens when something goes wrong, independent of which agent or model is involved. Orchestration, by contrast, is the routing of a task through a predefined sequence of steps. An orchestration tool decides that step one calls this function, then step two calls that one. It is a workflow engine, and it assumes the workflow is known in advance and that the steps behave. The difference matters at scale. Orchestration answers "what is the next step in this flow." Coordination answers a harder set of questions that only appear when many agents share infrastructure: In what order do concurrent actions from independent agents commit, so that shared state stays consistent? What is each agent permitted to do, and how is that scope enforced at the moment of execution rather than assumed? When a step fails partway through, how does the system retry or roll back without producing duplicate effects? Where does the authoritative record of what happened live, so that every agent and every human reads the same history? When an agent hits the edge of its authority, how does it escalate, and to whom? A workflow engine does not answer these because it was never designed to. It presumes a single controlling process. The moment you have many agents acting concurrently, with authority that varies by task and side effects that must not double-fire, you need guarantees the orchestrator cannot provide. Coordination is the layer that provides them. Covia frames these as seven execution guarantees: ordered execution, scoped authority, deterministic retry and rollback, execution-linked memory, a canonical system of record, governed escalation, and convergent state. Each maps to a specific way that multi-agent systems fail when the guarantee is absent. Together they describe what a coordination layer has to deliver before agents can be trusted with production systems. Where is the agent economy heading? Two futures branch from here, and the divergence is already visible in how teams talk about their deployments. In one, coordination stays a per-team problem. Every company scaling agents rebuilds the same substrate badly: hand-rolled locking, homegrown retry logic, access control by convention, a system of record that is really just whichever database got written to last. Each team pays the cost independently, hits the same cliff independently, and caps out at the number of agents a small group of engineers can hold in their heads. The agent economy in this future looks like the pre-TCP/IP internet: real capability, trapped in islands that cannot safely interoperate. In the other, coordination becomes shared infrastructure. The guarantees live in a layer that any agent can act through, the way any device can draw from the grid or any service can trust the network to deliver its packets. Teams stop rebuilding the substrate and start building on it, which is the point at which agent count stops being a liability. This is the future AI-native teams are building toward when they treat coordination as infrastructure rather than glue code, and it is the only version in which the phrase "synthetic workforce" describes something that scales past a demo. The models will keep improving regardless. That was never the constraint. The open question is which teams treat coordination as a layer to be owned deliberately, and which discover, one duplicate refund and one corrupted record at a time, that they built their agent strategy on the assumption that a human would always be watching. --- # State Divergence in Multi-Agent Systems: The Problem No One Ships Without Solving Published: 2026-07-24T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/state-divergence-multi-agent-systems The default is divergence Two agents read the same customer record simultaneously. Agent A determines the customer should be upgraded based on usage patterns. Agent B determines the customer's support tier should be reduced based on a resolved ticket. Both write back their modifications. The final state depends on which write arrives last. This is not a race condition in the traditional sense. Both agents operated correctly. Both read valid state, applied valid reasoning, and produced valid outputs. The problem is that the state each agent read was stale by the time it wrote. Agent A's write was based on a view of the record that did not include Agent B's modification, and vice versa. In a single-agent system, this cannot happen. One agent reads, modifies, and writes, and no other agent intervenes between the read and the write. In a multi-agent system, it happens continuously. The more agents operating on shared state, the higher the probability that any given read-modify-write cycle will be invalidated by a concurrent modification. State divergence is the condition where different participants in a distributed system hold conflicting views of the same data, with no mechanism to resolve the conflict deterministically. In multi-agent systems, divergence is the default outcome of concurrent operation on shared state. Convergence requires explicit substrate-level mechanisms. Why do conventional locking strategies fail for agents? The traditional approach to concurrent state modification is locking. Before modifying a record, acquire a lock. Hold the lock while reading, modifying, and writing. Release the lock when done. Other agents attempting to modify the same record wait until the lock is released. Locking works for short-lived, predictable transactions. A database transaction that reads a row, increments a counter, and writes back completes in milliseconds. The lock duration is negligible. The waiting time for other transactions is negligible. The system throughput is barely affected. Agent operations are neither short-lived nor predictable. An agent that reads a customer record may need to query three external APIs, reason about the results, compose a response, and then write back. This process takes seconds to minutes, not milliseconds. During that time, the lock prevents all other agents from modifying the record. In a system with dozens of agents, lock contention becomes the dominant performance bottleneck. Worse, agents can fail mid-operation. An agent that acquires a lock, begins processing, and then crashes (due to a model timeout, a network failure, or a framework error) leaves the lock held. A lock timeout mechanism can eventually release it, but the timeout duration represents a period during which no other agent can access the record. Shorter timeouts risk releasing locks on operations that are still in progress. Longer timeouts risk extended periods of unavailability. Optimistic concurrency control (read a version number, attempt to write with a condition that the version has not changed) avoids the lock duration problem but introduces a different failure mode: write conflicts. When two agents read the same version and both attempt to write, one succeeds and the other receives a conflict error. The conflicted agent must re-read, re-reason, and re-attempt. In high-contention scenarios, agents can enter livelock, repeatedly reading, reasoning, and conflicting without making progress. Neither pessimistic nor optimistic concurrency control is designed for the access patterns of multi-agent systems. Both assume that concurrent modifications are the exception. In multi-agent systems, concurrent modifications are the norm. What is convergent state? Convergent state is a property of a distributed system where all participants are guaranteed to arrive at the same value for shared data, regardless of the order in which they receive updates. Convergence is a mathematical guarantee provided by the data structures used to represent state. The mechanism is the lattice data structure. A lattice defines a partial order over possible values and a merge function (the join, or least upper bound) that combines any two values into a single value. The merge function has three critical properties: it is commutative (merge(A, B) = merge(B, A)), associative (merge(merge(A, B), C) = merge(A, merge(B, C))), and idempotent (merge(A, A) = A). These three properties together guarantee convergence. Commutativity means the order in which updates are received does not affect the result. Associativity means the grouping of updates does not affect the result. Idempotency means duplicate updates do not affect the result. Any system that applies updates using a lattice merge function will converge to the same state, regardless of network delays, message reordering, or message duplication. The formal name for data structures with these properties is Conflict-free Replicated Data Types, or CRDTs. A CRDT is a data structure whose merge function is commutative, associative, and idempotent by construction. Updates to a CRDT can be applied in any order, on any replica, and all replicas will converge to the same value. How does divergence manifest in multi-agent workflows? The cascading decision problem Agent A reads the inventory level for a product: 50 units. Based on this reading, it decides to accept a customer order for 30 units. Agent B, concurrently, reads the same inventory level: 50 units. Based on this reading, it decides to accept a different order for 35 units. Both agents commit their decisions. The combined committed orders total 65 units against an inventory of 50. This is an overselling bug, and it is the most common manifestation of state divergence in multi-agent commerce systems. The fix is not "make the agents check inventory before committing." Both agents did check inventory. They checked it at a point in time when the inventory was sufficient for their respective orders. The divergence occurred because neither agent's view of inventory reflected the other's concurrent commitment. The conflicting policy problem Agent C is responsible for cost optimisation and reduces a cloud infrastructure allocation based on observed low usage. Agent D is responsible for reliability and increases the same allocation based on a predicted traffic spike. Both modifications are valid under their respective policies. The final state depends on execution order, and neither agent is aware of the other's modification. This is a structural property of multi-agent systems where different agents optimise for different objectives on shared state. Without a convergence mechanism, the system oscillates between the two agents' preferred states, with each agent undoing the other's modifications on every cycle. The split-brain workflow problem A multi-step workflow involves agents distributed across two data centres. A network partition separates the centres. Agents on each side continue processing, modifying shared state based on their local view. When the partition heals, the two sides hold conflicting versions of every record that was modified during the partition. Without convergent data structures, resolving a split-brain scenario requires a human operator or a custom reconciliation script to examine each conflicting record and decide which version to keep. For a system with thousands of records modified during a partition lasting minutes, this is operationally infeasible. What does a lattice-based solution look like in practice? Consider the inventory example. Instead of representing inventory as a single integer (50 units), the substrate represents it as a lattice structure that tracks reservations independently. Each agent's reservation is a distinct entry in the lattice. The total available inventory is computed by subtracting the lattice-merged reservations from the base stock level. When Agent A reserves 30 units, it adds a reservation entry: {agent_a: 30}. When Agent B reserves 35 units, it adds a different entry: {agent_b: 35}. The lattice merge combines both entries: {agent_a: 30, agent_b: 35}. The computed availability is 50 - 30 - 35 = -15. The system detects the oversell because the merged state reflects both reservations, regardless of the order in which they were applied. The detection happens at merge time, not at read time. Agent B's reservation, when merged with Agent A's, produces a state that violates the inventory constraint. The substrate can enforce this constraint at the merge function level: if the merged reservations exceed available stock, the merge function rejects the later reservation and triggers a governed escalation. This approach eliminates the fundamental problem with locking: the agents do not need to coordinate before acting. They act independently, and the substrate resolves conflicts through deterministic merge semantics. The merge function encodes the business rules (inventory cannot go negative, security policy wins over cost optimisation, the most recent timestamp governs in case of direct conflict), and every replica applies the same function to produce the same result. Why is eventual consistency insufficient? Eventual consistency is often presented as a solution to distributed state management. The system guarantees that, in the absence of new updates, all replicas will eventually converge to the same value. This guarantee is weaker than convergent state in three important ways. First, eventual consistency does not specify how conflicts are resolved. Two conflicting writes will eventually converge, but the convergence strategy (last-write-wins, first-write-wins, application-defined) varies by implementation. Last-write-wins is the most common, and it silently discards one agent's modifications based solely on timestamp ordering. The discarded agent receives no notification that its work was overwritten. Second, eventual consistency provides no bound on convergence time. "Eventually" may mean milliseconds or hours, depending on network conditions and replication lag. During the convergence window, different agents reading from different replicas see different values and make decisions based on conflicting views of reality. Third, eventual consistency does not compose. If two eventually consistent systems interact (for example, an eventually consistent CRM and an eventually consistent inventory system), the combined system's consistency guarantees are weaker than either component's individual guarantees. The convergence windows of the two systems are independent, creating a combinatorial space of inconsistent states. Convergent state, as implemented through lattice data structures, addresses all three weaknesses. Conflicts are resolved by the merge function, which is deterministic and encoded in the data structure. Convergence occurs at merge time, which is bounded by network latency rather than replication lag. And lattice structures compose: the merge of two lattice-structured records is itself a lattice-structured record with the same convergence guarantees. How does the Grid implement convergent state? The Grid uses lattice data structures as its state management substrate, giving it convergent consensus across venues. Every piece of shared state in the Grid is represented as a lattice data structure with a defined merge function. When agents modify shared state, their modifications are lattice operations that can be merged in any order to produce the same result. The implementation has three layers. The data layer represents all shared state as lattice structures with a defined merge function. The merge layer applies lattice merge functions when concurrent modifications occur, producing a deterministic result. The constraint layer evaluates business rules against the merged state and rejects or escalates operations that violate defined constraints. This architecture means that agents operating on the Grid never encounter a state divergence that the substrate cannot resolve. Two agents modifying the same record concurrently produce a merged state that reflects both modifications, resolved according to the merge function defined for that data type. The merge is deterministic, commutative, associative, and idempotent. Every replica that applies the same set of modifications arrives at the same state, regardless of ordering. The constraint layer provides an additional guarantee beyond convergence: the merged state must satisfy defined invariants. An inventory that goes negative, a security policy that contradicts itself, a workflow that enters an impossible state, these are detected at merge time and handled through governed escalation rather than being silently accepted. What does this mean for agent framework design? The convergent state guarantee changes the design assumptions for agent frameworks. Without convergent state, agent frameworks must implement their own concurrency management: locks, version checks, conflict detection, retry logic, and conflict resolution. Each framework implements these differently, and agents from different frameworks cannot safely modify the same state. With convergent state at the substrate level, agent frameworks can treat shared state as a convergent resource. An agent reads the current state, makes a decision, and writes back a modification. If another agent modified the same state concurrently, the substrate merges both modifications deterministically. The agent framework does not need to detect or resolve the conflict. The substrate handles it. This is the same separation of concerns that databases provide for web applications. A web application does not implement its own concurrency control for database records. The database provides isolation levels and conflict resolution, and the application operates within those guarantees. The Grid provides convergent state guarantees, and agent frameworks operate within them. The open question is whether the lattice merge model is expressive enough for all agent coordination patterns. Lattice merge works well for commutative operations (counters, sets, maps with defined merge functions). It works less well for operations that are inherently non-commutative: operations where the order matters, where A-then-B produces a fundamentally different outcome than B-then-A. For these operations, the substrate must provide ordered execution guarantees in addition to convergent state, which means some operations require serialisation even in a convergent system. The boundary between "convergeable" operations and "serialisable" operations is an active area of research, and where that boundary falls determines the practical throughput of any convergent-state system under multi-agent load. --- # Audit Trails Are Not Logs Published: 2026-07-22T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/audit-trails-are-not-logs The distinction most agent deployments get wrong Every production system generates logs. Application logs, access logs, event logs. They accumulate in storage, get indexed by observability platforms, and serve their purpose when an engineer needs to debug a failing service. Logs are essential infrastructure. They are also, categorically, not audit trails. The difference matters because the question changes when the actor is an AI agent. When a human operator modifies a production database, the organisation can reconstruct the chain of authority through access control records, change management tickets, and the operator's own account of their reasoning. When an agent modifies that same database, the only record of what happened, in what order, and under whose authority is whatever the system captured at the time. If the system captured logs, you have a debugging tool. If the system captured an audit trail, you have evidence. An audit trail is a contemporaneous, immutable, causally ordered record of actions taken, the authority under which they were taken, and the outcomes they produced. It is created at execution time, as part of the execution, with the same integrity guarantees as the action itself. A log is a side channel. It records observations about what happened, often after the fact, often with gaps, and almost always without cryptographic proof that the record has not been altered since creation. Why does the distinction become a compliance requirement? Regulatory frameworks do not ask whether you can reconstruct what happened. They ask whether you can prove it. SOC 2 Type II, ISO 27001, the EU AI Act's transparency obligations for high-risk systems: each of these requires the organisation to demonstrate that it maintained authoritative records of consequential actions. The word "authoritative" is doing significant work in that sentence. It means the record is contemporaneous, complete, tamper-evident, and attributable to a specific actor under a specific grant of authority. Post-hoc reconstruction fails every one of those tests. Assembling a timeline from distributed log files after an incident is a forensic exercise, valuable for root cause analysis, insufficient for compliance. The timestamps may not be synchronised. The log entries may have been rotated, truncated, or overwritten. The causal ordering may be ambiguous. And critically, there is no proof that the logs were not modified between the time of the action and the time of the audit. This is not a theoretical concern. It is the precise scenario that auditors are trained to probe. When an auditor asks "show me the record of this agent's actions on this date," the answer cannot be "give us a few hours to query our log aggregator and correlate the entries." The answer must be a single, retrievable record that stands on its own. What "system of record" means when the actor is an agent A system of record is the authoritative source for a specific category of data. In finance, the general ledger is the system of record for transactions. In HR, the HRIS is the system of record for employee data. The defining characteristic is that it is the canonical source from which all other representations derive. When there is a discrepancy between the system of record and any other source, the system of record wins. When the actor in your production environment is an AI agent, the question becomes: what is the system of record for that agent's actions? Where is the authoritative record of what it did, what inputs it received, what tools it invoked, what outputs it produced, and under whose delegated authority it operated? For most organisations deploying agents today, the honest answer is that no such system of record exists. The agent's actions are scattered across application logs, LLM provider logs (which the organisation may not even own), tool invocation records in various downstream systems, and perhaps some custom telemetry. No single source is authoritative. No single source is complete. And no single source can prove that its records have not been altered. This is the compliance gap. Organisations have observability for their agents in the same way they have observability for any distributed system. They do not have a system of record for agent actions. The anatomy of an authoritative record An audit trail entry for an agent action needs to capture several things simultaneously. The identity of the agent. The identity of the human or system that delegated authority to the agent. The scope of that delegated authority, including any constraints or boundaries. The specific action taken. The inputs to that action. The outputs produced. The timestamp, with sufficient precision and synchronisation guarantees. A cryptographic commitment that binds all of these elements together and makes the record tamper-evident. Each of these elements must be recorded at execution time, as part of the execution pipeline, with the same transactional guarantees as the action itself. If the audit record is written asynchronously, after the action completes, there is a window in which the action exists without a record. If the system fails during that window, the action happened but the record did not. The record must also be causally ordered. When agent A's output becomes agent B's input, the audit trail must capture that causal relationship explicitly. Timestamp ordering is insufficient because clocks drift, batches get reordered, and distributed systems do not guarantee that wall-clock time reflects causal sequence. How the record is created at execution time Covia's approach treats the audit trail as a first-class product of execution. When an agent executes an action through the Grid, the audit record is created as part of the same atomic operation as the action itself. The record includes the agent's identity, the delegation chain that authorised the action, the scoped permissions under which it operated, the inputs and outputs, and a cryptographic commitment to the complete record. The causal ordering is maintained through the lattice data structure that underlies the Grid. Each action references its causal predecessors explicitly, creating a directed acyclic graph of agent actions that can be traversed in causal order regardless of when the actions were recorded or on which node they executed. The compliance gap is a design gap The reason most agent deployments have logs rather than audit trails is that the platforms on which they are built were not designed with audit trails as a requirement. LLM providers give you token-level logs for debugging and billing. Tool invocation frameworks give you execution traces for observability. Application platforms give you request logs for monitoring. Each of these serves its purpose. None of them, individually or combined, constitute a system of record for agent actions. Closing the gap requires treating the audit trail as a design-time decision. The system must be built so that the record is an inherent product of execution, so that it cannot be bypassed, and so that it provides the cryptographic integrity guarantees that make the record admissible as evidence. Organisations deploying agents into enterprise environments will eventually face a simple question from their auditor, their regulator, or their board: can you prove what your agents did? The organisations that designed for audit trails will retrieve a record. The organisations that designed for observability will begin a forensic reconstruction. The agents are already modifying production systems. The question of whether the record is authoritative enough is one that gets answered retroactively, usually at the worst possible time. --- # Bring Your Own Agent: Why the Grid Is Framework-Agnostic Published: 2026-07-20T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/bring-your-own-agent-grid-framework-agnostic The framework question is the wrong question Every team building with agents eventually runs the same meeting. Someone puts three logos on a slide. LangChain, CrewAI, AutoGen. A fourth column reads "custom Python." The debate runs for an afternoon, sometimes a quarter, and the output is a standard: one framework, blessed, mandated across teams. Six months later a new framework ships, a new hire brings a different preference, and a model vendor releases its own orchestration library. The standard cracks. The meeting reconvenes. The framework debate feels foundational because it touches everything the agent does: how it plans, how it calls tools, how it holds a conversation. But framework choice answers a narrow question, which is how an agent is authored. It says nothing about how an agent behaves once it is running in production against real systems, real money, and real users. That second question is where reliability lives, and it does not care which library emitted the plan. Covia takes a specific position on this. The Grid does not care which framework built the agent. It cares that every agent, whatever authored it, runs under the same execution guarantees. What the framework actually decides A framework is an authoring surface. It gives a developer a vocabulary for describing intent: a chain, a crew, a graph of nodes, a set of roles. It decides ergonomics. It shapes how quickly a prototype comes together and how readable the code is a month later. These are real concerns and worth having opinions about. What a framework does not decide is what happens at the boundary where the agent stops reasoning and starts acting. When an agent issues a payment, updates a record, sends an email to a customer, or hands work to another agent, the framework has already done its job. The instruction is out. Whether that instruction executes once or three times, whether it executes in the right order, whether it can be rolled back, whether anyone can later say who authorised it: none of that is in the framework's scope. It sits below. This is the layer most teams discover late, usually the first time an agent does something in production that no one can fully explain. The logs show the model's reasoning. They do not show a durable record of what executed, in what order, under whose authority. The framework was never designed to provide one. Why standardising on a framework fails Mandating a single framework is an attempt to buy consistency. If every agent is a LangChain agent, the reasoning goes, every agent behaves consistently. In practice the mandate delivers the opposite of what teams want, for three reasons. First, frameworks move faster than any standard can hold. The agent tooling space rewrites itself every few months. A choice that looks canonical in one quarter looks legacy in the next, and the cost of migration falls on every team that complied. Second, different problems want different authoring models. A tightly scoped extraction task and a long-running research workflow do not benefit from the same abstractions. Forcing both through one framework produces awkward code in at least one of them, and awkward code is where incidents hide. Third, and most important, standardising on a framework standardises the wrong layer. It makes authoring uniform while leaving execution as varied as ever. Two LangChain agents written by two teams can still retry differently, escalate differently, and leave different gaps in their audit trail. The logo matched. The behaviour did not. Consistency that matters is consistency of execution. That has to be enforced somewhere every agent passes through, regardless of how it was built. Where should reliability be enforced? If not in the framework, then where? The answer Covia takes is that reliability belongs in the substrate every agent runs on, at the point of execution, applied identically to all of them. Consider how this worked in an earlier shift. Applications were written in many languages against many operating systems, and the industry did not resolve that by mandating one language. It agreed on TCP/IP: a neutral layer underneath that every application used to communicate, no matter what it was written in. The diversity above the protocol was fine because the guarantees below it were uniform. Agents want the same shape of answer. Diversity of authoring above, uniformity of execution below. This is what framework-agnostic means at Covia. An agent authored in CrewAI, an agent authored in AutoGen, and an agent hand-written in Python are all the same kind of thing once they reach the Grid: a participant that submits work to be executed under guarantees. The Grid holds the guarantees. The framework holds the ergonomics. Neither reaches into the other. The guarantees every agent inherits When an agent runs on the Grid, its execution profile stops depending on how carefully its author handled edge cases. The substrate applies the same seven guarantees to every participant: Ordered execution. Actions happen in a defined sequence, so two agents acting on the same resource cannot interleave into a corrupt state. Scoped authority. Every agent operates inside an explicit grant of what it may touch, enforced at execution rather than documented in a wiki. Deterministic retry and rollback. A failed action has a defined outcome. It retries under known conditions or unwinds cleanly, so a network blip does not become a double charge. Execution-linked memory. What an agent remembers is tied to what it actually did, so state and action cannot silently diverge. Canonical system of record. There is one authoritative account of what happened, rather than a reconstruction stitched from log lines after an incident. Governed escalation. When an agent hits the edge of its authority, there is a defined path to a human or a higher-authority process, rather than a silent failure or an overstep. Convergent state. When many agents act concurrently, the system resolves to one consistent state through convergent consensus rather than leaving conflicting versions in place. A developer using LangChain does not implement any of these. Neither does a developer using a custom loop. They are properties of the venue the work runs in, which means an agent inherits them by arriving on the Grid, without being rewritten. A concrete picture Picture two agents built by two teams. One is a procurement agent written in CrewAI that reconciles invoices against purchase orders. The other is a finance agent hand-written in Python that releases payments. In a framework-first world, these two share nothing. Each team implemented its own retry logic, its own idea of what counts as authorised, its own logging. When they touch the same invoice at the same time, the outcome depends on which team's edge-case handling was more careful. No one designed that behaviour. It is an accident of two codebases meeting. On the Grid, both agents submit their work to the same substrate. Ordered execution means the reconciliation and the payment cannot interleave into a state where an invoice is paid twice or approved against the wrong order. Scoped authority means the procurement agent cannot release a payment even if a prompt injection convinces it to try, because releasing payments sits outside its grant. The canonical system of record means that when finance asks what happened, there is one answer, the same answer, whichever agent is asked. None of this required the two teams to agree on a framework. It required them to run on the same substrate. Bring your own agent, keep your guarantees The practical consequence is a model worth naming plainly: bring your own agent. Keep the framework your team already knows. Keep the code you have already shipped. What changes is the execution layer underneath, and the authoring layer stays yours. This matters for how organisations actually adopt agents. Real companies do not run one framework. They run whatever three different teams chose over two years, plus whatever a recent acquisition brought in, plus whatever a vendor's SDK ships with. A reliability story that requires all of them to converge on one framework is a reliability story that never ships. A reliability story that meets every agent where it is has a chance. It also clarifies the line between what a team owns and what the infrastructure owns. A boundary, in Covia's terms, is an execution limit: a defined edge an agent cannot cross without explicit authority. When boundaries live in the framework, every team draws them differently and enforcement is a matter of hoping each developer remembered. When boundaries live in the substrate, they are enforced the same way for the CrewAI agent and the Python agent alike. The team keeps ownership of intent. The Grid takes ownership of limits. In practice, you register the agent on a venue and call it like any other: Neutral infrastructure or nothing There is a reason the neutrality has to be strict. The moment infrastructure privileges one framework, it stops being infrastructure and becomes a competing framework with extra steps. Teams can tell the difference, and they route around it. Anything that manages a mixed fleet of agents has to be genuinely indifferent to how those agents were built, or it cannot manage the fleet a real organisation actually has. Covia positions itself as the management layer for the synthetic workforce, and a management layer only earns that name if it manages everyone. A synthetic worker authored in one framework and a synthetic worker authored in another are the same kind of participant from the Grid's point of view: work to be executed under guarantees, held to the same account. So the framework question turns out to be answerable after all, once it is asked correctly. Which framework should you standardise on? Whichever ones your teams are already productive in. The choice that actually decides whether your agents can be trusted in production gets made one layer down, at the point where reasoning becomes action. That is the question worth an afternoon of debate: what is every agent guaranteed the moment it acts, no matter who built it? --- # Guarantees Every Production Agent Needs Published: 2026-07-17T09:00:00Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/guarantees-production-agent-needs The substrate problem Production AI agents fail in ways that look nothing like demo failures. A demo agent summarises a document, generates a response, and returns it to a user. A production agent modifies a CRM record, triggers a deployment pipeline, sends a customer email, and updates an invoice, all within a single workflow that may involve three other agents operating on the same data concurrently. The difference is consequence. When a demo agent fails, a user clicks "retry." When a production agent fails mid-workflow, a customer receives a duplicate invoice, a deployment rolls forward on corrupted state, or two agents overwrite each other's modifications to a shared record. Most teams discover this the hard way. They build agents that work reliably in isolation, deploy them into shared production environments, and watch failures cascade in patterns they did not anticipate. The agents themselves are fine. The substrate they run on provides no guarantees about what happens when multiple agents act concurrently on shared systems. These are substrate guarantees, not application features. You cannot bolt them on at the application layer any more than you can implement TCP reliability in a web application without a transport protocol underneath. The agent framework does not matter. The model does not matter. What matters is whether the execution substrate enforces the properties that production workloads require. What qualifies as a production agent? A production agent is any autonomous process that modifies shared state or triggers side effects in systems where other agents, humans, or processes also operate. The defining characteristic is participation in a shared environment where actions have consequences that persist beyond the agent's own execution context. A production agent is distinct from a tool-augmented chatbot in three ways. First, it acts without waiting for human approval on every step. Second, its actions affect systems that other agents also modify. Third, its failures have consequences that cannot be undone by refreshing a browser window. By this definition, most "AI agents" in production today are production agents whether their operators realise it or not. The moment an agent writes to a database, sends a message, or calls an external API, it is operating in production territory. The question is whether the substrate it runs on acknowledges this. The seven guarantees 1. Ordered execution When Agent A reads a customer record, decides to update the billing tier, and writes the new tier back, the read and write must execute in a defined order relative to every other operation on that record. If Agent B is simultaneously modifying the same customer's support tier, the final state must reflect a serialisable ordering of both operations. Without ordered execution, the outcome depends on timing. Two agents reading the same record at the same instant, each making a decision based on that read, each writing back a modification: the last write wins, and one agent's work is silently discarded. The agent that lost the race has no way to detect this. It completed successfully from its own perspective. Ordered execution does not mean sequential execution. Agents can and should run concurrently. Ordered execution means the substrate maintains a consistent ordering of state transitions, so that every agent's view of shared state reflects a coherent history. This is the same guarantee that databases provide through serialisable isolation levels, applied to the broader surface area of agent operations. 2. Scoped authority Every agent action must execute within a defined permission boundary. Scoped authority means an agent can modify the resources it has been granted access to and nothing else, enforced by the substrate rather than by the agent's own restraint. A scoped authority system defines, for each agent, which resources it can read, which it can modify, and which operations it can invoke. These scopes are enforced at the substrate level. An agent that attempts to exceed its authority receives an explicit denial. This matters because agents make decisions based on context, and context can be manipulated. A prompt injection that convinces an agent to "update all customer records" should fail because the agent's execution scope limits it to the specific customer records relevant to its current task. The enforcement boundary must sit below the reasoning layer, in the same way that operating system permissions sit below the application layer. Scoped authority also enables auditability. When every action is tagged with the agent's identity and scope, the system of record can answer questions like "which agent modified this record, and did it have permission to do so?" without relying on the agent to self-report honestly. 3. Deterministic retry and rollback When an agent operation fails mid-execution, the substrate must provide exactly two options: retry the operation from a known-good state, or roll back all of its effects. "Retry from wherever it crashed" is not an option, because the operation may have already produced side effects that cannot be duplicated. A deterministic retry means the substrate knows exactly which steps completed, which side effects were emitted, and which steps remain. It replays only the incomplete portion, using idempotency keys to prevent duplicate side effects. A deterministic rollback means the substrate can reverse all effects of the failed operation, returning shared state to its pre-operation condition. Without this guarantee, retries in non-idempotent tasks duplicate side effects. An agent that sends a customer email, then fails on the next step, will send that email again on retry unless the substrate deduplicates it. An agent that debits an account and then fails will debit twice. The failure mode is that the agent crashed and the recovery path made it worse. 4. Persistent memory, execution-linked Agent memory must persist across executions and must be linked to the execution context that produced it. This is distinct from both conversation history (which is session-scoped) and vector databases (which are query-scoped). Execution-linked memory means that when an agent runs a workflow on Monday and then continues that workflow on Wednesday, it has access to the complete state of Monday's execution: which steps completed, what decisions were made, what intermediate results were produced. This memory is the canonical record of what happened, stored in the same substrate that enforced the execution guarantees. This matters for long-running workflows. An agent coordinating a multi-week procurement process needs to remember not just "what was the last thing I did" but "what is the complete state of every sub-task, which approvals are pending, and what decisions did I make three weeks ago that constrain my options today." Persistent, execution-linked memory makes this a substrate feature rather than an application-level reconstruction problem. What does a system of record mean for agent execution? 5. Canonical system of record A system of record for agent execution is a single, authoritative source of truth for every action taken, every state change produced, and every decision made by every agent in the system. It is not a log. Logs are append-only records that require reconstruction to answer questions about current state. A system of record maintains the current state directly, alongside the full history that produced it. The distinction matters operationally. When an incident occurs, the first question is "what happened?" A log-based system requires an engineer to reconstruct the sequence of events from potentially millions of entries across multiple services. A system of record answers the question directly: here is the current state, here is every transition that produced it, here is which agent made each transition and under what authority. The Grid implements this as a first-class substrate feature. Every agent operation, every state transition, every authority check, and every retry or rollback is recorded in a single, queryable system of record that provides both the current state and the complete causal history. 6. Governed escalation Not every decision should be made by an agent. Governed escalation means the substrate provides a formal mechanism for agents to escalate decisions to humans, other agents, or governance policies, with the escalation itself recorded in the system of record. Governed escalation is distinct from "human in the loop." Human-in-the-loop implies a binary: either the human approves every action, or the agent acts autonomously. Governed escalation defines a spectrum. The substrate enforces policies like "this agent can approve expenses under $1,000 autonomously, must request peer review for $1,000 to $10,000, and must escalate to a human for anything above $10,000." The policies are enforced at the substrate level. An agent that encounters a decision exceeding its authority does not choose to escalate. The substrate prevents it from proceeding and routes the decision to the appropriate authority. The escalation, the decision, and the resumption of the original workflow are all recorded in the system of record. 7. Convergent state When multiple agents operate across distributed systems, their local views of shared state will temporarily diverge. Convergent state means the substrate guarantees that all divergent views will eventually resolve to the same value, without requiring a central coordinator or leader election. A convergent state system uses data structures with mathematically guaranteed merge properties. When two agents modify the same data concurrently, the merge function produces the same result regardless of the order in which the modifications are applied. This eliminates an entire class of distributed systems failures: split-brain scenarios, stale reads that produce conflicting writes, and coordination deadlocks. Convergent state does not mean eventual consistency in the traditional sense. Eventual consistency often means "the system will probably converge at some point, and you can read stale data in the meantime." Convergent state means the data structures themselves guarantee convergence, with deterministic merge semantics that produce a provably correct result. The compound effect These guarantees are not independent features. They form a compound property of the execution substrate. Ordered execution without scoped authority means operations are sequenced correctly but any agent can modify anything. Scoped authority without a system of record means permissions are enforced but no one can verify after the fact. Deterministic retry without convergent state means individual operations recover correctly but the global state can still diverge. The compound effect is this: a substrate that provides all seven guarantees simultaneously creates an environment where production agents can operate concurrently on shared systems with the same reliability expectations as traditional distributed services. The substrate enforces properties that the agents cannot violate. This is the argument for treating the coordination layer as infrastructure rather than as a feature of individual agent frameworks. Each framework can implement some of these guarantees for its own agents. No framework can enforce them across agents from different frameworks operating on the same shared state, unless the enforcement happens at the substrate level. What remains unsolved These guarantees address the substrate layer. They do not address the reasoning layer. An agent with perfect execution guarantees can still make bad decisions. It can correctly and reliably execute a plan that is wrong. The substrate ensures the execution is faithful; it does not ensure the plan is sound. This is the boundary between infrastructure and intelligence, and it is a boundary worth respecting. The history of computing infrastructure shows that conflating these layers produces systems that are fragile at both. Operating systems do not evaluate the quality of the programs they run. Databases do not assess the wisdom of the queries they execute. The execution substrate for agents should enforce execution guarantees without opining on execution intent. The open question is where reasoning governance belongs. If the substrate cannot evaluate intent, and the agent framework trusts the model's judgment, and the model is probabilistic by nature, who is responsible when a correctly executed plan produces a harmful outcome? The guarantees ensure the execution is faithful. Faithful execution of a flawed plan is a failure mode that no substrate can prevent. --- # Introducing Covia: The Management Layer for the Synthetic Workforce Published: 2026-05-03T07:45:30Z Author: Chirdeep Chhabra URL: https://covia.ai/blog/introducing-covia-management-layer-synthetic-workforce By Chirdeep Chhabra, Co-founder & CEO, and Mike Anderson, Co-founder & CTO, Covia Labs Three years ago, AI agents were interesting demos. Today, they're writing to Salesforce, opening pull requests, responding to support tickets, and running financial reconciliations inside real production systems. The shift from AI-as-advisor to AI-as-actor has happened faster than anyone planned for, and the infrastructure underneath was never designed for it. When a single agent retries a non-idempotent call, the billing system double-charges. When two agents race to update the same record, one write wins and the other's work disappears without a trace. When an agent takes an action no one can later explain, there is no authoritative record of what it did, on whose authority, or with what outcome. These are the symptoms of a workforce running without a management layer. Every team building production agents is rediscovering the same set of problems: ordered execution, scoped authority, deterministic retry and rollback, persistent memory tied to what actually happened, and a canonical system of record for agent-initiated action. Most are solving them one by one inside application code, shipping fragile glue that papers over the instability. The second architectural refactor to stabilise agent execution usually confirms the shape of the missing layer. Covia is building that layer. What the Grid Does The Covia Grid is a runtime that governs how synthetic workers act. It is the coordination substrate that sits beneath your agent frameworks and above your cloud. Every action an agent takes passes through the Grid, where it is ordered, authorised, recorded, and made replayable. The rule book is enforced at the moment of execution. Persistent memory is anchored to what the agents actually did. The system of record is created as work happens. Underneath, the Grid is a small set of primitives. A capability model with attenuable authority. Agents carry cryptographically signed tokens that grant a specific, narrow set of permissions. The tokens attenuate only: they can be delegated to narrower permissions, never widened. This is how an agent gets scoped authority at runtime without being handed a blank cheque. A convergent state layer built on lattice technology that refuses to corrupt under concurrency. When two agents try to update the same record at the same time, the lattice guarantees a canonical outcome without leader election or locking. An event-driven scheduler that wakes work only when something changes. No polling, no constantly-running sidecar processes. Agents cost nothing when idle and activate deterministically when triggered. A system of record created as execution happens. It is the authoritative timeline of what agents did, in what order, under what authority, and with what outcome. It is the action record itself, created at the point of action. These guarantees are infrastructure properties, not integrations. You do not opt into them feature by feature; they are the shape of the substrate. Agents on the Grid Covia sits underneath the agent frameworks you already use. It is plug-and-play: nothing in your existing stack needs to be replaced to adopt the Grid. Your agents keep their framework, their model provider, and their code. What they get in addition are the Grid's execution guarantees at runtime. The Grid supports four agent styles that compose on the same substrate. LLM agents with tool-call loops and persistent history, for reasoning and open-ended tasks. Workflow agents that follow state machines with guaranteed step ordering, for compliance-heavy processes where every transition must be validated and logged. Rule-engine agents that evaluate policy rules deterministically, without LLM inference, for sub-millisecond latency and zero hallucination risk. And custom agents where teams bring their own transition function in any language, plugged into the Grid for durable state, coordination, and audit. A workflow agent can delegate a reasoning step to an LLM agent, which can call a rule-engine to evaluate a policy, all under the same audit trail and the same ordering guarantee. This is what it means for the substrate to be neutral: the execution semantics are uniform, no matter what style of agent is running above them. Coordination Across Boundaries Agents rarely run in isolation. They act across tools: a sales agent reading from Salesforce, updating HubSpot, and posting to Slack in a single workflow. Across clouds: an on-call agent in AWS triggering a workflow agent in GCP when a deployment fails. Across organisational boundaries: your agents coordinating with a vendor's agents on a shared pipeline without either side sharing credentials. Across jurisdictions: an EU-resident agent handling a request ultimately serviced by an API in the US, with data-locality policies enforced at execution. Each of those boundaries has historically required a custom integration, a shared credential store, or a central broker. The Grid handles all of them by making identity, authority, and ordering properties of the substrate itself. Every agent carries its own decentralised identifier. Capabilities delegate across organisations without credential sharing. State ordering is canonical across the network without a central coordinator. A handoff between two agents in different clouds is semantically identical to one between agents on the same machine. The boundary stops being an integration problem and becomes a policy decision. The System of Record, Explained When we say system of record, we mean something specific. Every action an agent takes is appended to an authoritative timeline at the moment it is issued. A ticket updated, a record created, a file written, an email sent, each links to the agent that issued it, the capability that authorised it, and the state transition it produced. The timeline is cryptographically ordered, so it cannot be rewritten after the fact. It is replayable, so any decision can be reconstructed and audited. It is available at runtime, so agents read their own history and act on it immediately, without waiting for a separate logging pipeline to catch up. Observability pipelines describe events after the fact, reconstructed from spans and traces. The system of record is the primary event stream, created live as the agent acts. Audit trails, compliance reports, debugging reconstructions, and an agent's own persistent memory all resolve to the same record. When something goes wrong, the question "on whose authority, at what moment, with what outcome" has a precise answer, created at the moment of action. Why This Matters Now Agent coordination is the next grid problem. Electricity needed power grids. The internet needed TCP/IP. The web needed HTTP. Cloud-native compute needed Kubernetes. Each wave produced a shared substrate where the rules of the system are enforced in common, so every participant can trust the same guarantees. Agent systems are entering that phase now. Two audiences shape what we ship first. Enterprise teams are asking a governance question. Their CISO or board needs a system of record for every action an autonomous agent takes inside a regulated system, and that record must exist at execution, created as the actions happen. Scaleups are asking a scaling question. They have five or fifteen agents in production already, and the second architectural refactor to stabilise execution is now on the roadmap, taking engineering time that should be going into product. The same substrate serves both, because the failure mode underneath is the same. Without an execution layer, governance is theatre and scale is fragile. Why Open A coordination layer for agents has to be neutral and open, for the same reason TCP/IP and HTTP had to be. A grid is what you get when the substrate is open and the execution rules apply equally to every participant. Any framework can plug in. Any model provider can connect. Any cloud can host it. Adopting the Grid does not require replacing what you have already built, and the guarantees are the same on every side. If You're Building Here If you're responsible for an AI system that modifies production data, the question is not whether agents are becoming part of your workforce. They already are. The question is whether the infrastructure underneath can tell you, precisely, what they did, in what order, under what authority, and with what outcome, and whether that record was created as the actions happened or reconstructed afterwards from logs and hope. Covia is early, and the grid is still being built. If any of this resonates with the ways your own agent systems have started to fail, early access is open at covia.ai.