Enterprise AI trends now orbit a single word: agent. The pitch is a coworker that does not only draft. It takes actions—files a ticket, updates a record, emails a customer, runs a query—across the tools a company already pays for. Sometimes that pitch describes a narrow, logged, reversible automation with a language interface. Sometimes it describes theater: a chat window that narrates work another system, or another person, still has to finish.
AI product reviews for businesses should start by asking which of those objects is on offer. I have sat through demos where the “agent” was a script with a friendly voice, and demos where a model actually called tools and changed state. Only the second one can fail in a new way. Only the second one can save a new kind of time.
What an Agent Is, Without the Costume
An agent, in the sense that matters to IT, is a system that can plan, call tools, and continue until a stopping condition. The stopping condition might be a completed form, a human approval, a budget cap, or a dead end. If there is no tool use and no state change, you have a chatbot with a job title.
That definition is intentionally dry. Dry language makes the risks visible: permissions, looping, silent side effects, and the difficulty of reproducing what happened.
Conditions that separate a coworker from a narrator
It can take an action in a system of record, not only describe the action.
Those actions are attributable to an identity you can revoke.
There is a ceiling on spend, rate, and blast radius.
A human can inspect the tool calls, not only the final paragraph.
Failure is loud. Silent success on the wrong record is the nightmare case.
Read the announcement. Then read the incentives. The incentive is to use “agent” because it sounds like labor substitution. Labor substitution is a larger budget conversation than “summarize this thread.”
Where Agents Are Already Mundane
The useful versions I have seen tend to be narrow. They live inside a ticketing system, a coding environment, or a retrieval-heavy internal search. They have a small tool list. They are evaluated on whether the ticket is correctly filled, not on whether the prose is charming. They are boring in the way payroll is boring.
The theatrical versions have a large tool list, a keynote metaphor, and a weak story about identity. They can book a calendar in the demo because the presenter is logged in as a god. They struggle when the actual employee can see only their region’s accounts.
A comparison buyers can use
Question | Narrow agent | Workflow theater |
|---|---|---|
Tool list | Few, named, permissioned | “Works with your stack” |
Identity | Service account or user-delegated, revocable | Shared magic token |
Oversight | Transcript of tool calls | Chat recap |
Reversibility | Undo or ticket-based rollback | “We’ll fix it” |
Metric | Completed tasks with error rate | Engagement with the chat |
If a vendor cannot fill the left column, you are not looking at a coworker. You are looking at a new front end on the same work.
What IT Teams Should Demand Before a Rollout
I am not anti-agent. I am anti-surprise. A system that can email customers or change financial records is a privileged user. Privileged users get onboarding, logging, and a person who owns the incident channel.
A rollout list that is deliberately unglamorous
Map every tool the agent may call and the least privilege it needs.
Pin model and tool versions so yesterday’s behavior can be reconstructed.
Decide which actions never go out without a human, regardless of model confidence.
Load-test the review queue. If reviewers cannot keep up, the loop is fake.
Run a red-team day on prompt injection from content the agent will read (tickets, emails, web pages).
Price the oversight hours, not only the tokens.
Prompt injection deserves a special mention. If an agent reads untrusted text and then calls tools, the untrusted text is now in a position of influence. That is not a reason to panic. It is a reason to treat the pattern like you would treat unsanitized input in any other system.
How I Will Cover the Next Wave of Agent Launches
I will keep asking what changed in the system of record. If the answer is “the summary is nicer,” I will write a feature update. If the answer is “it closed 40 tickets and opened two bad ones, and here is the log,” I will write a product story. The second story is rarer. Rarity is information.
Here is what changed, and what did not. Tool-calling models got good enough that agent demos are no longer science fiction. Most enterprises still run on permissions, audits, and people who are accountable when a customer is angry. This is meaningful capability. It is not yet a replacement for those people, and it is not a reason to confuse a narrator with a coworker.
Who really benefits, and who really pays? Vendors benefit from the labor metaphor. Platform owners benefit if agents deepen lock-in to their APIs. The people who inherit the exception queue pay. Count them before you count the savings.
No notes on this sheet yet.