AI Agents at Work: Where They Deliver and Where They Stall

An agent demo is a short, well-lit path: a clear goal, a clean environment, a handful of tool calls, a satisfying result. Tuesday is different. Tuesday is a half-broken integration, a request that is eighty percent specified, and a system where the wrong action is expensive.

The distance between those two is not purely a model capability problem, and it will not be closed by a better model alone. It is a problem of task structure — whether the work can be described precisely enough, verified cheaply enough, and undone easily enough for autonomy to be safe.

That distinction matters because it tells you where to look. Teams that succeed with agents are often not using better models than teams that fail. They are pointing them at different work.

What agents are genuinely good at right now

Three categories are working in production today.

Bounded, high-volume steps. Taking one structured input, applying a rule, and producing one structured output, at a scale a human would find tedious. Classification, routing, extraction, enrichment, deduplication. These work because success is checkable and the blast radius is small.

Retrieval and synthesis across many sources. Gathering from a dozen places and producing a first pass that a human then verifies. The value is in the aggregation, not the judgment.

First-pass drafting of structured artifacts. The thing that has a template: the ticket, the summary, the changelog entry, the meeting note. The agent produces the shape; a person supplies the meaning.

Notice what these have in common. In each case, a human can tell at a glance whether the output is right.

Where they stall

The failures cluster too, and they cluster in predictable places.

Long-horizon tasks with fuzzy success criteria. "Improve our onboarding" is not a task. It is a goal, and goals do not decompose themselves. The longer the horizon, the more the agent has to make judgment calls it has no basis for, and the more those calls compound.

Irreversible actions. Sending the email, charging the card, deleting the record, deploying to production. Any step you cannot undo turns every small error into an incident, which means every step needs review, which means the autonomy was theoretical.

Brittle integrations. Agents are only as good as the systems they can touch. An undocumented API, a login flow that breaks on a cookie change, or a tool that returns a success code with an error inside the body will defeat an otherwise capable agent — and it will do so intermittently, which is worse than failing consistently.

Work where errors are silent. This is the dangerous category. If the agent gets something wrong and the output still looks plausible, the error propagates. Silent failures are why agents need observability more than they need intelligence.

Three questions that predict the outcome

Before committing a workflow, ask:

1. Can success be verified automatically? If a test, a schema, or a rule can confirm the output, the agent can iterate and self-correct. If only a human can tell, you have built a very expensive draft generator.
2. Is the action reversible? If yes, let it run and fix mistakes. If no, insert a human approval step — and accept that you have built a co-pilot, not an agent.
3. Is the failure loud or quiet? Loud failures are manageable; you will see them. Quiet failures are the ones that cost you a quarter.

A workflow that answers yes, yes, loud is a genuine automation candidate. One that answers no, no, quiet is not a candidate at any level of model quality.

Designing guardrails that survive contact

Guardrails are not a feature you add later. They are the design.

• Approval points on irreversible steps. Keep the reversible steps autonomous and gate the rest. This preserves most of the speed with none of the exposure.
• Idempotency. Running the same step twice should not double the effect. This is what lets you retry safely, and retries are where reliability actually comes from.
• Observability by default. Log the inputs, the tool calls, the intermediate steps, and the outputs. When something goes wrong at 3am, the log is the only thing that tells you why.
• Budget caps. Agents can loop. A cost ceiling is not paranoia; it is the difference between a bug and an invoice.

A realistic adoption path

Start with one workflow, not a platform. Pick something high-volume, low-stakes, and easy to verify. Run it in shadow mode alongside the human process and compare outputs before you let it act. Measure the intervention rate — how often a person has to step in — because that number, not the demo, is the real readiness signal.

Then expand by adjacency. The second workflow should look like the first. Teams that jump from a working classification agent to a fully autonomous operations agent usually end up with neither.

The question to ask before you start

Not "what can this agent do?" but "what is the smallest useful thing it can do reliably?"

That reframing does most of the work. It forces you to name the task, the success condition, and the failure mode before you have invested in the platform. And it produces something you can actually ship, which is worth more than an impressive pilot that never leaves the sandbox.

Agents are real and they are useful. They are just narrower than the marketing suggests, and the narrowness is structural rather than temporary. Knowing where the edges are is the whole skill.