What are companies actually buying when they buy enterprise AI agents?
Companies buying enterprise AI agents are buying software that acts, not software that answers: it opens tickets, edits records, sends messages and, in engineering, changes code that ships to production. The purchase is usually framed by function (support, sales, operations, development) and priced by seat or by usage. What the contract rarely covers is accountability for the output. Gartner predicted on June 25, 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls. The third reason is the one a buyer can settle before the pilot: decide which actions the agent may take alone, which need a person's approval, and which stay human-only, then require a record that shows each action and who signed. An agent has only been delegated work once someone has agreed, in writing, to answer for what it delivers.
The same Gartner release also points at "agent washing", the rebranding of assistants, RPA and chatbots as agents, and estimates that only about 130 of the thousands of vendors claiming agentic products are real. For a buyer this means the label on the product tells you little. The useful question is what the product is allowed to change, and what it leaves behind when it does.
Why is delegation without accountability not delegation?
Delegating to a person works because a name is attached to the result. If a contractor ships a bad change, someone answers for it, and the client knows who. An agent has no standing to answer. When the vendor's terms say the customer is responsible for reviewing outputs, and the customer's team approved the pilot because the demo looked good, the responsibility sits with nobody in particular until something breaks.
In software this shows up late and expensively. Code written by an agent merges, the session that wrote it ends, and months later nobody can say what the agent was allowed to touch or who looked at the diff. We covered the same pattern for what an AI coding agent leaves behind after a session, and the point generalizes beyond code: the output of an agent is only as defensible as the record that came with it.
Automatic, assisted, human-only: how do you draw the line once?
The simplest way to avoid both blanket trust and blanket fear is a contract of autonomy with three columns, written per function and per repository before the pilot starts, not after the first incident.
| Automatic | Assisted | Human-only | |
|---|---|---|---|
| Who acts | The agent, alone | The agent prepares, a person decides | A person, with the agent at most as a reader |
| Typical examples | Formatting, drafting, running checks, summarizing | Code changes, customer replies, config changes | Release signature, product decisions, regulatory choices, client relationship |
| What must be recorded | That it ran, and what it touched | The proposal, the check results and who approved | The decision and the person who took it |
| What goes wrong if misplaced | Silent errors at scale | Rubber-stamping, approval as a reflex click | Slow, but rarely dangerous |
The rule that makes the table work is that it moves one way only by decision: an action goes from assisted to automatic because someone wrote that down, not because the agent has been right often. Even vendors pushing hardest on autonomy keep a checkpoint, as the auto mode of Claude Code and the human signature shows: the system prepares, the person signs.
What should you ask a vendor before the pilot?
Questions that turn a sales conversation into something you can compare across vendors:
- What can the agent change without asking, and can that list be configured per team or per repository?
- Where is the log of what it did, who can read it, and how long does it last after the session ends?
- Which step requires a named person to approve, and is that approval recorded as an event, not as a checkbox?
- If the agent's output turns out to be wrong six months later, what do I have to show who authorized it?
- What happens to the record if we change vendor or model?
None of these questions needs a technical background to ask, and none needs a long pilot to answer. They need the buyer to treat the agent like a supplier who will sign for nothing, and to decide in advance who inside the company does. If the vendor cannot say where the line sits between automatic and assisted work, the line is wherever the agent happens to put it.
A vendor that answers the first two well and dodges the last three is selling capability, not delegation. The same reasoning applies to a tool that tracks work on a kanban board: tracking tasks is not the same as proving who accepted the result.
What record makes the answer repeatable?
An answer to "who signed this" is only useful if it can be given again, by someone who was not in the room. That needs three things stored outside the agent's own session: what the agent was authorized to do, the independent check that ran on the result (tests, build, review of the diff itself), and the signature of the person who accepted it. Each is cheap to store at the moment of the change and impossible to rebuild afterwards.
This is the layer Detent (detent-ai.com), the end-to-end delivery system, puts above the agent: every change on the line carries its authorization, its verification and a human signature before release. You can compare how that differs from agent-only tools in the comparison on the home page.