Surface
In this essay6 sections
"Agentic" has become one of the most overused words in product marketing, often describing nothing more than a chatbot with a few tool calls bolted on. Real agentic AI, the kind that actually completes multi-step work reliably, looks less like a conversational interface and more like a carefully bounded workflow: defined permissions, logged decisions, explicit stopping conditions, and a human checkpoint at the moments that matter. Products that treat agentic capability as chatbot theater tend to produce demos. Products that treat it as workflow engineering tend to produce something operators can actually trust in production.
The scale of the gap between excitement and disciplined deployment is visible in the numbers. McKinsey's late-2025 research found that around 88% of organizations use AI in at least one business function, but only about 23% report scaling agentic AI approaches in a meaningful way, and only roughly 39% see any measurable EBIT impact from AI at all. McKinsey identifies a smaller group, around 6% of organizations, as high performers capturing outsized value, and the pattern separating them from the rest is not more ambitious agent design. It's operational discipline: clear boundaries, monitoring, and governance around what the agent is allowed to do.
What makes something actually agentic
An agent, in the meaningful technical sense, is a system that can take a goal, decide on a sequence of actions to achieve it, execute those actions using tools (APIs, databases, code execution), observe the results, and adjust its next action based on what it learned. That's meaningfully different from a chatbot that calls a single tool once per turn and returns a response. Real agentic behavior involves loops, branching, and the possibility of the system taking actions the user did not explicitly specify in that exact form.
That extra autonomy is exactly why agentic systems need more operational infrastructure than conversational ones, not less. A chatbot that gives a wrong answer is embarrassing. An agent that takes a wrong action, issues a refund it shouldn't have, sends an email to the wrong recipient, modifies a database record incorrectly, is a production incident.
The four controls that separate a workflow from theater
Permissions, scoped tightly
An agent should have access to exactly the tools and data it needs for its defined task, nothing broader. "Give the agent database access" is not a permission scope; "give the agent read access to the orders table and write access limited to a status field, for orders under a defined dollar threshold" is. Broad, convenient permissions are the single most common way an agentic feature turns into a security or operational liability. Scope permissions the same way you'd scope a junior employee's system access: to the minimum needed for the job, expanded only with evidence of need.
Audit logs for every tool call
Every tool call an agent makes, what it called, with what parameters, and what it received back, should be logged in a way a human can review after the fact. Those logs are how you diagnose production issues. When an agent produces an unexpected result, the audit trail lets your team distinguish between "the model reasoned incorrectly," "the tool returned bad data," and "the permissions were too broad," which each require a completely different fix.
Kill switches that actually work
There should be a fast, reliable way to stop an agent, or an entire class of agent actions, without a deploy cycle. This matters for the mundane case (a bug causes unexpectedly high API spend and someone needs to stop it now) and the serious case (an agent is taking actions that look wrong and someone needs to halt it while the team investigates). A kill switch that requires an engineer to push a code change under pressure is not a real kill switch.
Human-in-the-loop at the decision points that matter
Not every agent action needs human approval (that would defeat the purpose of automation), but the actions with real consequences (financial transactions above a threshold, irreversible operations, anything affecting a customer relationship) should route through an approval step rather than executing autonomously. Name the specific steps where the cost of a mistake justifies the friction of an approval gate, and leave the rest automated.
A comparison: chatbot theater vs a real agentic workflow
| Aspect | Chatbot theater | Real agentic workflow |
|---|---|---|
| Tool access | Broad, "just in case" access to many systems | Scoped to the minimum needed for the defined task |
| Action visibility | Conversation transcript only | Structured audit log of every tool call and result |
| Stopping mechanism | Requires a redeploy or manual intervention in code | Fast, operator-accessible kill switch |
| High-stakes actions | Executed autonomously if the model decides to | Routed through a human approval step |
| Failure diagnosis | Unclear whether the model, the tool, or the data was at fault | Traceable to a specific tool call, parameter, or permission boundary |
| Cost predictability | Can spiral in retry loops with no step limit | Bounded by a maximum step count and monitored spend |
Why this discipline correlates with actual EBIT impact
McKinsey's finding that only about 39% of organizations see any measurable bottom-line impact from AI, despite 88% adoption, points to a pattern: deploying AI broadly without operational discipline produces activity without results. The roughly 6% of high performers usually share governance infrastructure (permissions, monitoring, approval workflows) that lets them put agentic capability into processes that matter, with enough confidence that the deployment survives contact with real edge cases and does not get quietly turned off after an embarrassing incident.
That split matches the AI MVP pattern we describe elsewhere: the model-capability question ("can it do the task") and the operational question ("can we trust it to do the task unsupervised, safely, at scale") are separate, and skipping the second one is a major reason pilots do not graduate to production. Our piece on AI MVP scoping covers the model-capability side in depth; this piece is about the operational side that has to accompany it once an agent has tool access.
Choosing where agentic capability actually belongs
Not every AI feature needs to be agentic, and forcing agent architecture onto a task that a single well-grounded response could handle adds exactly the operational overhead described above without a matching benefit. Our comparison of RAG, fine-tuning, and agents covers how to decide when a task genuinely needs multi-step, tool-using behavior. Reach for agentic architecture when the job has real sequential steps with branching logic, and treat the four controls above as required build work before launch.
A practical readiness checklist
Before shipping an agentic capability into production, confirm:
- Tool access is scoped to the minimum required for the defined task, not granted broadly for convenience
- Every tool call is logged with parameters and results in a reviewable format
- A kill switch exists that an operator can trigger without a code deploy
- High-consequence actions route through a human approval step, with the threshold explicitly defined
- A maximum step count and cost ceiling prevent runaway loops
- The team has a plan for who reviews audit logs and how often, including a named owner and cadence
Teams that build these controls in from the start ship agentic features that survive contact with real operators and real edge cases. Teams that treat agentic AI as a chatbot with extra steps tend to produce a compelling demo that gets quietly shelved after its first production incident.
Looking to add agentic capability to a product responsibly? Explore our AI & ML solutions, or see how we approach AI delivery before scoping the workflow.
