Glossary · Chapter 03

Agentic AI

A chatbot answers questions. An agent owns an outcome: “process this invoice”, “resolve this ticket”, “assess this tender”. To do that, it combines the language understanding of an LLM with tools that act inside real systems — and with a loop of perceiving, reasoning, planning, acting and verifying. This capacity to act is exactly what makes agents valuable and risky at once. That is why every term in this chapter has two sides: what the agent can do — and what keeps it in check.

03.01AI agent

A system that is given a goal instead of a sequence of steps. The agent perceives its environment (documents, tickets, system states), reasons, plans steps, executes them through tools and verifies its own result — in a loop, until the goal is reached or a rule makes it stop. The difference from an RPA bot is fundamental: the bot replays a script; the agent writes its own for every case — within the limits it has been given.

Fig. — The agent loop, enclosed by the governance ring.

Example“Process the incoming supplier invoice”: the agent notices the PO number is missing, looks it up in the ERP via the supplier number, finds two candidates, picks the right one based on amount and date — and documents that decision in the audit log before proposing the posting.

03.02Agent vs. chatbot vs. copilot

Three levels of independence. The chatbot answers when asked — it does not act. The copilot assists a person who performs every action themselves. The agent executes on its own and reports back when it is done or stuck. The dividing line is the question: who presses “execute”? The moment the system does it itself, it needs an identity, limits and a record — then it is an agent, and should be treated as one.

Fig. — Script versus goal: where the bot stops, the agent escalates in a controlled way.

03.03Tools & function calling

Tool layer · MCP

The agent's hands. An LLM on its own can only produce text — tools give it defined capabilities: create an SAP posting, start a UiPath robot, query a database, send an e-mail. With function calling, each tool is described to the model with a name, purpose and parameters; the model decides when to call which one with which values. Standards like the Model Context Protocol (MCP) unify how systems offer their tools to agents. The tool layer is also the most important control surface: what does not exist as a tool, the agent cannot do.

03.04Human-in-the-loop (HITL)

The principle that makes autonomy enterprise-ready: at defined points, the agent hands over to a human — for amounts above a threshold, for low confidence, for anything policy marks as critical. Done well, this does not mean “a person looks at everything”, but: exceptions land in a queue with an SLA, carrying the case, the agent's reasoning and its proposal. The human decides the 5% that need judgement — instead of retyping the 95% that do not.

03.05Guardrails & policy

The rails within which an agent may act — as code, not as a statement of intent: posting limits, forbidden actions, approval requirements, data classes it must not touch. The crucial point is where the rules are enforced: not in the prompt (which a model can misread), but in the tool layer and platform, where they cannot technically be bypassed. They are changed like software — via review and pull request, with version history.

ExampleThe AP agent's policy: postings up to €10,000 autonomous, four-eyes approval above; bank-data changes never autonomous; access to AP transactions only. The agent cannot talk its way past these limits — the tool layer refuses.

03.06Agent identity

When software acts on its own, it must be traceable who acted. So every agent gets its own first-class identity in the company's identity system (Okta, Entra ID) — never a shared service account. This comes with tightly scoped permissions and short-lived tokens (minutes, not months): compromised credentials expire on their own, and access reviews and revocation work exactly as they do for human employees. Agent identity is where AI operations and the security organisation meet.

03.07Audit trail

The complete record of an agent's actions: every perception, every decision with its reasoning, every tool call, every result — stored immutably and ideally hash-chained, so that after-the-fact tampering shows. The audit trail answers the question internal audit, the regulator and your own board will ask: why did the system do that? It is also the best tool for your own root-cause analysis — every case can be replayed step by step.

03.08Multi-agent systems

Orchestration · agent teams

Complex outcomes rarely come from a single agent. In multi-agent systems, an orchestrating agent decomposes the task and delegates to specialists — one extracts, one validates, one posts, one writes the reply. This raises quality and traceability (each specialist can be tested in isolation), but it also multiplies the governance questions: every agent needs an identity, a scope and a record, and the handovers between them belong in the audit trail just as much as the actions themselves.

03.09Levels of autonomy (L0–L4)

A staircase, not a threshold: L0 manual work · L1 scripted automation (RPA) · L2 intelligent automation (ML inside the flow) · L3 assisted agents (the agent proposes, a human confirms every action) · L4 governed autonomy (the agent acts within limits, humans supervise by exception). Moving up is not a technology exercise but a trust-building one: a process climbs one level exactly when evals, the audit trail and exception rates justify it — not sooner.