Seven questions before you give an agent decision rights

In June 2025 Gartner predicted that over 40% of agentic AI projects would be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Model quality isn’t on that list. Agents mostly stall not because they can’t do the work, but because nobody is sure what they’re doing or what it costs.

We’ve built change-management, monitoring and incident-response frameworks inside client organisations, and at the heart of that work is a plain fact: putting a system live means giving it authority. For RPA bots that authority was narrow; a bot followed steps someone had written down. An agent picks its own next step. So the questions you ask before signing off go-live change too. Here are mine.

1. Does it decide, or recommend?

The same agent carries very different risk in the two roles. An agent that classifies a supply anomaly and puts it in front of a person is recommending. An agent that lifts a payment block on its own is deciding. Write this down for every action in the design document. “The agent does X” isn’t enough; say “the agent proposes X and this person approves” or “the agent does X and stops in this situation”.

2. Can a wrong decision be undone, and what does it cost?

I suggest ranking actions on two axes: can it be reversed, and what does a mistake cost? Reversible, cheap actions can be left to the agent. Irreversible or expensive ones need a human approval gate. That gate isn’t an admission that the agent falls short; it’s a deliberate split of authority. Where the gate sits can change over time, too. As the records show the agent is reliable on a given type of action, you can pull the gate back.

3. Which tools can it reach, and under which identity?

Every tool an agent can call is a list of everything it can do. An agent running with a human user’s permissions can make every mistake that user could. You need a separate service identity, only the tools it needs, and the narrowest permissions that work. The July 2026 release of the Model Context Protocol helps here: method and tool names now travel in HTTP headers, so a gateway can see which tool is being called and apply policy without opening the request body.

4. Did you define “correct” before writing the agent?

An agent project without acceptance criteria is a demo that never ends. Before writing the agent, build a small evaluation set from real examples: for this input, which output is right, which is acceptable, which is wrong? That set becomes the basis for acceptance testing and for regression testing after every prompt change. On outsourced projects it belongs on the list of deliverables.

5. Does every run leave a trace?

When an agent does something wrong, the first question is “why?” To answer it you need, for every run, a record of the input, the tools called, what they returned, the model’s output and the cost. Those records are the raw material of incident response; without them every investigation is guesswork. There’s a second benefit: the trace shows what each task costs, which makes the budget conversation concrete.

6. Does it touch personal data?

On 12 March 2026 Türkiye’s data protection authority, KVKK, published guidance on agentic AI systems. According to the legal summaries, it expects organisations to have a data-governance framework and risk assessment covering their use of agentic AI, clear responsibilities between the parties processing data, human oversight designed in from the start, privacy by design and by default, and staff who understand what these systems do with data. Each of those maps onto one of the questions above. If your agent processes personal data, write that mapping down. It’s the first document an auditor will ask for.

If you serve the EU there’s one more item. The AI Act’s transparency obligations were not postponed by the new regulation. An agent that corresponds directly with people has to tell them they are dealing with an AI system.

7. What happens when you switch it off?

This is the question asked least. When the agent fails, when its cost jumps unexpectedly, or when the model provider changes something, who takes over the work? I expect every agent to have a written fallback: if a rule-based robot can do the same job, that robot should be on standby; if not, the work should drop into a human queue. Who holds the off switch, and which signal triggers the decision to use it, should be written down as well.

If the answer is “we don’t know”

If the answer to any of these seven is “we don’t know”, you aren’t running an agent in production. You’re running a pilot in production. That’s fine, as long as everyone knows it’s a pilot. The trouble starts on the day a pilot is budgeted like a product and audited like one.