Agentic AI: Architecture, Governance and Steering a System That Executes

What “agentic” adds to AI

A generative model produces: it writes, summarizes, translates, codes. An agentic system decides and acts: it sets itself a plan, calls tools, writes into real systems, then verifies what it has just done. The word “agentic” therefore does not designate a family of more powerful models. It designates a layer added around the model — and that layer is made up, for the most part, of things that are not AI: rights, connectors, blocking rules, logs. That is why you can have the best model available and still have no agentic system at all. If what you are looking for first is the overview of the subject, it is in our guide to AI agents.

From the model that answers to the system that executes

Three regimes coexist in most organizations, and confusing them is expensive when the time comes to decide what to automate.

• Deterministic: explicit rules. Reliable, reproducible, easy to audit, but rigid and not very tolerant of uncertainty.
• Probabilistic: statistical generation and prediction. Flexible, but variable, and with no guarantee of accuracy.
• Agentic: reasons, plans and acts through connected systems, often combining the two preceding regimes. Coordination and long-horizon planning remain the areas still maturing.

A chatbot or a “classic” model is excellent at answering and generating, but it stays dependent on a human prompt at every turn and does not act inside your tools. An agentic system plans, calls tools, executes, verifies, logs and raises exceptions. It is this move into action that changes the nature of the problem: the question is no longer the quality of the answer, it is the reversibility of the action. The choice between a system that executes and a system that prepares is settled case by case, and the decision grid is in our comparison of AI agent vs AI assistant.

Autonomy, accountability, control: three notions not to be confused

Everything else in the build follows from three notions that must stay distinct, including in committee discussions.

• Autonomy: the agent runs steps without asking a human at every micro-decision.
• Accountability: the organization remains answerable for the actions (rights, approval, auditability, compliance).
• Control: the agent acts within a bounded scope (objectives, permitted data, tools, thresholds, approvals).

The most common mistake is to treat these three notions as a single slider, as though more autonomy mechanically meant less control. The opposite is true: an agent only gains autonomy to the extent that its scope is correctly bounded, because that bounding is what makes the autonomy bearable for the organization. On the exact meaning of the term, its origin and the notion of agency, the dedicated resource is the agentic AI definition. On results, 98% of companies using agentic AI report a return on investment (Squid Impact, 2025) — a benchmark to read with its usual caveat: these measurements vary with the bases analysed, and they cover organizations that have already passed the production stage. Further benchmarks appear in our review of AI and GEO statistics.

How an agentic AI system runs: objective, plan, tools, verification

An agentic system works in loops, not in isolated requests. Each loop chains four stages, and it is the chaining — not each stage taken separately — that creates both the value and the risk.

• Perception: gather the available signals, the state of the systems concerned and the applicable constraints.
• Planning: break the work into steps, estimate cost and impact, choose a path.
• Action: call tools and produce traceable changes.
• Verification: check compliance, consistency and sources, then correct or escalate.

Without the fourth stage, you still have an agent — but an agent you would be well advised not to let write, since nothing stops a mistake before it feeds the next step. It is verification, and the ability to correct without human intervention on simple cases, that separates a governed chain from one you merely undergo.

The four principles that make an agentic system reliable

An agent is a system that pursues an objective by deciding for itself the sequence of its actions, with tools at its disposal. In production, four architecture principles make that sequence reliable: an explicit objective, multi-step planning, tool calling, and self-verification. These are design recommendations and not a membership test — a system that applies only two of them is still an agent, simply less safe to operate. These four principles can be controlled: each one translates into something that can be instrumented, and each one exposes you to a nameable risk when it is missing. This is the first grid to put on the table in an architecture meeting, before any discussion of the model. It also serves as a diagnostic on a system already in service: in most cases, a disappointing agent does not fail on all four principles at once, but on a single one, and it is almost always the last — the one that costs the most to put in place and that stays invisible until something goes wrong.

Cascade effects: why a small error becomes an incident

In a system that answers, an error is read and corrected. In a system that executes, it becomes the input of the next step. A piece of data misread at step two feeds a decision at step three, which triggers an action at step four: this is what is called a cascade effect, and it is the failure mode specific to agentic systems. A second mechanism is added whenever several teams or several agents share instructions: semantic misalignment, where the same rule is interpreted differently depending on the entry point, produces divergent outputs without any step having failed.

Usage data gives the measure of the ground: 56% of users say they have made mistakes because of AI (Squid Impact, 2025), on uses where nothing was executed automatically. When the output triggers an action, the same proportion no longer reads as an inconvenience but as an incident load. The operational consequence is simple: the longer the chain, the closer the control point has to be to the point of error, not at the end of the journey.

The architecture: orchestrator, tools, memory, policies, guardrails

At company scale, a robust agentic architecture does not come down to “an LLM plus prompts”. Five components must exist and be named; when one is missing, the model is never the cause.

• Orchestrator: sequences, delegates, arbitrates and applies the rules.
• Tools: connectors and APIs into your systems, and callable functions.
• Memory: durable context (instructions, constraints, history of decisions).
• Policies: permissions, scopes, action limits, approval required according to risk.
• Guardrails: tests, checklists, blocking rules, human escalation.

The underestimated point: your results will depend as much on the quality of the data and the rules as on the model. That is particularly true when automatic actions follow one another. If what you need is to characterize the agent itself — what it is, how it differs from a model, which families exist — the detail is in the AI agent definition.

Memory and context: what gets lost between two steps

When a process runs over several steps, loss of context becomes a major risk: inconsistent decisions, repetition, contradictions from one step to the next. Memory is not a convenience, it is what guarantees that step four still knows the constraint set at step one. Three things have to survive: the initial objective and its limits, the decisions already taken together with their rationale, and the sources already consulted together with their date.

Document retrieval completes this set-up: rather than loading everything into the context, the system fetches the information at the moment it needs it. In an agentic configuration, this retrieval becomes active — the system can formulate its own questions, build its context as the task unfolds and trigger further searches without being explicitly asked. It settles the problem of freshness and coverage, not that of consistency: two successive retrievals can still contradict each other if nothing arbitrates between them. The implementation — indexing, retrieval, evaluation — is a subject in its own right.

Specializing by role rather than stacking capabilities

A complex objective is better shared between several specialized agents than handed to a single agent to which capabilities keep being added. Specialization is not a technical refinement: it is a division of responsibility, and it is what makes the separation of rights described below possible.

• Analysis agent: reads the signals, detects anomalies and opportunities.
• Editorial agent: builds a structured request (intent, angle, evidence, expected outline).
• QA agent: applies the compliance, source and consistency checklists.
• Execution agent: prepares the action, generates the tickets, writes into the target system if the authorization exists.

As soon as several agents work on the same objective, a new risk appears: coordination drift, where each one acts correctly within its own scope but the whole fails to converge. Coordinating several agents in production — roles, exchange protocols, conflict resolution — is a separate piece of work from the architecture of a single system.

Governance: who has the right to do what, and who approves

As soon as an agent reaches systems — even on a simple read — security becomes a design subject, not an add-on. Two risks do not in fact depend on the right to write: prompt injection, where an instruction hidden in a document, a web page or a ticket diverts the agent from the objective it was set, and exfiltration, where internal data leaves through the agent's output channel — a reply, a tool call, an outbound request. A read-only agent can therefore be manipulated, and can leak what it consults. It is not only an engineering concern: asked what worries them about AI, 23% of executives place legal risk among their most extreme concerns (Artios, 2026). An executive who discovers after the fact that a system has published, deleted or committed something with no trace will not discuss models: they will cut off access. Governance is therefore what allows an agentic project to last beyond the pilot.

Permissions: least privilege, scopes, separation of roles

The basic principle is least privilege: grant only the rights that are needed, at the right moment, on the right scope. Three rules make it workable.

• Scopes per action: read-only versus write, by content type, by directory or by environment.
• Separation of roles: one agent can propose and another approve, rather than an all-powerful “super-agent”.
• Expiry: temporary tokens, rotation, immediate revocation in the event of an incident.

These rights are distributed according to the risk of the action, never according to the trust placed in the system. The matrix below is the most useful conditional decision to settle before any move into production: it says what the agent does alone, what is checked by sampling, and what does not go out without human agreement.

Human supervision must not be everywhere, or you lose the effect of scale. It has to be placed where the risk is real: high-traffic pages, offer pages, regulated sectors, claims with figures, sensitive comparisons. The opposite excess has its own cost in trust: excessive automation is among the concerns expressed about AI, at 17% (Artios, 2026). A well-built chain does not confuse “automation” with “absence of governance”: the human stays in the loop, but in the right place.

Traceability: reconstructing a decision after the fact

Without traceability, you can neither audit, nor improve, nor protect yourself. The test is simple: six weeks after a disputed action, are you able to say which rule authorized it, which data motivated it and how to undo it? Three objects answer that question.

• Execution log: instructions, versions, tools called, outputs, decisions.
• Data provenance: which sources were used, and when.
• Rollback capability: undo an action, restore a version, correct quickly.

A fourth object is systematically forgotten and costs the most when it is missing: versioning of the rules themselves. Knowing which version of rules and models produced which output is what makes it possible, after an incident, to tell a system error from an instruction change that was badly propagated. It is also what makes corrections durable: you correct the dated rule that produced the error, and not each output taken in isolation.

Observability: steering without a black box

An agent that executes must be observable like a production system: metrics, logs, traces, alerts. Three families of objects are enough to cover the essentials, provided they are instrumented from the first day in service and not after the first incident.

• Structured logs: input, plan, actions, results, timings, errors.
• Step-by-step traces: to reconstruct a multi-step decision.
• Quality monitoring: failure rate per tool, retry rate, human escalation.

What you watch, and at what threshold you cut

Logging is useless if nobody defines what triggers a reaction. Three thresholds are set when the system goes live, and are then revised on real data rather than on intuition. The first is an iteration ceiling: beyond a number of steps fixed for a given task, execution stops and is escalated, because an agent that loops almost never converges on its own. The second is a failure rate per tool: when a connector fails beyond its usual level, it is the tool to look at, not the model. The third is the escalation rate: if it rises, the rule is badly written or the scope is badly chosen; if it falls to zero, verification has probably stopped working.

These same counters serve to contain cost. The cost of an agentic system comes not only from the model, but also from the number of steps, the tool calls and the correction loops. The discipline that follows is constant: limit useless loops and measure every step.

Outputs that are plausible but false

This is the point that changes everything once an agent chains actions: a “plausible” output can trigger a real action and create a real problem. The risk is amplified by autonomy, particularly when the objective is badly worded — a system optimizes what it was asked to maximize, not what you wanted to obtain. And it cannot count on a vigilance that does not exist: 66% of users rely on AI outputs without checking their accuracy (Squid Impact, 2025). Verification cannot therefore be left to the recipient; it has to sit inside the system.

• Require sources when a factual claim puts credibility at stake.
• Cross-check when the information is time-bound or uncertain.
• Block publication if the agent cannot justify a critical point.

At scale, three practices make these rules sustainable: systematic checklists applied to every output, sampling that checks a percentage of outputs according to risk and impact, and test sets covering easy cases, edge cases, sensitive content, languages and multi-site setups. They are what allow you to correct the rule rather than the output, the only way not to redo the same check indefinitely.

FAQ on agentic AI

What is agentic AI?

It is an approach in which an AI system does not stop at analysing or generating: it decides and carries out actions to reach an objective, with limited supervision. It plans a sequence of steps, calls tools, acts in real systems, then verifies and corrects. The difference from a generative model is not power, it is the ability to act and everything that has to be put around it to keep it framed.

Agentic AI definition: which definition should a company use?

Use an operational definition: a system that pursues an objective by deciding for itself the sequence of its actions, with tools at its disposal. The explicit plan and self-verification are not part of that definition: they are architecture requirements, laid down because they make the system operable. Their absence does not give you something other than an agent — it gives you an agent it would be unwise to plug into your systems.

How does agentic artificial intelligence differ from chatbots and classic LLMs?

The difference lies in action. A chatbot or a generative model depends on a human prompt and can neither decide nor act on its own inside your systems. An agentic approach adds initiative and execution: it calls tools, writes, verifies and raises exceptions. It also adds an obligation the other does not have: traceability of every action.

Is ChatGPT an agentic AI?

In part, and less and less as an exception: agentic capabilities are built into the product itself — web search, code execution, connection to third-party applications, chaining several steps towards a given objective. So there is not necessarily an external architecture to build in order to obtain agent behaviour. What remains to be built, in a business, is the framework: what it is allowed to read, what it is allowed to write, which actions go through an approval, and how all of that is logged.

What are the key components of an agentic AI agent?

Five at a minimum: an orchestrator that sequences and applies the rules, callable tools, a memory that carries the durable context, permission and scope policies, and guardrails (tests, blocks, escalation). When an agentic project fails, it is almost always one of those five components that is missing — rarely the model.

How does the perception, planning, action, verification cycle work in agentic AI?

Perception: gathering signals, the state of the systems and the constraints. Planning: breaking the work into steps and choosing a path. Action: execution through tools, with traceable changes. Verification: checking compliance and consistency, then correcting or escalating. It is the fourth step that makes the difference: without it, errors add up from one step to the next.

What are the 3 types of AI?

Deterministic AI works through explicit rules: reliable and auditable, but rigid. Probabilistic AI generates and predicts statistically: flexible, but variable and with no guarantee of accuracy. Agentic AI orchestrates actions, often combining the two preceding types. The choice is made on the risk of the action: whatever has to be reproducible stays deterministic.

How do you ensure quality control and brand consistency with AI agents?

By turning your requirements into rules the system can be held to: explicit constraints, evidence requirements, checklists, and approval thresholds defined by risk level. Then add auditability: knowing why an output was produced and on which data. The improvement loop works on the dated rule that produced the error, not on each output taken in isolation.

How do you secure permission management and tool isolation for AI agents?

Apply least privilege, segment scopes by action and by environment, and separate the roles: proposal, execution, approval. Go through controlled functions rather than direct access, require human approval on risky actions, and log every tool call. Add secret rotation and immediate revocation in the event of an incident.

Continue reading

• Your rights matrix is in place: if the question becomes “how far does the agent decide alone”, the delegation levels and what is never delegated are what settle it → autonomous AI agents.
• You already have automated scenarios: if you have to decide which ones justify an agent and which do not need one, the boundary lies between classic automation, assisted automation and an agent → AI automation agent.
• The architecture is clear: if what you are missing is the order in which to build it and the acceptance criteria at each stage, the method is set out in create an AI agent.
• One agent is no longer enough: if several have to share an objective, the roles, the exchange protocols and conflict resolution belong to AI agent orchestration.
• Loss of context is your problem: if you want the document layer — indexing, retrieval, evaluation — it is covered in the RAG AI agent.

If the concrete task ahead of you is having content produced by a system framed by your own rules and your own approvals, that is the purpose of our personalized AI.