A distributor in Bengaluru wired an agent into its purchase order inbox last year. The pitch was simple: read the supplier email, extract the line items, match them against the open PO, flag mismatches. It worked in the demo and it worked for six weeks. Then a supplier changed its PDF template, the extraction silently drifted, and eleven orders were approved against quantities nobody had checked. Nothing about the model had changed. The process around it had never been designed to notice.
That is the honest state of agentic automation right now. The models are good enough. The scaffolding usually is not.
What Separates a Workflow From an Agent
A workflow is a fixed sequence you wrote down. An agent decides the sequence at runtime based on what it observes. That difference is the whole source of the value and the whole source of the risk.
Anthropic’s own guidance on building effective agents makes the point bluntly: most problems that people reach for agents to solve are better served by a deterministic chain with one model call in the middle. Agents earn their keep when the path genuinely cannot be enumerated in advance, such as triaging a support ticket that could touch billing, provisioning or a bug, or reconciling an invoice against three systems that disagree.
A useful test before building anything: if you can draw the flowchart, build the flowchart. If you draw it and it has forty branches that all depend on what the previous step found, you have an agent-shaped problem.
The Controls That Make Them Safe to Run
The teams getting real production mileage out of agents converge on a similar set of guardrails.
- Step and token budgets. Every run gets a hard ceiling, typically 15 to 25 tool calls. An agent that exceeds it stops and escalates rather than looping. Unbounded loops are the single most common cause of both runaway cost and silent failure.
- Scoped credentials per tool. The agent that reads the inventory database should not hold write access to it. Least privilege applies to machine actors exactly as it does to people, and it is what keeps a bad plan from becoming a bad outcome.
- Idempotency on every side effect. Retries are normal in agent systems. If the same run can create two purchase orders, the design is wrong. Every write carries a key derived from the business event, not from the attempt.
- A human checkpoint tied to value, not to confidence. Model confidence scores are poor gates. Thresholds tied to rupee amounts, customer tier or irreversibility are far more defensible when someone asks why an action was taken.
- A full run log, not just the answer. Every tool call, input, output and decision, retained. Without it, debugging a bad run is guesswork and there is nothing to show an auditor.
Measure the Process, Not the Model
The mistake we see most often is teams benchmarking the model and declaring victory. What matters operationally is end to end: what percentage of runs completed without escalation, what percentage of escalations were correct escalations, what the median wall clock time was compared to the human baseline, and what the cost per completed task came to.
Those four numbers tell you whether to expand scope or pull back. A 70 percent full automation rate with clean escalation on the rest is usually a strong result. A 95 percent rate where the 5 percent fails silently is a liability.
Build the evaluation set before the prompt. Twenty to fifty real cases with known correct outcomes, drawn from actual history, will tell you more in an afternoon than a month of prompt tuning against intuition.
At Invexa, we treat an agent as an operational system rather than a model deployment. Budgets, scoped credentials, escalation paths and run logs go in before the first prompt is written, because those are the parts that determine whether the thing is still trustworthy in month six.