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:
from covia import Grid
venue = Grid.connect("https://venue.covia.ai")
# Register an agent on the venue. It runs on the Grid with the execution
# guarantees, alongside agents created from other frameworks and tools.
venue.agents.create("billing-bot", config={
"system": "You reconcile invoices.",
"model": "claude-sonnet-4",
})
reply = venue.agents.chat("billing-bot", "Reconcile the Q1 invoices")
print(reply.response)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?