Structure at the edges, freedom in the middle

Follow-along demos: one concierge, several platforms

n8n

The fastest route to a working concierge

AI Agent node, skills as sub-workflows, Guardrails, send-and-wait approval, Evaluations.

Open demo

LangGraph

The engineer's version

Typed state graph, agent middleware for authorisation and approval, interrupts resumed in Studio, LangSmith evaluation.

Open demo

More platforms

Other leading automation platforms

The same concierge, the same design and the same twelve test conversations on more platforms.

Coming soon

Introduction

Who meets you at the door?

Walk into a good bank branch and somebody does. They ask what you need, answer straightforward questions and point you to the right desk for the harder ones. If the job is small, such as printing a statement or updating a phone number, they simply do it. You never join the queue for a teller or mortgage adviser. Nobody would call that person a chatbot. They are a processing officer with excellent manners.

So why do so many enterprise AI assistants still stop at the greeting?

This article is for architects, business analysts, process owners and engineers across European organisations who are being asked to put an agent inside a real process. The bank branch is the worked example, not the boundary of the argument. Its handovers are visible and its work ranges from routine administration to significant decisions. The same design problem appears in healthcare, employment, education, insurance, utilities, public services and many other sectors.

At heart this is a technical comparison of one service agent built on several platforms. The branch concierge acts on a person's behalf inside the bank, and I am building it in n8n and LangGraph first, with more leading automation platforms to follow, because each tool draws the line between workflow and agent in a different place. The n8n and LangGraph builds are finished. Their follow-along demos are linked above and their files are in the companion repository. More platforms are still to come, so treat the comparison here as the design argument with two builds behind it.

It also takes enterprise hesitation seriously. McKinsey's 2026 State of AI survey found that nearly nine in ten organisations use AI somewhere and 47 per cent are scaling chatbots across the enterprise, yet only about two in ten are scaling AI agents. My working hypothesis, and it is an inference rather than a survey finding, is that this gap is more than the normal lag of a new technology. Organisations are comfortable letting AI talk, but far less comfortable letting it act. The survey hints at what unlocks adoption: its small group of high performers is much more likely to redesign workflows around AI and actively manage AI risk. That is the process-orchestration thesis of this article in survey form.

So the article takes each enterprise objection and names the control that answers it. Accountability gets a process orchestration wrapper. Explainability gets lineage and observability. Containment gets guardrails and risk-rated skills. Consequential decisions stay behind the automated decision-making (ADM) line that law and policy have already drawn. Each build then has to show whether those controls hold when the agent is actually running.

Three concepts carry the argument, so here they are briefly.

01

Workflow versus agent

A workflow runs the model along paths drawn in advance: classify, look up, draft, check. An agentic loop gives the model more control. It reasons about the goal, acts through a tool, observes the result and chooses its next step until the person has what they came for. That freedom is the point, and it is exactly what an enterprise is right to question.

02

The objections, and the law behind them

A model cannot own an outcome, answer a regulator or exercise professional judgement. Across the EU, GDPR applies to solely automated decisions with legal or similarly significant effects. The AI Act adds human oversight and logging duties for high-risk uses, and in defined cases a right to an explanation, while sector rules sharpen the obligation for a hospital, employer, university, public body, insurer or bank. The practical question is not simply whether a process contains AI. It is where the consequential decision is made, what the agent may do around it and who can intervene.

03

The prescribed elements

A well-built agent is not a free-for-all. Around it sits a deterministic process that owns every human task and the ADM line. Inside it sit governed skills, such as print a statement, that the agent may call but not modify. The agent's freedom lives between the two.

Scroll through the three concepts

My working answer is the headline: structure at the edges, freedom in the middle. I call the result Enterprise Agency: agentic AI an enterprise can stand behind, because it is free to act and still accountable for what it does.

What the "branch concierge" actually does

Strip the role back and it is four jobs:

• Meet and understand. Greet the customer and work out what they actually need, which is often not what they first ask for.
• Answer. Deal with the questions that have a known answer: opening hours, what documents to bring, where a payment has got to.
• Do it yourself. Handle the small, safe tasks on the spot: print a statement, update a phone number, book an appointment.
• Hand over well. For anything that needs a specialist, such as a teller, mortgage adviser or complaints handler, take the customer there with the context already gathered, so they do not start from scratch.

The result is warm, personal and above all fast: people are served more quickly and with less confusion, and specialists see only the cases that need them. That is the bar for the digital version too.

A sandwich, not a dial

LangChain's LangGraph documentation, building on Anthropic's guide to effective agents, places the main patterns in three columns. On the left, the model sits inside predefined paths such as prompt chaining and parallelisation. In the middle, it directs control flow through predefined paths using routing, orchestrator-workers and evaluator-optimiser loops. On the right, the agent chooses its own actions in response to the environment.

I group the picture slightly differently. The left column is workflows and the right is agents, but the middle is not a halfway house. It belongs to both. Routing, orchestration and evaluation make workflows smarter and help keep agents honest. That shared middle is where the interesting design lives.

The pattern names in that picture are Anthropic's, and every tool in this series implements them under its own labels. They are collected here for reference, each with its concierge example, so the rest of the article can use the names without stopping to define them.

Enterprise Agency: Anthropic's agent loop and five workflow patterns, applied to the concierge

The whole pattern

Enterprise Agency

Agents and workflows, governed by the process around them. Both are built from Anthropic's augmented LLM: a model with retrieval, tools and memory attached.

=

Agents

The agent loop. The model acts, observes the result and decides its next move, with tools as its hands. Concierge: the open-ended "meet and understand" conversation.

+

Workflows

1. 1

   Prompt chaining. Sequential model calls with a programmatic check between steps. Concierge: understand the request, draft the reply, check it for tone and compliance.

2. 2

   Routing. Classify the input and send it down a specialised path. Concierge: is this a question, a self-service task or a handover, and to whom?

3. 3

   Parallelisation. Independent sub-tasks run at once, or the same task run several times and voted on. Concierge: check identity and fetch account context at the same time.

4. 4

   Orchestrator-workers. A central model breaks a task into sub-tasks it could not predict in advance, delegates them and synthesises the results. Concierge: a customer with three things to sort in one visit.

5. 5

   Evaluator-optimiser. One model generates, another evaluates, and they loop until the output passes. Concierge: every customer-facing message checked against the bank's tone and the regulator's rules before it is sent.

The shape I think works is a sandwich, not a dial. On the outside sits deterministic process orchestration, owning every human task and the line where automated decision-making stops. That is where accountability lives, with a named decision owner and an audit trail. On the inside sit governed skills: bounded capabilities with defined inputs, outputs and risk ratings that the agent can call but not rewrite. Between them, the agent has real leeway to reason, choose, loop and adapt until the goal is reached.

The freedom in the middle is controllable because it is bounded on both sides, provided those bounds are enforced and tested. The agent can adapt its steps freely, because anything it changes goes through a skill, anything it reaches directly is read-only and all of it runs inside a process that has already decided what it is allowed to decide.

Two gates guard different risks. Pre-action authorisation checks every proposed skill or tool call against its risk rating, relevant flags and the session's permissions before it runs. Anything high-risk, unknown or unauthorised stops there, and the refusal goes back to the agent as a result to reason about. The impact and policy gate then decides whether a result or communication needs a person before it reaches the individual. The first stops actions. The second stops outcomes. Both fail safe, so a missing or unrecognised classification is refused or routed to review, never waved through.

The design also has to get better over time without the agent teaching itself. Every run leaves a trace: the tools it chose, the sequences of steps that worked, the questions its knowledge could not answer. A learning loop on the outer band reads those traces, and a person reviews what should change. Any change is run against the evaluation set and only then promoted. A route that keeps working becomes a known path or a new skill, a gap becomes approved knowledge and a confusing tool gets a better description. The freedom in the middle finds the improvements. The structure at the edges decides which ones become permanent.

A run-through of the diagram's elements

• Process orchestration. The outer band. A deterministic, modelled process, BPMN or its equivalent, that owns identity checks, every human task, the impact and policy gate, the learning loop and the record of what happened. This is where human accountability, the ADM line and process lineage live.
• The agent. The middle band. The model plus its loop, its memory for the session and its routes: known paths to skills and dynamic step discovery across tools and knowledge, free to choose its next step until the goal is reached or a runtime limit stops it. Its freedom is real but bounded on every side.
• The agent loop: reason, act, observe (RAO). The three circles, and the pattern every agent framework implements under its own name. It descends from ReAct, the reason-and-act prompting method from Yao and colleagues in 2022, which showed that interleaving reasoning with tool calls beats doing either alone. Reason: the model reads the goal, the conversation so far and what earlier steps returned, and decides what to do next. Act: it proposes a call to a skill or a tool, which runs only if authorised. Observe: it reads what came back and folds it into the next round of reasoning. The loop runs until the model judges the goal met, the customer is handed over or a set limit on iterations, time or cost stops it. Every turn is traced, which is what the outer band's lineage is built from.
• Skills. The inner core. Bounded, business-meaningful units such as print a statement or book an appointment, each with a typed input, a typed output and a risk rating, built from one or more tools plus the rules around them. Governed does not have to mean deterministic: a skill may use a model inside, but its inputs, outputs, risk rating and owner are fixed. The agent can call a skill but cannot modify it. Skills change only through the reviewed learning loop and change management. Anything that changes data goes through a skill. The skill is what you test and audit as a unit, because it is what the business recognises.
• Tools. A single action the model can call: a name, a description and a typed input, such as get_balance. The platform runs it and returns the result. In this design the tools the agent reaches directly are read-only. Writes happen only inside skills.
• MCP. The Model Context Protocol, the open standard for how tools are plugged in. An MCP server publishes its tools and data, and any MCP-aware client can discover and call them. The connection, the schemas and the authentication stop being bespoke. MCP is how the hands are wired, not what the agent is allowed to do with them.
• Knowledge. What the agent can consult rather than do: fees and product terms, branch policies and FAQs. Reached through RAG, retrieval-augmented generation, which fetches the relevant passage and places it in the prompt at the moment it is needed. RAG is to knowledge what MCP is to tools: how it gets in, not what the agent may do with it.
• The two gates. Pre-action authorisation, the "Authorised?" badge on act, checks every proposed call before it runs. An authorised call goes ahead. A refused one comes back to the agent as a result to observe and reason about again. The impact and policy gate, the ADM? diamond on the outer band, checks the output before it becomes an outcome. Both are deterministic rules reading structured facts: the risk rating of what is proposed or what ran, flags on the customer record and the category of request. Both fail safe when the facts are missing or unrecognised: the call is refused or the output goes to review. The process makes these calls, never the agent.
• Human decision. The named decision owner, with the competence, context and authority to change the outcome. They see the case the agent prepared and make an independent judgement. That is what makes the review meaningful rather than a rubber stamp. Which cases require it depends on the law, sector rules and the organisation's own policy.
• Learning loop. The box below the gate. Traces from every run feed it: step sequences that worked, tool errors and knowledge gaps. Nothing flows back automatically. A person reviews each proposed change, which must pass the evaluation set before it is promoted into skills, tools or knowledge, versioned so it can be rolled back. Agent memory is session-scoped, and nothing the agent does at runtime changes its own skills, tools or knowledge.

Where automated decision-making has to stop

The branch concierge makes the boundary visible, but it does not define the audience. Replace the bank with an employer, hospital, university, insurer, utility or public body and the same question remains: what can the agent do around a decision, and where must automated action stop?

Start with the effect on the person, not the industry. Routine answers, retrieval and reversible administration may be suitable for straight-through handling. A decision about employment, education, healthcare, credit, insurance or access to an essential service may affect somebody's rights, opportunities or livelihood. Those are different categories of work even when they sit in the same process and use the same model.

Data protection law applies across sectors. The EU GDPR uses the term automated decision-making. Article 22 gives people the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects, with exceptions for contract necessity, explicit consent or a basis in law. Where an exception applies, safeguards include human intervention, the right to express a view and the right to contest the decision. The trigger is the nature and effect of the decision, not whether the organisation calls itself regulated or the software is described as an agent.

The EU AI Act looks at the use case. It is cross-industry and risk-based. Annex III lists high-risk uses that include recruitment and promotion, admission to education, creditworthiness, pricing of life and health insurance, access to essential public services and benefits, migration and justice. A high-risk system must be designed for effective human oversight and logging, and the organisation deploying it must assign oversight to competent people. Prohibited practices have applied since February 2025 and general-purpose model rules since August 2025. The high-risk obligations were due in August 2026. Under the Digital Omnibus they now apply from December 2027 for the standalone Annex III uses, and from August 2028 for high-risk AI embedded in products already covered by EU product-safety law. Whatever the final dates, the design direction is already clear.

The practical design test is therefore portable: identify the decisions that affect an individual, classify their impact, decide what automation is permitted and put a named decision owner outside the agent wherever meaningful human judgement is required.

Beyond the EU: the UK, the United States and international standards

The EU AI Act can also reach organisations outside the EU when a system is placed on the EU market or its output is used in the EU. A supplier does not escape the question simply because its headquarters or model provider sits elsewhere.

The UK has its own domestic approach. The Data (Use and Access) Act 2025 replaced Article 22 of UK GDPR with Articles 22A to 22D, in force since 5 February 2026. The regime is more permissive for significant decisions that do not involve special category data, but still requires safeguards including notice, representations, the right to obtain human intervention and a route to contest the outcome.

In the United States, Colorado's automated decision-making technology law applies from 1 January 2027 to consequential decisions in areas including education, employment, housing, lending, insurance, healthcare and public benefits. Where legislation is less developed, ISO/IEC 42001 and the NIST AI Risk Management Framework are reinforcing the same practical expectations: intervention, explanation, evidence and accountability.

How sector rules sharpen the boundary: banking as the worked example

The branch concierge sits in banking, where sector rules add another layer to the cross-industry position. In the EU, the Capital Requirements Directive and the EBA's internal governance guidelines make the management body responsible for the risk framework. The EBA's loan origination guidelines require firms using automated or machine-learning models in creditworthiness assessment to understand, monitor and explain them. DORA adds accountability for ICT and third-party risk, including reliance on model providers. The AI Act then places creditworthiness assessment among its high-risk uses.

The UK reaches a similar design outcome through existing financial regulation. The Consumer Duty and the Senior Managers and Certification Regime attach responsibility to the firm and named senior managers. The FCA's position is that using AI does not move that responsibility to the system or its supplier.

This is one sector example, not the general rule. A healthcare regulator, employment authority, exam body or public-sector governance framework will sharpen the boundary differently. The reusable principle is that the agent cannot inherit the legal or professional accountability held by the organisation and its decision-makers.

In any sector, two roles may sit behind the boundary. The operational decision owner reviews the case and has the competence, context and authority to change the outcome. The accountable owner is responsible for the activity and its control framework. The first performs the review. The second is why the review and its evidence exist.

For the concierge, that gives a deliberately cautious rule. Lending, complaint outcomes, account closure and vulnerability judgements are not the agent's to make. In another setting the list might contain a diagnosis, recruitment decision, grade, insurance price or benefits award. The agent may gather evidence, complete routine work and carry context forward, but the consequential judgement stays with the appropriate process and person.

A useful way to enforce that in any build, borrowed from OpenAI's practical guide to building agents, is to risk-rate what the agent can call. Individual tools and business-level skills are both assessed. Read-only and reversible actions may be low risk, unless the data is sensitive or disclosure itself could cause harm. Writing personal data may be medium risk. Anything with significant consequences or elevated permissions is high risk and requires a person before it runs. A skill inherits at least the highest rating of the tools and data it uses. The rating becomes part of the executable boundary rather than a statement left in a policy document.

Why the gate cannot live inside the agent

A tempting shortcut is to tell the agent, in its system prompt, to escalate anything that looks like a significant decision. Every framework makes that easy, but it puts the check in the wrong place. On the diagram, the impact and policy gate sits outside the agent in the deterministic process. Five arguments support that choice.

01

The law asks for intervention, not self-restraint

GDPR Article 22 gives a person the right to obtain human intervention from the controller. Regulatory guidance says that involvement must be meaningful, carried out by somebody with the authority and competence to change the decision. For high-risk uses, the EU AI Act says overseers must be able to disregard, override or reverse an output and interrupt the system. Those actions are performed on the system from outside. A system cannot intervene in itself or act as the person who overrides it.

GDPR Art. 22(3)AI Act Art. 14(4)WP251

02

A control must be independent

A protection layer is only worth counting if it does not share a failure mode with the thing it controls. An LLM is probabilistic and open to prompt injection. An instruction hidden in a message or retrieved document can alter what the agent believes its rules are. If the escalation rule lives in the prompt, the attacker can reach it. A deterministic gate reading structured facts gives the same answer for the same facts and sits beyond the model's reach.

IEC 61508 / 61511NIST AI RMFOWASP LLM01

03

Models rate their own work too kindly

Asking the agent whether its own proposal needs review is asking it to grade itself. Research on LLM evaluators finds that models recognise and favour their own output. A model that has just reasoned its way to a conclusion is not a neutral judge of whether that conclusion is safe. The check needs a different mechanism, not a second opinion from the same model.

Panickssery et al. 2024

04

Keep maker and checker separate

The party that initiates an action should not be the only party approving it. Finance calls this maker-checker or the four-eyes principle, but the control appears across safety, quality, security and public administration. The agent is the maker. If it also decides what gets checked, it becomes the checker too. The gate restores the separation by deciding what needs a second pair of eyes before a named person provides them.

COSOBasel operational risk principles

05

Nothing audits itself

Governance separates doing, challenging and assuring. The agent is a system operated by the first line, while the gate and decision owner are controls the agent cannot switch off. Risk and compliance monitor and challenge those controls. Internal audit needs a record it can rely on: complete, tamper-evident and access-controlled, which is what the process lineage on the outer band provides. At every layer, the thing being checked is not the thing doing the checking.

IIA Three Lines

Scroll through the five reasons

A deterministic gate is only as trustworthy as the facts it reads, so each fact needs a source the model cannot write to. In the n8n and LangGraph builds, identity and the complaint and vulnerability flags come from the customer record found at identification. The risk rating comes from each skill's result in n8n and from the tool registry in LangGraph. Policy keywords are matched against the customer's own messages, and the rules live in the gate itself. The model is never asked whether its reply needs review. n8n checks only that the reply is not empty, and LangGraph also applies a fixed rule that sends a reply claiming an outcome, such as an account closed, to a person.

Put together, the principle is short. The agent may be as clever as you like about what to do. It must never be the judge of whether it was allowed to.

The pillars of a safe agent

These pillars are the target design. The n8n and LangGraph builds tested some of them, and their follow-along pages have the evidence.

Identity and authorisation first

No service data about a person is retrieved beyond what is needed to identify them and establish the session's permissions. Every call the agent proposes is then authorised against those permissions before it runs.

Guardrails, in and out

Input checks for relevance, jailbreak attempts and personal data. Output checks for tone, accuracy and rules compliance. Layered, because no single check is enough.

Controlled access to tools and skills

An explicit, allow-listed toolbox, every tool and every skill risk-rated, each skill a bounded sub-process the agent can call but not rewrite. Direct tool access is read-only. Writes go through skills. The agent's reach is the toolbox, nothing more.

State and memory

What the agent knows about the person and the interaction, held deliberately and on an appropriate legal basis. Memory is kept separate for each session and customer, and how long anything is retained is set by a retention policy, not by the session ending. The agent never modifies its own knowledge or skills.

Meaningful human decision

Two triggers, both fired by the process rather than the agent: the agent has failed to understand after a set number of attempts, or a gate has found a high-risk action or consequential decision. The person receives the context, time and authority needed to reach an independent outcome.

Safe failure

Idempotent skills and a compensation step for the ones that can half-complete. A fixed fallback when the model, a tool or the human queue is unavailable. A stated review capacity and response time, so a pause is never indefinite.

Observability, with privacy built in

Every step traced: what went in, what came out, which tool ran, what it cost in tokens. For audit as well as debugging. Agent traces can contain personal, financial, health, employment or other sensitive data, so the trace is minimised, redacted, access-controlled and retained to a schedule.

Evaluation and outcome monitoring

A test set of realistic conversations, run on every change so the agent cannot quietly get worse. Beyond route-based regression, live outcomes are monitored for fairness across the groups of people the agent serves. The test set grows from reviewed traces, while a fixed baseline catches drift that builds up across many small changes.

Learning loop, reviewed

Traces show where the agent could do better: step sequences that keep working, tools it misuses and questions its knowledge cannot answer. Each becomes a proposal, reviewed by a person and run against the evaluation set before it is promoted into knowledge, a tool, a known path or a skill. The agent never promotes its own changes, and the gate rules and the ADM line are never changed through the loop.

Change management

Every change to what the agent knows or does is a controlled change: a new model or provider, promoted knowledge, a tool, a known path or a skill. Each is versioned so it can be rolled back, approved by someone other than whoever proposed it and run against the evaluation set, with the level of approval set by risk.

Tools, MCP and skills are easy to confuse. The run-through of the diagram's elements, in the sandwich section, keeps them apart: tools are the agent's hands, MCP is how the hands are wired and skills are what the agent is actually allowed to do with them.

One concierge, several builds

The tools agree on the pillars but differ in which layer they make easiest. n8n and LangGraph both begin with the agent in the middle; later builds will include platforms that begin with the outer process. Each can express skills, which is what makes building the same concierge in each a fair comparison. The n8n and LangGraph follow-along pages are linked at the top of this article.

n8n

The fastest route to a working concierge

The AI Agent node runs the loop, with tools attached as sub-workflows, which is how you make a skill bounded. The Guardrails node sits in front of the agent and behind it, checking for jailbreak attempts, off-topic requests and personal data, and can sanitise text on the way through. Memory is a node you attach and scope. Human approval is a send-and-wait step in Slack or email. The execution log records every step and every token, and Evaluations let you run a fixed test set against the workflow before you change it.

LangGraph

The engineer's version, with LangChain underneath

The concierge is a typed state graph, with a LangChain agent as one of its nodes. Tools come from an explicit registry, each carrying its risk rating, and agent middleware checks every proposed call before it runs and pauses the risky ones for approval. The gate is a plain function feeding a conditional edge. The human line is an interrupt: when the gate flags a case for review, the graph stops, saves its state through a checkpointer and waits for a person to resume it with their decision. LangSmith adds masked tracing, evaluation experiments, prompt environments and a review queue.

What we will focus on and score

Every build is judged against the same scenario and the same twelve test conversations, so they can be compared on the same terms. In the scenario, a customer requests a statement for a rental application, mentions that they are considering a mortgage and asks about a complaint opened the previous month. The test conversations cover each of those moments, plus the actions, handovers and attacks around them. That creates three levels of agency: self-service for the statement, a handover with context for the mortgage enquiry and no automated decision on the complaint.

Each build is judged on the same six questions. Their answers roll up into the five business concerns in the table below, which shows the n8n and LangGraph builds' scores for each. Scores for further platforms will be added as each build is finished.

1. How the agent chose skills. Which skill it called for the statement and the mortgage handover, and whether it tried to reach for anything it should not.

2. Where execution stopped. Whether the impact and policy gate fired on the open complaint, and whether the process rather than the agent made that call.

3. How human review worked. What the decision owner saw, how long the pause took and whether they could change the outcome.

4. What evidence remained. The trace, the tool calls, the token counts and the gate decision, and whether a reviewer could reconstruct the visit from them.

5. What was easy and what was hard. Which layer of the sandwich the tool made natural, and which it made you fight for.

6. What failed in testing. The jailbreak line, the off-topic request and the cases where the agent reasoned its way somewhere it should not have gone.

Each demo page records the evidence from its build. The scorecard here stays with the business concerns and the answers the sandwich gives them.

Conclusion

The branch concierge is a useful test because it is neither a chatbot nor a back-office batch job. In production it would talk to real people, act inside real systems and meet work ranging from routine administration to consequential decisions. Banking supplies the scenario, but the design applies to any European organisation putting an agent between a person and a service.

Building the concierge on several platforms will test that claim. Each tool favours a different layer: n8n and LangGraph the agent in the middle, and later builds will include platforms that favour the outer process. The n8n and LangGraph builds are finished and run on demo customer records, not a live bank. In both, routine requests went straight through and the higher-impact ones paused for a person. The n8n evaluation set caught memory configuration faults that a smooth demonstration would have hidden. The LangGraph build ran a first reviewed learning loop: a proposed prompt change was staged, evaluated and rolled back, and a human review corrected a test.

A later code review of both builds found boundaries that held for one message but not a whole conversation, such as a follow-up that could slip past the gate. They are now fixed and covered by tests in the repository. Fairness monitoring, compensation for half-completed skills and review under real queue pressure are not yet tested, so what stands here is a design argument with two builds behind it rather than a settled comparison. The implementation will change with each tool. The safe shape should not: structure at the edges, freedom in the middle, with the consequential decisions owned by the process.

So, who meets you at the door? An agent that can answer, do the small things and hand you over well, inside a process that knows which decisions it may never make. The ones that change a life stay with a rule and a person. That is not a limit on the concierge. It is what makes it safe to let one loose. That is Enterprise Agency.

Terms

Plain-English definitions for the terms and tooling in this post, listed alphabetically.

Agency. How much freedom a system has to decide its own next step. In this post, the leeway given to the agent between an outer layer of process orchestration and an inner layer of skills.

Augmented LLM. A language model with retrieval, tools and memory attached. Anthropic's name for the basic building block of agentic systems.

Automated decision-making (ADM). A decision about a person made solely by a system, without meaningful human involvement, with legal or similarly significant effects. Restricted by GDPR Article 22 in the EU and governed by Articles 22A to 22D of UK GDPR, inserted by the Data (Use and Access) Act 2025 and in force since 5 February 2026.

Automation bias. The tendency of people to accept a system's output without checking it. The EU AI Act requires human overseers of high-risk systems to be helped to resist it.

Checkpointer. LangGraph's persistence layer. It saves the graph's state at every step, which is what lets a graph pause for a human and resume later.

Consumer Duty. The FCA rule requiring firms to deliver good outcomes for retail customers. The FCA applies it to AI-driven services as it does to any other.

DORA. The EU Digital Operational Resilience Act, applying to financial entities since January 2025. It makes the management body accountable for ICT and third-party risk, which now includes AI model providers.

EBA. The European Banking Authority, whose guidelines on internal governance and on loan origination set the EU expectations for management body responsibility and for the use of automated models in credit decisions.

Enterprise Agency. My name for agentic AI that an enterprise can stand behind: agents and workflows built from the augmented LLM, with structure at the edges and freedom in the middle. The agent chooses its next step, while the process owns authorisation, human decisions and what changes over time.

EU AI Act. The EU's cross-industry, risk-based AI regulation (Regulation 2024/1689). Prohibited practices apply from February 2025 and general-purpose model rules from August 2025. The high-risk obligations, delayed by the Digital Omnibus, apply from December 2027 for standalone Annex III uses and from August 2028 for high-risk AI embedded in regulated products under Annex I.

Evaluator-optimiser. A loop in which one model produces an output and another evaluates it, repeating until the output passes.

Guardrail. A check on what goes into or comes out of a model: relevance, safety, personal data, tone, rules compliance. Best used in layers.

High-risk AI system. Under the EU AI Act, either a safety component of a product covered by the EU product safety laws listed in Annex I, or a system used for one of the Annex III purposes, such as creditworthiness, risk assessment and pricing for life and health insurance, recruitment, education admission and access to essential services. Such systems must be designed for effective human oversight and keep logs. In defined cases, a person affected by a decision based on an Annex III system can ask the deployer for a clear explanation (Article 86). This statutory category is separate from the high rating this design puts on a tool or skill.

Impact and policy gate. The deterministic check on the outer band, drawn as the ADM? diamond, that reads structured facts about an agent's output and decides whether it goes straight through or to a named decision owner before it becomes an outcome. Missing or unrecognised facts route to review.

Interrupt. LangGraph's mechanism for stopping a graph mid-run, saving state and waiting for a person to resume it, used here when the gate flags a case for review.

Learning loop. The reviewed route by which an agent improves over time. Traces reveal step sequences that keep working, tools that are misused and gaps in knowledge. A person reviews each proposed change, it passes the evaluation set and only then is it promoted into skills, tools or knowledge. The agent never changes itself.

MCP (Model Context Protocol). An open standard for connecting AI applications to tools and data. An MCP server publishes tools with typed schemas. An MCP-aware client such as n8n or LangGraph can discover and call them without bespoke integration.

Orchestrator-workers. A pattern where one model breaks a task into sub-tasks, delegates them to worker calls and synthesises the results.

Pre-action authorisation. The deterministic process control on every call an agent proposes, checking the risk rating, relevant flags and the session's permissions before it runs. Only authorised calls run, and a refusal returns to the agent as a result to reason about.

Prompt chaining. A task split into sequential model calls with a programmatic check between them.

Prompt injection. Text in a message, document or web page that a model treats as instructions, overriding its intended rules. Ranked first in the OWASP Top 10 for LLM applications.

RAG (retrieval-augmented generation). Giving the model knowledge at the moment it needs it, by retrieving relevant material (policies, product terms, a customer's history) and placing it in the prompt. RAG is to knowledge what MCP is to tools: how it gets in, not what the agent is allowed to do with it.

RAO (reason, act, observe). The agent loop: the model reasons about the next step, acts through a skill or tool, observes the result and repeats until the goal is met or a limit stops it. Descended from the ReAct pattern.

Routing. Classifying an input and sending it down a specialised path.

Segregation of duties. The control principle that the party who initiates an action must not be the party who approves it. In banking, the maker-checker or four-eyes rule. Here, the agent proposes and the gate and decision owner approve.

Skill. A bounded, governed capability an agent can call but not modify: a defined input, a defined output and a risk rating. Implemented as a sub-workflow in n8n or a typed tool in LangGraph.

SMCR. The Senior Managers and Certification Regime, established under the Financial Services and Markets Act 2000 as amended in 2013. Every regulated activity sits within a named senior manager's statement of responsibilities, and the statutory duty of responsibility makes that person accountable for harm in their area, including harm caused through AI, if they did not take reasonable steps to prevent it.

Three lines model. The Institute of Internal Auditors' governance model of organisational roles. The first line does the work and owns its risks and controls. The second line, risk and compliance, monitors and challenges. The third line, internal audit, gives independent assurance. The agent is a system operated by the first line, and the gates and decision owner are first-line controls. The lineage on the outer band is what the second and third lines rely on.

Tool. A single action a model can call: a name, a description and a typed input. The platform runs it and returns the result. The atomic unit that skills are built from.

Tool risk rating. A low, medium or high rating on each tool and each skill an agent can call, based on read or write access, reversibility, permissions and financial impact. A skill inherits at least the highest rating of the tools and data it uses. In this design, a tool or skill rated high needs a person to decide before it runs. The rating is this design's own control, not the AI Act's high-risk classification.

References

External sources referenced in this post.

Design patterns

• Yao et al.: ReAct, synergizing reasoning and acting in language models (2022). link
• Anthropic: Building effective agents. link
• LangChain: Workflows and agents (LangGraph docs). link
• OpenAI: A practical guide to building agents. link

Adoption

• McKinsey: The state of AI in 2026, global survey of 1,719 respondents (August 2026). link

Regulation

• EU AI Act (Regulation 2024/1689), including Annex III high-risk uses and Article 14 on human oversight. link
• EU AI Act implementation timeline, including the Digital Omnibus delay to the high-risk obligations. link
• Colorado SB26-189, automated decision-making technology (signed May 2026, replacing the 2024 AI Act, applying from 1 January 2027). link
• Article 29 Working Party, endorsed by the EDPB: Guidelines on automated individual decision-making and profiling (WP251), on meaningful human involvement. link
• EU GDPR (Regulation 2016/679), including Article 22 on automated individual decision-making. link
• EBA: Guidelines on loan origination and monitoring (2020), including the use of automated and machine-learning models in creditworthiness assessment. link
• EBA: Guidelines on internal governance (2021), management body responsibility for the risk framework. link
• EU Digital Operational Resilience Act (Regulation 2022/2554), in force 17 January 2025. link
• FCA: Rethinking regulation for the age of AI (speech). link
• UK Data (Use and Access) Act 2025: factsheet on the changes to UK GDPR, including Articles 22A to 22D. link
• UK Data (Use and Access) Act 2025: plans for commencement (data protection provisions in force 5 February 2026). link
• UK Financial Services and Markets Act 2000, Part 5 (senior managers, statements of responsibilities and the duty of responsibility). link
• UK Parliament Treasury Committee: Artificial intelligence in financial services (January 2026). link
• NIST AI Risk Management Framework. link
• ISO/IEC 42001:2023, AI management systems. link
• UK Government: A pro-innovation approach to AI regulation (the five principles). link

Controls and safety

• COSO: Internal Control, Integrated Framework (segregation of duties). link
• Basel Committee on Banking Supervision: Revisions to the principles for the sound management of operational risk (2021). link
• IEC: Functional safety and IEC 61508 / 61511, independence of protection layers. link
• OWASP Top 10 for LLM Applications 2025, including prompt injection and excessive agency. link
• OWASP LLM01:2025 Prompt Injection. link
• The Institute of Internal Auditors: The IIA's Three Lines Model. link
• Panickssery, Bowman and Feng: LLM evaluators recognize and favor their own generations (2024). link

Tooling

• LangChain: Interrupts (LangGraph docs). link
• n8n: Guardrails node (n8n docs). link