AI Agents Aren’t Employees Yet. The Missing Capability Is Accountability.

At 1 a.m., a message lands in the operations channel: “Deployment completed.” By morning, the service is still not live. The configuration was written to staging instead of production, and a compensation script ran twice. No agent decided to cut corners. Nothing looked obviously wrong in its action trace. It simply treated a plausible sequence of clicks and tool calls as a finished job.

This is the gap at the center of the agent conversation. AI can write code, inspect documents, browse, query systems, run tests, and open tickets. That is a large step beyond a chatbot. It is also why the idea of handing workflows to agents and leaving a small number of people to supervise them feels so seductive.

But a job is not a list of actions. A real job includes ambiguous goals, changing requirements, conflicting rules, access boundaries, and consequences when the result is wrong. We call a colleague reliable not because they know where to click, but because they know what completion means, what they are not allowed to touch, when uncertainty requires a pause, and who owns the cleanup. Agents are advancing rapidly on the first half of that list. They remain uneven on the second.

The four layers hidden inside “can it do the work?”

It helps to separate four very different capabilities that get bundled into the word agent.

• Answering.Producing a useful paragraph, code snippet, analysis, or recommendation. Frontier models are already extremely good at this, often faster than a person.
• Acting.Using tools: searching, filing forms, editing files, committing code, executing scripts, or making API calls. This is where an agent begins to feel like it can work.
• Closing the loop.Checking the external system after the action, diagnosing a mismatch, rolling back, retrying safely, or escalating rather than merely reporting success in a chat window.
• Being accountable.Making tradeoffs when goals collide, information is incomplete, and the cost of a mistake is hard to estimate.

The hype jump happens when an impressive second-layer performance is mistaken for the fourth. An agent may write excellent SQL and still not understand that this particular query reaches sensitive data. It may patch a function without recognizing that the change collides with a months-old rollout rule. It may call ten tools in succession without recognizing that tool eight invalidated the plan made at tool one.

Better prompting helps with habits. It does not conjure up organizational memory, unambiguous authority, reversible processes, or judgment about unacceptable risk. Those have to be designed into the system around the model.

Long tasks are not short tasks added together

A good demo can be persuasive: if a model can research one question, edit one function, and book one meeting, why should it not run a day’s work when those moves are chained together? Because every additional step creates another opportunity for lost state, an ambiguous interface, an altered permission, a changing environment, or a small error that the next step treats as fact.

METR’s work on task horizons offers a useful lens. In the study, task length was measured by the time an appropriately skilled human would need. The frontier models tested at the time succeeded on nearly all tasks taking humans less than four minutes, but succeeded on fewer than 10% of tasks taking more than roughly four hours. The point is not that a model suddenly becomes useless at the four-hour mark. It is that reliability falls nonlinearly as a chain grows. Small mistakes get more chances to survive and compound.

For an organization, the better question is not simply “Can the agent do it?” It is: “For how long can it do this class of task at the success rate we require?” “What proof will remain when it fails?” “Can we reverse the failure?” Asking those questions turns an all-purpose automation promise into a workflow that can actually be engineered.

A swarm is not a team until the interfaces have owners

Adding agents does not automatically create an organization. A UCL study instrumenting 1,902 multi-agent coding runs exposed a very ordinary failure. In an eight-step calculation split one step per agent, all ten runs failed on the same decision: whether to round at each step or at the end. The agents discussed it repeatedly. Each could defend its local reading of the instructions. No role owned the final interface decision.

That is more revealing than the claim that the models “got dumber.” Human teams can also lose a project in an interface. Agents can repeat the same pattern faster and at lower friction. More messages do not create more agreement. Giving one model the label coordinator does not create a real coordination mechanism.

Google Research reached a complementary conclusion from controlled evaluations across 180 agent configurations. On genuinely parallel tasks, centralized multi-agent coordination could outperform a single agent substantially. On strictly sequential planning tasks, every multi-agent variant tested performed worse. The decision is not “single agent versus swarm.” It is whether the work can actually be split, and whether an error can be stopped at every handoff.

The right unit of decomposition is therefore not “give each agent a stage.” It is “give each stage an explicit input, an explicit output, an acceptance test, and a recovery path.” Without those four things, a multi-agent workflow is just one unreliable long task broken into several unreliable shorter ones.

Code volume is an easy way to fool yourself

AI-assisted engineering makes the wrong metrics look especially attractive. Commits, lines changed, requests sent, and tool calls all rise quickly and fit neatly into a dashboard. None proves that a customer received more value.

Meta’s Project OT is a useful warning, not because one company settles the question for everyone, but because it exposes the accounting problem. Reuters reported from internal materials that, during a period of intensified AI use, changes to Meta’s internal platforms and infrastructure rose 220% year over year while new or upgraded features reaching users rose 36%. The same reporting described a 40% increase in major technical and security incidents and a 70% rise in staff time spent firefighting. Those are reported internal figures in a particular organizational setting, not a universal forecast. The principle is broader: automation tends to multiply actions before it proves that it has multiplied value.

If testing, acceptance, access controls, and rollback discipline do not improve at the same pace, agents produce more work waiting to be checked. The humans have not disappeared. They have been moved from creation into review, triage, and incident response. The keystrokes saved at the front of the process can be consumed by verification and repair at the end.

“It is only a loop” misses the point, too

There is a healthy reaction against the grandiose language around AI: an agent is often described as a for loop or while loop that keeps finding a next action, using a tool, and trying again. The objection contains an important truth. Current systems do not have human self-awareness, values, or an innate sense of responsibility. They do not reliably develop caution merely because the consequences have become serious.

Still, calling them ordinary loops understates both their value and their danger. The model can generalize across non-identical situations; the toolchain can edit a file, call a service, run a command, and alter a real system. Its errors are not limited to an awkward sentence in a chat box. They can become a production change, a disclosure of customer data, or an unplanned bill. That is exactly why agents deserve stronger operating controls than a toy script.

What to build now

The teams most likely to benefit from agents are not the ones that declare themselves “human-free” first. They are the ones that redraw their workflows most carefully.

• Classify work before automating it.Start with low-risk, reviewable, reversible work: research triage, test drafts, document maintenance, code suggestions, and internal ticket routing. Put clear human gates around money movement, sensitive data, production access, legal commitments, and public publication.
• Define completion as external evidence.“Done” should come with a link, a file diff, a test result, a database receipt, a monitoring check, or an approval record. The agent can propose completion; the system should be able to prove it.
• Separate execution from acceptance.An agent that performs a change should not be the only entity declaring it successful. Use an independent verification step. For high-risk actions, use different permissions, a different context, or a different model to review.
• Design an escalation path before the first failure.Missing inputs, conflicting rules, low confidence, irreversible actions, and cost thresholds should trigger a pause and a human decision. Knowing when to stop is more valuable than forcing a system to continue.
• Measure rework, not just speed.Track first-pass success, review rate, rework time, incidents, rollbacks, and cost per accepted outcome. Without those measures, claims about labor replacement are guesses.

Do not make an AGI calendar the operating plan

There is no settled industry definition of AGI. Some people mean broad cross-domain ability, others mean performance across economically valuable work, and others mean independent learning and self-improvement. Reorganizing a company around a concept without a shared test is a fragile bet.

Two things can be true at once. AI capabilities will continue to improve, and the range of longer tasks that agents can complete may grow quickly. Treating that as noise would mean missing a real productivity shift. But a capability curve is not a workforce-replacement curve. Moving technology into a job also requires data permissions, process standards, accountability, legal boundaries, customer trust, and people who can handle exceptions.

In the next few years, the scarce skill will not merely be prompt writing. It will be the ability to translate a business goal into a verifiable task, set boundaries for an agent, notice failure in the evidence, and own the final decision. Agents can become a powerful execution layer. Until they can consistently recognize uncertainty, stop at the right moment, explain their errors, and bear responsibility for them, calling them employees is still premature.

Sources

• UCL: When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding
• Google Research: Towards a science of scaling agent systems
• METR: Measuring AI Ability to Complete Long Software Tasks
• Reuters: investigation into Meta’s Project OT