"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?