How to architect, govern and steer an agentic AI system that executes

This page is for executives and directors (marketing, operations, IT) who want to hand an AI system not just answers but actions inside their tools. It describes what agentic AI adds to a generative model, the principles and components of a reliable architecture, then the governance and observability needed to steer it.

It helps you decide what an agent executes alone, what goes through human validation and what triggers a stop, according to the four permission levels in our guide to AI agents.

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. “Agentic” therefore does not designate a family of more powerful models, but a layer added around the model, made up for the most part of things that are not AI: rights, connectors, blocking rules, logs. The best model does not, on its own, make an agentic system.

From the model that answers to the system that executes

In most organizations, three regimes coexist that must not be confused when the time comes to decide what to automate.

A chatbot or a “classic” model is excellent at answering and generating, but it depends on a human prompt at every turn and does not act inside your tools. The move into action changes the nature of the problem: the question is no longer the quality of the answer, but the reversibility of the action. The decision grid between executing and preparing is in our comparison of AI agent vs AI assistant.

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

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

• Autonomy: the agent runs steps without asking a human at every micro-decision.
• Accountability: the organization remains answerable for the actions (rights, validation, 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. The opposite is true: an agent only gains autonomy if its scope is bounded, because that bounding is what makes the autonomy bearable for the organization. On the meaning of the term and the notion of agency, see our article on the agentic AI definition.

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 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, nothing stops a mistake before it feeds the next step. Verification is what 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. Four architecture principles make that sequence reliable: an explicit objective, multi-step planning, tool calling, self-verification. These are design recommendations, not a membership test: as our guide to AI agents points out, a system that applies only two of them is still an agent, simply less safe to operate.

Each principle can be instrumented and exposes you to a nameable risk when it is missing. This grid goes on the table before any discussion of the model and serves as a diagnostic: a disappointing agent rarely fails on all four principles, but on a single one, almost always the last, the one that costs the most to put in place and 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 the cascade effect, the failure mode specific to agentic systems.

A second mechanism appears when several teams or agents share instructions: semantic misalignment, where the same rule, read differently depending on the entry point, produces divergent outputs without any step failing.

The ground gives the measure: 56% of users say they have made mistakes because of AI (Squid Impact, 2025), with no automatic execution. When the output triggers an action, the same proportion becomes an incident load; further benchmarks appear in our AI statistics. 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

A robust agentic architecture does not come down to “an LLM and 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, validation 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, especially when actions follow one another. The agent itself, its criteria and its families, is covered 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. 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 in it.

• The initial objective and its limits.
• The decisions already taken, with their rationale.
• The sources already consulted, with their date.

Document retrieval completes this set-up: rather than loading everything into the context, the system fetches the information when it needs it and, in an agentic configuration, formulates its own further searches. It settles freshness and coverage, not consistency: two successive retrievals can still contradict each other if nothing arbitrates between them.

Specializing by role rather than stacking capabilities

A complex objective is better shared between several specialized agents than handed to a single agent overloaded with capabilities. Specialization is first and foremost a division of responsibility; 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 them in production is a separate piece of work.

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

As soon as an agent reaches systems, even read-only, security becomes a design subject, because two risks do not depend on the right to write. Prompt injection: an instruction hidden in a document, a web page or a ticket diverts the agent from its objective. Exfiltration: 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 leak what it consults.

An executive who discovers after the fact that a system has published, deleted or committed something with no trace will cut off access. Governance is 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 says what the agent does alone, what is checked by sampling and what does not go out without human agreement. Read it alongside the four permission levels of an AI agent set out in the pillar: low and medium risk fall under controlled writing (level 2), high risk under levels 3 and 4.

Human supervision must not be everywhere, or you lose the effect of scale. It belongs where the risk is real.

• High-traffic pages and offer pages.
• Regulated sectors.
• Claims with figures and sensitive comparisons.

The opposite excess also has a cost in trust, excessive automation being among the concerns expressed about AI. A well-built chain does not confuse automation with absence of governance: the human stays in the loop, 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, can you answer three questions?

• Which rule authorized the action?
• Which data motivated it?
• How do you undo it?

Three objects answer these questions.

• 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, often forgotten, costs the most when it is missing: versioning of the rules. Knowing which version of rules and models produced which output lets you tell a system error from a badly propagated instruction change, and correct the dated rule rather than each output.

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, provided they are instrumented from go-live, 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. Thresholds are set at go-live and revised on real data, not on intuition. Three need setting first.

These counters also serve to contain cost, which depends on the number of steps, the tool calls and the correction loops: limit useless loops and measure every step.

Outputs that are plausible but false

A “plausible” output can trigger a real action and create a real problem: that is what changes once an agent chains actions. The risk is amplified when the objective is badly worded, because a system optimizes what it was asked to maximize, not what you wanted to obtain.

Nor can it count on a vigilance that does not exist: 66% of users rely on AI outputs without checking their accuracy (Squid Impact, 2025). Verification therefore has to sit inside the system, not with the recipient.

• 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 and let you correct the rule rather than the output.

• Systematic checklists applied to every output.
• Sampling that checks a percentage of outputs according to risk and impact.
• Test sets covering easy cases, edge cases, sensitive content, languages and multi-site setups.

Continue reading

Depending on where you are, the next article is not the same.

• 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, in autonomous AI agents.
• You already have automated scenarios: to decide which ones justify an agent and which do not need one, the boundary between classic automation, assisted automation and an agent is set out in 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 task ahead of you is having content produced by a system framed by your rules and your approvals, that is the purpose of our personalized AI.

FAQ on agentic AI

What is agentic AI?

Agentic AI is an approach in which an AI system does not stop at analysing or generating, but decides and carries out actions to reach an objective, with limited supervision. It plans, calls tools, acts in real systems, then verifies and corrects. The difference from a generative model lies in the ability to act and the framework that ability requires.

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, and with them a new obligation: traceability of every action.

Is ChatGPT an agentic AI?

Partly: at the time of writing, agentic capabilities are built into the product itself (web search, code execution, third-party applications, chaining of steps), with no external architecture to build. What remains to be built in a business is the framework: read and write rights, actions subject to validation, logging.

What are the key components of an agentic AI agent?

An agentic AI agent rests on at least five components: 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 a project fails, one of the five is missing, rarely the model.

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

The cycle chains four stages in each loop: perception gathers signals and constraints; planning breaks the work into steps; action executes through tools, traceably; verification checks compliance and consistency, then corrects or escalates. Without verification, errors add up from one step to the next.

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

Quality control relies on rules the system can be held to: explicit constraints, required evidence, checklists and validation thresholds by risk level. 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.

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

Security rests on least privilege, scopes segmented by action and by environment, and roles separated between proposal, execution and validation. Go through controlled functions rather than direct access, require human approval on risky actions and log every tool call, with secret rotation and revocation.