How an AI agent knows your business process: the six building blocks

Updated: July 2026

The question behind every agent deployment

When an organization hands a business process to an AI agentAI agentA system that perceives its environment, decides and takes actions toward a goal (calling tools, executing plans). Autonomy of action demands allowlists, approval gates, sandboxing, logging and a kill switch.Open full entry →, one question comes first: how does the agent know the process? A language model knows nothing about your organization on its own. It knows what an invoice is and what "approve" means, but not what your approval limit is, who holds signing authority, or which supplier is on the exception list.

Everything the agent knows about your process arrives through six building blocks, and each one is a design choice: what lives where, and how much the model itself decides. Those choices determine how well the agent runs the process. They also determine what the controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → environment around it has to look like, because where knowledge and decisions live decides where controls can live.

The architecture of an agent, in plain language

An AI agent is a small stack of parts working together.

At the center sits the language model, the "brain" that understands and produces text and makes the agent's choices. Around it sits ordinary, fixed software: the orchestrationorchestrationThe fixed program code around an AI model that determines which steps run in which order, what is mandatory, and where a human is involved. Because it is conventional software, it behaves predictably and can carry enforceable controls, which is why process structure belongs there rather than in prompt text. See enforcement point, guardrail.Open full entry →, program code that determines which steps run in which order and where a human must be involved. The agent acts on the world through tools: functions it can call to do or request something, a search function, a connection to the ERP system, a mail function. It gets its assignment through a system instruction, the fixed text it receives on every run describing its role and way of working. It looks things up through retrieved knowledge (RAGRAGRetrieval-augmented generation: grounding a generative model's answers in documents retrieved at query time. It gives currency and source-traceability without changing the model, at the price of governing the retrieval corpus.Open full entry →): for each task it first fetches the relevant documents, the correct procedure, the product terms, and reads them as context. And it can carry memory: information it retains about earlier steps or earlier runs.

Not every agent uses every part. An agent can run without retrieval, and many run without long-term memory. The practical difference with a conventional chatbot sits in the tools: a chatbot answers, an agent can act on that answer.

Two kinds of parts, and why the difference matters

Now that the parts have names, one line can be drawn through them, and it is the most consequential line in the whole design.

Deterministic parts are conventional software: the orchestration, the checks inside tools, and the access rights that bound what the agent can reach. Their rules are explicitly coded, so given the same relevant inputs, state, and configuration they apply those rules predictably and reproducibly. If the payment tool is configured to refuse amounts above 10,000 euros, it applies that limit today, tomorrow, and on the thousandth invoice.

Probabilistic parts are everything that passes through the language model: how it reads the instruction, what it does with the retrieved documents, which tool it decides to call. The model chooses the most likely continuation; it does not follow fixed rules. The same question asked twice can produce two slightly different answers.

Each building block below carries one of these two labels. The label decides what you can rely on, and how you can ever test it.

The labels describe behavior, not quality. A deterministic layer is not automatically safe: it still needs a correct design, coverage of every path that matters, secure configuration, and change managementchange managementControlled handling of updates to models, data and configurations: every material change re-passes validation before redeployment.Open full entry →. What the label buys you is that its rules can be enforced and tested as rules.

What changes when an agent takes over a process

An agent does not simply execute the process faster. It changes the riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → profile of the process, in four ways.

Scale and speed. A human makes one error at a time; an agent makes the same error a thousand times per hour. HarmharmThe concrete damage an AI system can do that a responsible-AI principle exists to prevent: in the EU AI Act's terms, harm to a person's health, safety, or fundamental rights. Harm is the bridge between an abstract principle and a governable risk; governance becomes operational the moment an organization names the specific harms it wants to prevent. For fairness, a harm is a group receiving systematically worse outcomes because of a characteristic that should not have counted. See principle, risk.Open full entry → estimates based on human pace no longer hold.

No natural hesitation. An employee who sees something strange stops and asks. An agent only does that if it is explicitly designed to. The unwritten safety net of common sense goes away with the person.

New attack surface. The process becomes manipulable through channels that did not exist before: hidden instructions in an incoming email, an attached PDF, a web page, or a polluted document in the knowledge base. The attack side is covered in the agentic threat surface article.

Correlated errors. Where ten employees make ten different errors, one agent makes the same error everywhere at once. Their errors no longer balance each other out.

This is why the design starts with the risk rather than with the existing procedure: the agent redraws the risk before a single control is written down.

The six building blocks: where process knowledge can live

The architecture above is the machine. This section walks through the same parts as the places where knowledge about your process lives. The number six is a completeness claim: if process knowledge lives anywhere in an agent, it lives in one of these six building blocks. The IMDA Model AI Governance Framework for Agentic AIIMDA Model AI Governance Framework for Agentic AIA governance framework for agentic AI published by Singapore's Infocomm Media Development Authority, first released in January 2026 and updated in June 2026. It decomposes agents into models, memory, tools, and actions, and states a preference for structural and rule-based controls over guardrails that live in the prompt layer. It is guidance, not law. See agentic AI, guardrail, least agency.Open full entry →, published by Singapore's Infocomm Media Development Authority, divides agents differently, into models, memory, tools, and actions, but it covers the same elements.

One layer is deliberately absent from the list. Permissions and policy rules, whether they are access rights, role-based authorization, or a policy enginepolicy engineA component that applies recorded rules automatically to every action, for example a requirement that payments above a threshold need separate approval. Because the rule sits outside the model, it cannot be ignored or reasoned around by the model. Recording those rules as machine-readable code, kept under version control like any other production code, is known as policy-as-code.Open full entry →, do not teach the agent anything about your process; they bound what it can reach and do regardless of what it knows. That makes them a control layer rather than a building block, and it is where much of the control environment ends up living.

1. The model itself (probabilistic)

The generic knowledge and reasoning ability acquired during training. In a standard deployment of a general-purpose model, nothing of yours belongs in it: you choose a model, you do not fill it. The model knows what an invoice is. It does not know that your organization never pays a supplier whose bank details changed last week. Fine-tuningfine-tuningFurther training of an existing model on your own data to adapt its behavior. This makes you responsible for the modification, potentially up to provider level.Open full entry → or further training on your own data is a separate design choice, and it changes that picture: organization-specific knowledge then lives inside the model, where it is considerably harder to inspect, correct, or remove than a document in a knowledge base.

• The risks: the model fills gaps in your instructions with plausible assumptions, so what you do not regulate explicitly, it invents plausibly. And the model is not a fixed given: the providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → can update or replace it, after which behavior shifts while all your own artifactsartifactThe concrete record that proves a control was carried out: a test report, an impact assessment, a monitoring log, a release sign-off. An artifact is the tangible form evidence takes, the thing an auditor reaches for to confirm that a control was not just designed but actually operated. Each stage of the AI life cycle produces its own anchor artifact. Distinct from evidence as a whole: evidence is the proof, an artifact is one piece of it. See evidence, life cycle.Open full entry → stay the same. Many organizations therefore pin a specific model version where the provider allows it, which turns a model change from an event into a decision.
• The design choice to record: which model, which version, whether that version is pinned, and what happens when the provider changes it.

2. The system instruction (probabilistic)

The fixed "job profile" that accompanies every run: role, goal, way of working, tone, what to do when in doubt. One line in it can decide the character of the whole process. An instruction that says "when in doubt about the supplier or the amount, stop and present the case to a human" produces an agent that escalates; without it, the same agent guesses.

• What belongs in it: the task at a high level, escalation rules, and references to where detailed knowledge lives.
• The risks: hard rules placed here are requests to a probabilistic systemprobabilistic systemA system whose outputs are statistical predictions with error rates: designed to be wrong some fraction of the time, which testing measures rather than eliminates.Open full entry →, not restrictions, so the model can weigh them incorrectly, lose them among competing instructions, or be manipulated out of them. And the instruction ages while the process changes, because the text often lives in a configuration file outside regular change management.
• The design choice to record: what the agent's job description says, which escalation rules it carries, and who maintains it under which change process.

3. Retrieved knowledge, RAG (probabilistic)

The agent fetches the relevant documents per task, procedures, work instructions, product terms, and uses them as context. The rule of thumb: the system instruction says how the agent works, retrieval supplies what it works with.

Technically, retrieval is simple: the text of the fetched documents is placed next to your instruction in the model's context window, and the model reads both the same way. That mechanism is also the vulnerability: hidden text in a document arrives exactly where instructions live.

• The risks: the agent fetches the wrong or an outdated document; the source is polluted or carries hidden instructions; and version driftdriftThe gradual divergence of an AI system's behavior or performance from its validated state after deployment, without any code change or error. Drift is silent by nature: nothing breaks, accuracy simply decays until someone measures it. Causes are worth separating: a shift in the mix of incoming cases, a change in the source material, a change in surrounding systems, or an update to the underlying model by its provider. See model drift, agent drift.Open full entry →, because if the procedure changes and the knowledge base does not, the agent demonstrably works on an old process version.
• The design choice to record: which sources feed the agent, and how they stay synchronized with the real process.

4. Tool definitions (deterministic, with one precision)

The list of functions the agent can call, each with a name, description, and parameters. The agent reads those descriptions to decide what it does, which makes tool definitions executable process architecture: they describe the process and bound it at the same time. process_invoice(amount, supplier, cost_center) already tells the agent a great deal about how your process works.

The precision that matters: the check inside a tool is deterministic and enforceable, but whether the tool is called, and with which values, is a model decision.

• The risks: overly broad tools such as run_query(sql) hand the agent effectively unlimited power in a system. The model can also invent, calling a tool that does not exist or filling parameters with plausible but wrong values, which is one more reason the validation inside the tool is not optional. And third-party tool definitions, often supplied through MCPMCPAn open standard for connecting AI applications to external tools and data sources in a uniform way. For governance it matters because a tool definition supplied through an MCP server is process knowledge the agent reads: whoever controls that definition influences the agent's behavior, which makes third-party tool sources a supply chain question. See agentic AI.Open full entry → servers (a standard way to connect an agent to external systems and data sources), form a supply chainsupply chainThe layered chain behind an AI product (foundation models, datasets, labeling services, integrators), each layer adding risk the buyer never contracted for directly.Open full entry → channel: whoever controls the tool description influences the behavior of your agent.
• The design choice to record: the exact toolset, what each tool refuses on its own, and which tools come from outside.

5. The orchestration (deterministic)

The fixed code around the model that enforces the process structure. This is where a process stays a process instead of becoming a conversation: first match, then approve; above a threshold a human reviews; stop after three failed attempts.

The orchestration is the only place where sequence and human involvement are guaranteed rather than requested. It can carry the mandatory order of steps, an approval moment before an impactful action, segregation of duties across steps, retry limits, stop conditions, and the escalation route. Each of those is either structure in code or a sentence in a prompt, and only one of the two holds every time.

• The risks: designers leave too much to the model, because building orchestration takes more work than adding a sentence to the prompt. Every process step that exists only in prompt text is a step that can be skipped.
• The design choice to record: which parts of the process are structure in code, which are left to the model, and where a human reviews, approves, or can stop the run.

6. Memory (probabilistic)

What the agent retains within a task (short term) or across tasks and runs (long term). Memory is useful and quietly dangerous: an outdated supplier exception stored in memory can shape every approval that follows, without anyone seeing where the influence came from.

Many enterprise workflow agents need short-term memory within a task and no long-term memory at all. In other settings, customer support, coaching, tutoring, or care, durable memory is the point of the agent. There it needs its own governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → rather than avoidance.

• The risks: memory poisoningmemory poisoningThe risk that polluted, outdated, or deliberately planted information retained by an AI agent carries into all later decisions. It is hard to trace afterward, because the influence is not visible in the individual case that goes wrong, which is why what an agent retains and for how long is a design decision rather than a technical detail. See agentic AI, drift.Open full entry →, where polluted, outdated, or maliciously placed information carries into all later decisions and is hard to trace afterward.
• The design choice to record: whether long-term memory exists at all, what is retained, for how long, and who can inspect and clear it.

The autonomy choice

The six blocks do not settle how much the model itself determines. That is a separate choice, and it is the largest one.

	Workflow agent	Planning agent
Steps	Fixed in code	The model decides
The model's job	Fill in content per step	Plan the work and choose the tools
Certainty comes from	The structure around the model	Conditions on each individual action
Autonomy	Lower	Higher
Governance effort	Lower	Higher

Between the two sits a spectrum, and the position on it decides where certainty can live. With a workflow agent, the orchestration carries the process structure. With a planning agent there is no fixed place anymore where "step 2 only after step 1" is technically enforceable, so certainty has to come from conditions attached to each individual action.

For most first deployments this is also a risk choice: a workflow agent is considerably easier to control and verify. Choose higher autonomy only where the task requires it, and treat that choice as an explicit, substantiated decision in the risk analysis rather than a technical default. This is what OWASPOWASPThe Open Worldwide Application Security Project, a nonprofit foundation that publishes open security guidance. Two of its outputs matter for AI governance: the OWASP Top 10 for LLM Applications, which lists prompt injection as its first entry, and the OWASP Top 10 for Agentic Applications, which covers the security risks specific to agents that use tools and act autonomously. See prompt injection, least agency, agentic AI.Open full entry →'s agentic security work calls least agencyleast agencyThe principle, used in OWASP's agentic security work, that an agent should be granted the smallest set of capabilities and the least autonomy the task requires. Applied at architecture level it is a risk decision rather than a technical preference: less autonomy leaves more of the process enforceable in code. See OWASP, agentic AI, enforcement point.Open full entry →, applied at the architecture level; IMDA's preference for structural controls over prompt-layer guardrailsguardrailA barrier meant to stop unwanted behavior of an AI system. The distinction that decides its value is where it lives: a guardrail written into the prompt is a request the model can weigh incorrectly or be manipulated out of, while a guardrail in code or configuration is an enforcement. The word is also used in the market for output filters, schema validation, classifiers, and policy engines, so the layer it sits in is worth naming. See enforcement point, policy engine, prompt injection.Open full entry → is the same instinct from the governance side.

Seven choices, one design

Read the blocks again and each one ends the same way, with something to record. Which model and version. What the job description says. Which sources feed the agent. Which tools exist and what they refuse. What is structure in code and what is left to the model. What is remembered. And above all of them: how autonomous the agent is allowed to be.

Each of those choices also needs a name behind it. The system instruction, the knowledge base, the toolset, and the orchestration are production artifacts, and an artifact without a named owner changes without anyone deciding that it should. Recording the choice and recording who owns it are one act.

Together the recorded choices are the architecture of your agent, seven decisions in total, and they are the input for everything that has to be governed around it, because each choice determines which risks exist and in which layer, deterministic or probabilistic, a matching control could ever live. Designing an agent is therefore less a matter of prompting a model than of deciding, deliberately, where process knowledge, decisions, and authority belong. Governance does not start when the first control is built; it starts here, with those choices on paper. Recording the architecture is not yet a risk assessment, but it is what makes one possible: it shows how the agent can fail, what harm follows, and which control objectivescontrol objectiveA statement of the outcome a control must achieve, such as "unauthorized payments must not be technically executable". It says what must be true rather than what must be built, which leaves room for more than one control activity to meet it. Keeping the objective separate from the activity is what keeps a control register testable. See control activity, enforcement point.Open full entry → the organization needs. Where those objectives are then enforced, and how you prove they work, deserves its own treatment: the control environment for agentic AI.