For two years, the question put to generative AI was: "what can you answer?" It is becoming: "what can you do?" The shift is considerable. An assistant that gets it wrong produces an answer to correct. An agent that gets it wrong produces an action to undo — a ticket routed to the wrong team, an order created twice, an access right opened by mistake. That is no longer the same job, and no longer the same set of requirements.
This shift does not depend first on the power of the models. It depends on what surrounds them: the context they can reach, the tools they can call, the rules that frame them, the workflows they sit inside and the controls that watch them. In other words, it belongs to the architecture and the governance of the information system, not to the AI technology alone.
From assistant to agent
Three levels have followed one another, and today they coexist in most organisations.
The assistant answers. You ask a question, it produces text. It knows of the context only what you give it in the conversation, and it touches nothing. Its value is real but bounded: it saves time on drafting and searching.
The copilot assists inside a tool. It sees what the user sees — an open ticket, a document in progress, a customer record — and suggests: a rewording, a classification, a standard reply. The decision and the action stay human.
The agent pursues an objective. Where the copilot suggests, the agent carries through. Concretely, an agent can:
- interpret an objective expressed in natural language or triggered by an event;
- gather the context it needs, by querying documents and systems;
- call tools — an API, a query, an application transaction;
- chain several steps together, taking account of the result of each;
- carry out an action that changes the state of a system;
- stop and ask for human approval when the conditions call for it.
That last point is often treated as a detail. It is in fact the heart of the matter: an agent that is useful in a company is not one that decides everything, it is one that knows where to stop.
Why workflows become essential
An agent left to itself is a demonstration, not a production set-up. To produce value durably, it has to sit inside something that existed before it.
It needs a process: a known sequence of steps, with a beginning, an end and identifiable intermediate states. It needs rules — what is permitted, what is not, under what conditions. It needs rights: an agent always acts on behalf of someone or something, and the scope of that mandate must be explicit, narrow and revocable. It needs existing systems to query and update, with the integration constraints that implies. It needs an escalation path for the situations it cannot handle — and it has to recognise them. Finally, it needs controls: checks before acting, traces afterwards.
The division of labour is simple to state. The agent brings the capacity to reason and to act; the workflow brings the operating frame. Neither holds without the other: an agent without a workflow is ungovernable, a workflow without an agent stays rigid the moment the situation leaves the nominal case.
That is why organisations that had already invested in structuring their processes — service catalogues, approval circuits, reference data kept current — move markedly faster on agentic AI. Not because they have better models, but because the frame was already there.
The main use cases
The uses that hold up in production look alike: a process already structured, data that is reachable, a bounded perimeter of action.
IT operations and ITSM. This is the most mature ground, because the processes are documented and the tools instrumented. An agent can qualify an incident from its description, categorise it, enrich it with the history of the device or the user, route it to the right team, search the knowledge base, propose a resolution, trigger a known remediation action — restarting a service, resetting an account — and escalate when the diagnosis stays uncertain. Qualification and routing are often the first gains: they are frequent, low-risk and measurable.
Internal services. Request management, onboarding a new joiner, HR questions, purchase requests, reconciliations in finance, access and entitlement requests. These processes cross several applications and involve a great deal of collecting and chasing — exactly what an agent sitting behind a service portal handles well. Entitlements, on the other hand, call for particular caution: opening a right is easy, measuring the consequences less so.
Customer service. Qualifying an incoming request, finding the context in the file and the history, preparing an answer submitted to an adviser, carrying out the follow-up actions, updating the record. The most solid pattern remains the one where the agent prepares and the human approves, at least until measured quality justifies going further.
Business processes. Collecting information from several sources, checking consistency, preparing a file for approval, orchestrating between applications that do not talk to one another directly. That is often where the gap with classic automation is clearest: fixed rules handle the nominal case, the agent absorbs the variability.
Orchestration: the real subject
Value does not come from the model alone. It comes from the ability to hold together data, tools, APIs, workflows, possibly several agents, and points of human approval. It is an integration and governance problem before it is an AI problem.
This orchestration layer can rest on environments organisations already run: service and workflow management platforms such as ServiceNow, automation tools such as n8n or Power Automate, orchestration services from the major cloud providers, or the business APIs exposed by the information system. None of these platforms settles the question on its own: they provide a foundation for execution, traceability and rights, on which the agentic logic is placed.
Choosing that foundation poses itself in the same terms as any architecture decision: what already exists, what the teams know how to run, what the service contract demands, what reversibility requires. We assess it on its own merits, with no vendor assumed — that is the sense of our work on integration with the information system.
How far should you automate?
Not all actions can be entrusted in the same way. It helps to reason in increasing levels of autonomy, and to assign them action by action.
- Reading — the agent consults, reports back, summarises. No side effects.
- Suggestion — it proposes a classification, an answer, a decision. The human chooses.
- Preparing an action — it assembles the file, fills the form, drafts the request. Nothing is sent.
- Execution under approval — it acts, but only after an explicit, recorded agreement.
- Autonomous execution — it acts alone, within a defined perimeter and under watch.
The level chosen depends on five factors: the risk attached to an error, the criticality of the process concerned, the reversibility of the action — undoing a ticket routing does not cost what undoing a payment costs — the quality of the data available, and the traceability the set-up actually delivers.
A simple rule follows: an irreversible action on a critical process should not go beyond level 4, whatever the measured quality of the agent. And autonomy is earned progressively, as the measurements accumulate — it is not decreed at the start.
Quality and evaluation of AI agents
An agent that acts must be evaluated more strictly than an assistant that answers. That is the point successful demonstrations make you forget, and the one that decides whether it goes into production.
Evaluation begins with explicit acceptance criteria: what is a good incident qualification, a good file preparation, a good refusal to act? Those criteria translate into test sets built on real business scenarios, edge cases included — ambiguous requests, missing data, unusual phrasing.
Then robustness has to be tested: what does the agent do when an API does not answer, when a right is refused, when two sources contradict each other? Two families of error deserve separate treatment — hallucinations, where the agent produces information with no basis, and tool errors, where it calls the right function with the wrong parameters, or the wrong function. The second is more dangerous, because it produces a real effect.
Those evaluation sets then become non-regression tests: a change of model, of prompt, of tool or of platform version can silently degrade a behaviour that used to work. Human evaluation stays necessary where business judgement does not reduce to a rule — but it has to be sampled and framed, not left to general impression.
In production, the set-up rests on three pillars: monitoring of failure, escalation and human pick-up rates; supervision by teams who know how to interrupt an agent and take over; and traceability of every decision — what context, which tool called, which parameter, which result, which approval. Without that trace, no incident can be analysed, and no responsibility established.
That is exactly the scope of our expertise in evaluating and assuring the quality of AI systems, and the natural extension of the testing and acceptance practices we apply to transformation programmes.
A reference architecture
The chain reads from left to right, and any link can bring the whole down.
User or event — a request put into words, or an automatic trigger: ticket created, threshold crossed, file received.
AI agent — interprets the objective, decides how to proceed, chooses the tools.
Context and RAG — documents, reference data, history: what the agent must know so as not to invent.
Tools and APIs — the actions it may take, strictly enumerated, with the rights that go with them.
Workflow — the frame: states, rules, transitions, escalations.
Approval — the human stopping point, when the chosen level of autonomy requires it.
Action — the real effect on a system, and its acknowledgement.
Monitoring — continuous measurement, feeding both daily supervision and decisions to widen the perimeter.
A pragmatic trajectory
Six stages, in this order, to avoid both the pilot that leads nowhere and premature industrialisation.
Identify. Find the high-volume processes, already structured, where variability penalises classic automation. The criterion is not appetite for technology, it is repetition and friction.
Scope. Bound the perimeter of action, the rights, the level of autonomy aimed at and the acceptance criteria. This is where most of the risk is decided.
Prototype. Build a narrow version on real cases, to measure the gap between intention and observed behaviour — not to prove feasibility, which is settled.
Orchestrate. Connect the agent to the existing workflows, systems and approval circuits. This is the longest step, and the one demonstrations skip over.
Evaluate. Build the test sets, measure, correct, re-evaluate. No widening of autonomy without measurement first.
Industrialise. Supervise, trace, maintain, evolve — and treat the agent as an ordinary application component, with its life cycle and its debt.
What actually decides the outcome
The move from assistance to execution is not settled by the power of the models. It is settled by the quality of the orchestration, the precision of the rules, the soundness of the controls and the integration with the information system. The organisations that make this move will not be those that adopted the technology earliest, but those that knew how to bound what they entrust, measure what happens, and keep hold of what matters.
It is a subject of architecture, process and governance — which is to say a subject of advice as much as of technology.
We work through these trajectories at the crossing of two areas of expertise: AI agents and intelligent automation. If the subject is live for you, the most useful thing is to talk it through from your own use cases.
