For a while the agent was a demo. It booked a meeting, summarised an inbox, filed a ticket in a sandbox. Everyone nodded, and the pilot went back on the shelf.
That is changing. Agents are now being given real work inside real processes: triaging claims, reconciling invoices, preparing change requests, routing support cases. The model is not the hard part any more. The workflow around it is.
What changes when an agent touches production
A pilot answers one question: can the model do this task? A workflow deployment has to answer several more.
- Who owns the outcome when the agent acts and the result is wrong
- Which systems it may write to, with which permissions, through which interfaces
- What happens on failure — retry, escalate, roll back or stop
- How a person sees what it did, after the fact and in the moment
- How the process measures success compared with the old path
None of these are model questions. They are product, integration and operations questions, and they decide whether the agent survives its first month.
Start from the process, not the capability
The most common mistake we see is starting from what the agent can do and looking for somewhere to put it. That produces impressive features nobody uses.
Start instead from a process with a clear owner, a known volume and a measurable pain. Map the steps as they happen today, including the workarounds. Then decide which steps the agent drafts, which it executes, and which stay entirely with people.
Most good first deployments are narrower than the pilot. That is fine. A narrow agent that runs every day beats a broad one that runs in a slide.
Autonomy is a dial, not a switch
Agents in production rarely run fully unattended on day one. A sensible pattern is to set autonomy per action class:
- Read and summarise — automatic
- Draft a change or response — automatic, with a person approving before it goes out
- Low-risk writes — automatic below a confidence threshold, sampled for review
- High-risk or irreversible actions — never automated, or only with explicit sign-off
The dial moves as evidence builds. Evaluation results, override rates and sample reviews tell you when a class of action has earned more autonomy. Moving it without evidence is how trust gets lost.
Integration is most of the work
An agent is only as useful as the systems it can reach. In practice that means stable, well-scoped APIs with clear contracts, not screen scraping or shared admin credentials.
Expect to spend real effort on:
- Service accounts with least-privilege permissions
- Idempotent write operations so retries do not duplicate work
- Clear error responses the agent can reason about
- Logging every tool call with inputs, outputs and the model version
If the target system has no usable API, building one is often the first deliverable. It pays off for every automation that follows, not just the agent.
Operations from the first release
Once an agent acts, someone has to watch it. That means dashboards for volume, success, escalations and cost; alerts when behaviour drifts; and a runbook that says who gets paged and what they do.
It also means a way to pause. A kill switch per workflow, tested before go-live, is cheap insurance. So is a clear path back to the manual process when the agent is off.
Measuring what matters
Track the process, not the model. Useful signals include:
- Time to complete the task compared with the baseline
- Share of cases handled end to end without rework
- Override and escalation rates by case type
- Errors caught in sampling, and how they were caught
Review these with the business owner regularly. If the numbers do not move, the problem is usually workflow fit or integration gaps, not the model.
Where to start
- Pick one process with a named owner and a measurable pain
- Map the current steps and decide autonomy per action class
- Build or harden the APIs the agent needs before building the agent
- Put logging, evaluation and a kill switch in the first release
- Agree the success metrics with the business before go-live
Agents that act need the same engineering discipline as any other production system. If you want help scoping the first one, we are happy to talk.