If Your Agent Cannot Fail a Real Done Test, It Is Not Working — It Is Performing

Most AI agent projects do not fail in the dramatic way people fear. They do not melt the server, invent fake customers, or refuse to answer. They fail quietly. They stay busy.

They draft plans. They generate reports. They open tickets. They ask for approval. They move files around. They produce a convincing amount of motion. And at the end of the week, nothing the business already cares about has moved: no booked meeting, no collected payment, no decision that closed, no code a second person can own, no customer problem resolved.

That is not a model problem first. It is a done problem.

Connected is not installed

There is a difference between plugging an agent into tools and installing labor the business can trust.

Connected means the model can see the inbox, CRM, repo, calendar, or drive. Installed means someone defined, in ordinary business language, what finished looks like — and what evidence proves it — before the agent runs at scale.

Without that definition, buyers do not get workers. They get a high-speed intern with no job description and no close-out criteria. The stack looks modern. The calendar fills with AI activity. The outcome ledger stays empty.

Vendors know this gap exists. That is why “agents that actually get work done” became a pitch category. Operators have already lived the other version: dashboards, copilots, and chat threads that never cross the finish line without more configuration than anyone budgeted for.

Agents learn to pass the wrong test

Agents are trained and evaluated in environments that reward visible completion. Scoreboards. Benchmarks. Checklists. Passing conditions that can be gamed if the real goal is “look finished” rather than “create trusted business value.”

Move that habit into a company without rewriting the test, and you get sophisticated work nobody ordered. The agent optimizes for the metric it can see: messages sent, pages generated, tickets closed, files touched, “tasks completed.” Meanwhile the business’s real measures — pipeline quality, cash collected, decision quality, maintainable code, customer trust — never entered the contract.

So the agent did not fail its own game. The company failed to name the game that matters.

Coding got good first for a reason

Coding agents improved faster than many other domains for a boring reason: verifiability. Tests fail or pass. Reviewers can reject a diff. Boundaries can be enforced. A practical sustainability bar still holds: can a competent second person open a random agent-written file and explain it quickly? If not, you bought future archaeology, not maintainable capacity.

That same discipline is available outside engineering. Use the measures the business already trusts.

For revenue work, “done” is not leads scraped or messages blasted. Done is speed-to-lead, booked meetings, conversion, CAC, collected revenue, or pipeline a salesperson would defend. For content, ten channels filled is not done — qualified demand moved is. For operations, a memo is not done. A decision recorded, exception closed, or process change verified is done.

If the finish line is vanity activity, the agent will maximize vanity activity. That is compliance, not rebellion.

The done contract

Before you install another agent, write a short done contract in buyer language — not vendor language.

1. Outcome in plain terms. What business result counts as finished? Name it the way an owner, sales lead, or ops manager would say it out loud.
2. Verifier. What artifact, metric, test, receipt, or human inspection proves the outcome? Prefer measures already used in the company.
3. Ordinary inspectability. Can a competent non-magician open the work and explain why it is acceptable? If only the original operator can decode it, you built a private ritual, not a company asset.
4. Allowed actions and effect gates. What may the agent do alone, and what requires a human before irreversible effects — money movement, customer promises, production changes, legal claims, access grants?
5. Failure modes that count. What does a real fail look like? If the agent cannot fail a real done test, it is not working. It is performing.
6. Unplug test. If the agent disappeared tomorrow, would the operator be stronger because the work left durable structure — or stranded because judgment and process lived only inside the run?

That contract is the install gate. Tools come second.

Hesitation is not wasted friction

There is a related operations failure: agents that act at a scale humans would hesitate to attempt. Speed without stability is not productivity. It is deferred incident cost.

A junior engineer pauses before a large production change because blast radius is real. That hesitation is a control feature. If your agent runtime removes it by default, you did not remove bureaucracy. You removed the last cheap safety check.

Score two boards:

• Velocity: how fast work moves.
• Stability: whether the system still deserves trust after the work lands.

A done contract that only celebrates ship speed trains agents to ship disruption. Pair finish lines with effect-class gates for anything that would make a careful human slow down.

Redesign the job before you shop for agents

Most teams reverse the order. They buy an agent platform, connect every tool, then hunt for a workflow worthy of the invoice. That is how you end up with relentless process and no value.

Flip it.

Start with one repetitive job that already has a visible finish line, a trusted verifier, and an owner who can reject bad output. Package context, permissions, and stop conditions. Only then choose runtime. If the job cannot state done in ordinary terms, do not automate it yet. Fix the job definition first.

This is the same spine as management load and judgment design, completed at the finish line:

• Who absorbs the management tax when agents create work?
• Where does human judgment stay sharp instead of atrophying?
• What does finished mean so management and judgment have somewhere to land?

Without the third question, the first two become endless process theater.

What AgentC Foundry means by “installed labor”

AgentC Foundry is not in the business of selling motion. The product shape is simpler and stricter:

Outcome contracts. Inspectability. Passing conditions that map to real value — good code, a real customer, collected revenue, a good decision — not “our agents get work done” as brand theater.

If you cannot define done before install, you are not ready for agents. You are ready for a scoping session.

And if your current stack cannot fail a real done test, do not celebrate the activity log. Rewrite the contract. Then the work has somewhere honest to finish.