The Questions Enterprises Should Ask Before Deploying Agentic AI
Enterprise procurement was built for software that informs. A dashboard presents. A CRM records. A reporting tool assembles. In each case a person looks at the output and decides what happens next. The evaluation that grew up around this kind of software makes sense on its own terms. Compare the features. Check the integrations. Watch the demo. Take up references. Form a view on whether the thing works.
Agentic systems break that fit, and they break it quietly, because in a demo they look much the same. They read documents and present findings, as a reporting tool does. The difference is what happens after the finding. The system drafts the notice. It sends the message. It updates the record. It assembles the report. Within whatever limits it has been given, it decides which of those things to do.
Once software acts, the useful question is no longer what it can do. It is how it behaves.
Very little in a standard evaluation surfaces behaviour. A demonstration shows a system on its best day, running a workflow the vendor chose, with the vendor's strongest people in the room. Feature lists describe capacity, and capacity has not been the constraint for some time now. What a buyer actually needs to know is what happens on an ordinary Tuesday in month nine, when the workflow throws up something nobody anticipated, the person who championed the deployment has moved to another company, and nobody is watching closely any more.
Three concerns get at that. Most other questions follow from them.
Authority
An agentic system operates under a mandate, in much the way a new colleague does. It has a scope of work, some limits, and a route for escalating what it cannot handle.
The difference is that a colleague fills the gaps in their brief with judgement. A system's conduct at the edge of its mandate was settled in advance by whoever designed it. Where nobody settled it, the system will still do something at that edge, and the something will be a surprise.
Consider a system that watches a customer's specification documents, identifies what has changed between versions, and notifies the departments affected. There are two versions of that deployment. In the first, the system prepares the notices and a quality manager releases them. In the second, it sends without review, because the drafts looked reliable in testing and the review step began to feel like friction. The capability in both cases is identical. The first is a governed deployment. The second will eventually send a wrong instruction to a customer's factory, and the review afterwards will find that nobody ever decided the system should have been able to do that.
The authority questions are therefore not about trusting the technology. They ask whether the line between machine action and human judgement was drawn deliberately, written down, and built into the architecture, rather than left in a policy document that assumes everyone remembers it.
They also ask what happens at the boundary. A system that pauses when it is uncertain and refers the matter to a person, with its reasoning attached, is behaving as designed. A system that proceeds confidently through ambiguity will perform well in a demonstration and cause damage in production. The difference between the two is a design decision, and a buyer is entitled to know which one was taken.
Endurance
The most common failure in enterprise AI is silent. Nothing breaks. The system works, the invoices are paid, and within a few months the team has drifted back to the old way of doing things, because the new way asked more of them than it returned. Nobody reports this. It surfaces at renewal, if it surfaces at all.
We have written elsewhere about why documentation fails in manufacturing. The reason is structural. Documentation is a separate activity from the work, and an engineer who has just completed a complex evaluation is already facing the next enquiry. The choice between writing up the reasoning behind the last job and starting the next one is not a real choice. The next job wins, every time.
Adoption obeys the same logic. If a senior estimator has to re-enter into a new system what he already holds in his own spreadsheets, he will use it for exactly as long as somebody is checking. If the system takes his spreadsheets as they are, works in the channels he already uses, and saves him effort on the first day, nobody has to be persuaded of anything.
Adoption is therefore settled in the design, during the first weeks of an engagement. Training at the end cannot repair a system that was built without the people who have to live with it. When a vendor is asked how adoption will be achieved and answers with a change management plan, the design has not done its share of the work.
Measurement is the other half of endurance, and it fails in a particular way. The system goes in, early impressions are good, and two quarters later nobody can say whether it is working well enough, because the starting point was never recorded and success was never defined. The engagement then runs on goodwill. That is an uncomfortable basis for a renewal conversation, and it is uncomfortable for both parties.
The order matters here. The baseline comes first, drawn from the client's own records, before anything is built. If quote turnaround is the problem, that means the present turnaround, measured from enquiry received to offer sent, over a period long enough to be honest. Then the definition of success against that baseline. Then the deployment. Then a fixed review rhythm, whether or not anyone is asking for it.
A vendor who resists that order is asking to be funded for an experiment whose results they will narrate to you later.
Ownership
Agentic systems touch the material an organisation would least like to lose control of, because that is where the useful work is. Costing workflows carry supplier rates and margin logic. Compliance workflows carry audit findings. Client-facing workflows carry customer records.
The first questions here are the familiar ones. Where is the data processed, what is retained, for how long, and under whose control. Whether anything is trained on it. Who at the vendor can see it, in what circumstances, and whether that access is logged. These are now standard, and any serious vendor will answer them without hesitation.
There is a further layer, and buyers tend to reach it late.
A well-built deployment does not only complete work. It accumulates a structured record of how the work was decided. In one manufacturing deployment we have described, the first agentic workflow produced a structured product catalogue, a complete audit trail of quoting activity, and standardised commercial templates, none of which the business had possessed before. Those assets would retain their value even if the system that created them were switched off tomorrow.
Over time, that record often becomes the most valuable thing the engagement produced. Whether it belongs to the client should be settled in the contract. At signature, it is a clause. At exit, it becomes a negotiation, and the party holding the record has the stronger position in it.
Why we are publishing this
We have argued before that governance now precedes capability in the buying decision. We are not a neutral party. We build these products and we deploy them, so a buyer who asks these questions will put hard ones to us.
We would rather have that conversation than the other one, in which nobody asks and the deployment quietly dies in month nine. The market is young and crowded, and most vendors make the same promises in the same words, which leaves buyers without a reliable way to separate the serious from the merely fluent. That is bad for buyers. It is also bad for anyone building carefully, because a category littered with failed deployments teaches enterprises to stop trying.
Deployment failures are rarely failures of capability. They are failures of authority left undefined, adoption left to chance, measurement left undone, and ownership left unsaid.
The questions
Send these in advance of the meeting. Ask for the answers in writing, because written answers survive personnel changes on both sides.
On authority
Which parts of this workflow will the system complete end to end?
Where does its authority stop?
Which decisions stay with our people, and is it an architectural boundary?
What does the system do when it is uncertain?
Can the mandate be widened or narrowed after deployment, and who holds that control?
What can the system never do, regardless of configuration?
For any action the system took, can you show what it did, on what basis, and who approved it?
Who may inspect that record: our auditor, our regulator, our customer's auditor?
How are model updates handled, and can we roll back if behaviour shifts?
On endurance
Walk us through the first six weeks for the people whose work changes.
Apart from the training, what in the design makes people keep choosing it?
How will you know in month six whether it is still being used, and by whom?
Who inside our organisation must own this for it to hold, and how much of their time do you need?
Tell us about a deployment where adoption failed, and why.
Who establishes the baseline, and when?
Which numbers will we review together, how often, and against what definition of success?
What happens when the numbers drift?
How many of your deployments have run in production for more than a year, and what changed between month one and month twelve?
What happens if a foundation model you rely on changes, degrades, or is withdrawn?
On ownership
Where is our data processed, what is stored, for how long, and under whose control?
Is anything trained on our data?
Who on your side can see our data, in what circumstances, and is that logged?
If we leave, what do we take with us, and in what form?
What does the subscription cover, what runs on consumption, and what triggers a price change?
Which frameworks do you hold, and can you evidence them on request?
Six things worth noticing in the room
A demonstration that arrives before a single question about your operation.
AI proposed for everything, including problems that a scheduled script would solve.
No curiosity about your baseline.
Adoption described as a training session in the final week.
A change of subject when you ask what you keep if you leave.
Certifications mentioned in conversation and never produced in writing.
Any one of these can usually be explained. Two of them start to look like a pattern.
In closing
For the first few months, a successful deployment and a failing one look much the same from the outside. The evidence that separates them arrives later, by which time the contract has been signed and the alternatives have moved on.
These questions exist to bring that evidence forward, into the room, before the decision is taken. They are not difficult questions. A vendor who has done this work will find them easy to answer.
That is the whole test. Ask them of us, and of anyone else you are considering. Pay less attention to how confidently each answer arrives, and more to whether the vendor had clearly thought about the question before you asked it.
—
Mitochondria is an agentic AI product company based in Amsterdam and Pune. ISO 27001:2022 certified. Classified within the limited and minimal risk tiers of the EU AI Act, with controls aligned to the GDPR, UK GDPR and India's DPDP Act.