Welcome. The spy imagery is a joke with a point: an agent is something you send out to act on your behalf, with standing instructions, in an environment you do not fully control. Everything before today has been about systems that answer . Today is about systems that do — and that one word changes the engineering, the economics and the liability. Outline EMBA 8160 — AI for Leaders · Session 2
1. What an agent actually is
2. From a pattern that answers to a process that acts
3. A worked example: the refund agent
4. AI agents vs. Agentic AI
5. Multi-agent systems and coordination
6. The four design patterns
7. Architectures and frameworks
8. What this looks like in industry
Hold one question throughout: what is this system allowed to do without asking anyone? That single question organises most of the governance work in this field. Sections 1–3 build the vocabulary and one concrete example. Sections 4–6 scale it up. Sections 7–8 are what you will actually be shown by vendors and internal teams. What Is an Agent? Definitions, components, and why this is not a chatbot
Part one: the vocabulary. Most arguments about agent strategy are really arguments about what the word means.
The working definition: a system that perceives its environment, reasons over what it finds, plans a course of action, and executes on behalf of a user. The foundational definition is fifty years older than ChatGPT — Russell and Norvig’s “anything perceiving its environment through sensors and acting upon it through actuators.” Agents are a classical AI idea; the language model is a new engine dropped into an old architecture. The distinction that matters commercially is bottom left: a perception-action loop rather than a single prompt and response. The system keeps going until the goal is met or it gives up. “Beyond chatbots” is the sentence to repeat: decomposes problems, holds context over long horizons, and calls external tools. A chatbot’s output is text. An agent’s output is a changed system . Four properties worth pulling out for a business audience. Continuous cycles mean the system is adaptive — and also that it can loop, which is a cost and safety concern we will come back to.Multimodal input means text, images and sensor data: relevant for anyone in manufacturing, logistics or clinical settings where the signal is not a document.Modularity is the procurement point. Perception, reasoning, memory and tools are separable components, so you can replace one without rebuilding the system. Be sceptical of any vendor whose architecture does not let you swap the model.Eight components. Four are obvious — perception, reasoning, memory, action. Four are where projects succeed or fail: planning , tool integration , learning , and safety . Note that safety is drawn as a component, not a policy document. Guardrails, toxicity checks and human validation are things that are built, staffed and tested — or they do not exist. Ask the room to guess which box consumes the most engineering time in practice. It is usually tool integration: connecting to enterprise systems that were never designed to be driven by a language model. Use this slide as a checklist in design reviews. If a proposed “agent” has no memory and no planning, it is a chatbot with an API call, and it should be priced like one. From Pattern to Process Why RAG is a straight line and an agent is a loop
Part two: the mechanical heart of the session, and the bridge from the last two sessions on RAG.
Here is what we built in the last two sessions, drawn honestly: query, retrieve, generate, answer. A straight line. Fixed control flow — the path is decided in advance, and there is no branching. Static goal — answer one question from available context.The limitation is the whole reason for today: it cannot do multi-step reasoning and it cannot take external action. Ask it to process the refund rather than explain the refund policy and the architecture has nothing to offer. The inversion, and the single most important slide in the deck. The straight line becomes one option inside a loop: goal, plan, decide , act, evaluate — and back to plan if the goal is not met. Look at what sits behind “decide”: RAG, APIs, a code interpreter. RAG becomes a tool the agent chooses to use , not the architecture of the system. That sentence is worth saying twice, because it reframes every RAG project in the room. The retrieval system you just scoped is a component in something larger. The governance consequence arrives with the word “decide.” A system with a fixed path can be tested exhaustively. A system that chooses its own path cannot — you test the policy , not the path. The loop in four words: perceive, decide, act, remember . The next three slides open up three of those quadrants. Compare it to OODA if the room has a military or operations background — observe, orient, decide, act. Same structure, and the same insight: the advantage comes from cycling faster and from the quality of what you remember between cycles. “Remember” is the one people skip. Without state, an agent repeats itself, re-does work, and cannot explain what it did. The decide quadrant. The foundation model is the brain, and it is doing three specific jobs. Decomposition : high-level goal into atomic steps. Chain of thought : an internal monologue used to validate its own logic. Routing : choosing which tool to engage.Self-reflection sits in the middle of the diagram — the agent critiquing its own plan before acting. That is cheap insurance and it is the Reflection pattern we come back to later. Caution worth voicing: the internal monologue is generated text , not a guaranteed account of the model’s actual computation. It is extremely useful for debugging and it is not a compliance artifact. Do not let anyone present chain-of-thought as an audit trail. The act quadrant, and the slide where the risk conversation really begins. Connectors that let the agent “affect the world, not just speak about it.” Look at the tool list in the code box: search_docs, update_record, issue_refund. Three lines, and the third one moves money. The technical framing is a list of functions. The business framing is a list of permissions granted to a non-deterministic system . Those are the same list, and only one of them gets reviewed in most organisations. Practical guidance: every tool an agent holds should have its own authorisation, its own rate limit, and its own audit log. “The agent has API access” is not an acceptable answer to a control question. The remember quadrant, split two ways: short-term (the context window — chat history and the current plan) and long-term (a database of user preferences and domain knowledge). The right-hand box is the part engineers care about and leaders should too: structured state . customer_verified: true, refund_amount: 75.00, status: pending_approval. Why it matters: the state object, not the conversation, is the record of what the system believed and did. It is what you replay in a dispute, and it is what a regulator will ask for. Free-text chat history is not a substitute. Observation and self-correction loop back into both stores — the agent checks the result of its action and updates what it believes. What the team sees
A function signature payment.issue_refund(order_id, amount)
Adding a tool is a ten-minute task. That is genuinely what makes agents powerful.
What you are approving
A standing authority A probabilistic system may move money, on its own judgement, at a rate limited only by how often people ask.
The same ten minutes, from the other side of the table.
Ask for four things per tool: who authorised it , what the blast radius is , what the ceiling is , and how it gets reversed .
This is the slide to spend real time on. The gap between how cheap it is to add a tool and how consequential the tool is, is the central governance problem of agentic systems. The four questions are the practical version. Blast radius: what is the worst single call? Ceiling: the hard limit that is enforced in code, not in the prompt. Reversal: is there an undo, and who can run it? Say clearly: a limit written in a prompt is a request . A limit enforced in the tool wrapper is a control . Auditors care about the second kind, and so should you. Agents at Work Where they are deployed, and one example in detail
The deployment map across eight domains. Do not read it out — pick the two closest to the room and dwell there. A pattern worth naming: almost every entry replaces coordination work rather than thinking work. Routing a query, chasing a shipment, checking a contract against a playbook, assembling a report. That is where the near-term value is, and it is also where the headcount questions land. Note “RAG routers” under customer service — exactly the routing architecture from the last session, now one component inside an agent. One sentence from a customer: “I need a refund for my last order.” Four things have to happen: verify identity, retrieve purchase history, check the business rule, execute the refund. The line at the bottom is the whole session compressed: a standard chatbot can explain the policy; an agent applies it. Notice the business rule is a threshold — under $\$100$. Someone chose that number. That choice is the actual autonomy decision, and it is usually made in a configuration file by whoever is building the system. Ask: who in your organisation signs off on that threshold today for a human agent? Whoever it is, they should sign off on this one. The same transaction as a trace. Input, LLM classifies intent and plans, CRM tool, billing tool, a deterministic logic check on the 30-day window, the refund call, a write to memory, and a response. Two colours, two kinds of step. The red diamonds are model judgement ; the green boxes are deterministic calls . Good agent design pushes as much as possible into green. Point at the “within 30 days?” check specifically: that is a business rule evaluated in code, not by the model. If that check were phrased as a prompt instruction, it would hold most of the time — and most of the time is not a policy. This trace is also the audit record. If your team cannot produce a picture like this for a real transaction after the fact, the system is not ready for production. Where that refund agent breaks Misread intent “I'd like to know about refunds” is classified as a refund request. The model acts on an enquiry.
Stale or wrong data The CRM lookup returns the wrong order. Every downstream step is correct and the outcome is wrong.
Partial failure The refund API succeeds; the memory write fails. The system does not know what it did.
Loops and cost The goal is never judged “met,” so the agent re-plans indefinitely. The bill and the latency grow together.
Prompt injection The customer writes text designed to be read as an instruction. The attack surface is the input field.
Threshold drift The $\$100$ ceiling lives in a prompt, not in the payment wrapper, and quietly stops binding.
None of these are exotic. Every one has been observed in deployed systems. Partial failure is the one that surprises executives: unlike a database transaction, an agent’s sequence of tool calls has no automatic rollback. If money moved and the log did not, you have a reconciliation problem and no record of the cause.Prompt injection deserves its own sentence: the user’s text and the system’s instructions travel in the same channel, so anything a user can write is potentially an instruction. This is why a tool that can move money must never trust the model’s judgement alone.The mitigations are unglamorous and effective: step limits, budget caps, idempotent tool calls, deterministic rule checks, and human approval above a threshold. Agents vs. Agentic AI The unit and the system
Part four: a distinction vendors blur, and one you should be able to hold firmly.
AI agents are the building blocks; Agentic AI is the system-level paradigm. An agent answers a question or processes a file. Agentic AI manages a supply chain.The autonomy row is the one to interrogate. “Reactive” means it operates within predefined constraints and usually waits to be asked. “Proactive” means it formulates its own goals . Be direct with the room: the right-hand column is mostly aspiration today. Very few production systems self-formulate goals, and the ones that do are narrowly bounded. When a vendor sells the right-hand column, ask which specific goals the system sets for itself and what stops it setting one you would not approve. The useful takeaway is not the taxonomy — it is that autonomy is a dial, and someone has to decide where it is set. The four foundational patterns, which we will see again in detail: reflection , planning , tool use , multi-agent collaboration . These are composable, not alternatives. A serious system uses all four. Flag the cost structure now: reflection means generating output more than once, planning means extra model calls before any work happens, and multi-agent means several models in conversation. Each pattern buys quality with tokens and latency. There is no free reliability. Four higher-order principles. Governed autonomy is first, and deliberately so: independent operation within strict guardrails , with human approval checkpoints for critical actions. System-level orchestration is the organisational claim — coordination across functions, breaking silos between production, logistics and sales. Note what that implies: the agent inherits every data-sharing and access question those silos were partly there to manage.Proactive goal formulation — “from reactive executor to proactive partner” — is the frontier claim. Treat it as a direction of travel, not a current capability.The leadership read: principles one and two are buildable today and are mostly governance work. Principles three and four are where the research is. Multi-Agent Systems From decomposing steps to decomposing roles
On the left, one agent with everything pointed at it — inputs, data, tasks, and a lot of question marks. On the right, three agents with roles. The shift: from decomposing steps to decomposing roles. That is an organisational design idea, not a technical one, and it is why this material feels familiar to anyone who has structured a team.Two justifications given: specialisation (each agent optimised for a sub-domain, with its own instructions and tools) and complexity management (preventing context window overflow). The second is the more honest engineering reason. A single agent holding an entire complex task runs out of room and starts losing the thread — the “lost in the middle” problem from the last session, now applied to a plan rather than a document. Two structural pieces: the orchestrator — the manager that controls flow, routes outputs, and decides when the goal is met — and the shared state or blackboard , the common workspace all agents read from and write to. The blackboard is an old idea from classical AI and it is the right one. It means agents do not need to talk to each other directly; they publish to a shared board. Two questions to ask about any multi-agent design: who decides the goal is met , and what happens when two agents write contradictory things to the blackboard? Teams often have no answer to the second. Organisational analogy, and a warning with it: a manager, a shared document, and three specialists. Multi-agent systems inherit the failure modes of human teams too — deadlock, duplicated work, and diffusion of responsibility. Two coordination modes. Linear — the relay race: a fixed sequence, best for predictable workflows. Adaptive — the basketball team: dynamic routing where the orchestrator picks the next agent based on context. The trade-off is exactly the one from earlier: the relay race is testable, auditable and cheap; the basketball team handles novelty and cannot be exhaustively tested. Strong practical advice for the room: start with the relay race. Most processes that get proposed for adaptive coordination turn out to be predictable enough for a fixed sequence, and the fixed sequence can be explained to an auditor. Escalate to adaptive coordination only where you can point to real variation that the fixed path handles badly. A second worked example with genuinely different shape: raw PDF in, OCR required, legal tone and compliance constraints, risk compared against internal playbooks, and new clauses drafted and synced to the contract management system. “Too complex for a single prompt. Requires a team. ” — note the specific reason. It is not that the task is hard; it is that the task has four different kinds of work, each needing different instructions, different tools, and different quality bars. The risk step is a RAG call against policy playbooks. Again, retrieval as a component. Worth flagging: the output is a redline draft , not a decision. That is a well-designed autonomy boundary and a good template — the system does the labour, a lawyer keeps the judgement. The team: an intake agent that configures the workflow, a classifier doing OCR and extraction, a risk analyst running the RAG policy check, and a drafter generating redlines — all coordinating through the shared blackboard holding the parsed contract, the risk list and the draft edits. Note the blackboard contents are structured artifacts , not conversation. That is what makes the system reviewable: a human can inspect the risk list without reading the agents’ chatter. This is also the natural place to insert human review — between the risk list and the draft edits. Pause the workflow, show a person the risks, let them approve before anything is drafted. The progression, and the exercise: take a RAG project you already have, redesign it as a single agent loop, then scale it to a multi-agent team with specialised roles. Use this as a live exercise if there is time. Most people in the room have a RAG project in flight or in the budget. The useful discipline in doing it: at each step, name what new capability you gained and what new failure mode you accepted. The arrow is not free in either direction. When not to build a team Multi-agent earns its cost when
The work has genuinely different kinds of task, each needing different tools, instructions or quality bars.
A single agent's context or instruction set has become unmanageable.
You want independent review — one agent checking another's work.
It is usually the wrong answer when
The process is a fixed sequence. That is a workflow, and a workflow engine will be cheaper, faster and testable.
Nobody can say which agent is accountable for the final output.
The team is reaching for it because the single agent is unreliable — more agents multiply an unreliable step rather than fixing it.
Each additional agent adds model calls, latency, and a new place for the handoff to go wrong. Complexity is a cost you pay every single transaction.
The last item on the right is the common failure. Multi-agent architectures are often adopted as a remedy for a step that simply does not work well. It rarely helps, and it makes the failure harder to locate. The “this is really a workflow” point is worth pressing. A large share of proposed agentic systems are deterministic business processes with one uncertain step. Build the deterministic part deterministically and use a model only where judgement is genuinely needed. Debuggability is the hidden cost: with one agent you ask why it did that. With six, you first have to work out which one did it. The Design Patterns Reflection, tool use, planning, and multi-agent
All four on one page. Reflection — generate, critique, iterate. Tool use — prompt out to tools, results back. Planning — plan, generate tasks, execute, re-plan. Multi-agent — specialised roles in conversation. Note the loop symbol in three of the four. Iteration is the common thread, and iteration is what separates these from a single prompt. Each of the next five slides takes one of these apart. Reflection : the system reviews its own output the way a human reviewer would, identifies errors, and revises. The self-critique loop can run several times.The worked example is Self-RAG , which applies reflection to the retrieval pipeline: instead of always retrieving a fixed number of documents, the model decides whether retrieval is needed, then critiques the segments it generated for relevance and support. The business translation: reflection buys accuracy with tokens. A useful rule is to reserve it for outputs that are expensive to get wrong — a contract redline, a customer-facing commitment, code that will be deployed. It is also the cheapest quality intervention available in most pipelines. If a team has never tried “generate, then critique, then revise,” that is the first experiment to run. The comparison in detail. Standard RAG on the left: retrieve k documents, prompt with all of them, generate. The result contains a contradiction and a passage with no supporting information — the FP4 failure from the last session. Self-RAG on the right: retrieve on demand, generate segments in parallel, then critique and select — each segment tagged relevant, irrelevant, supported or partially supported, and the best combination assembled. The bottom row is the elegant part. “Write an essay about your best summer vacation” triggers no retrieval at all , because the model judges that no external knowledge is needed. Standard RAG retrieves regardless, wasting cost and adding noise. Leadership version: the system decides whether it needs to look something up, and grades its own evidence. That is a meaningful reliability gain, and it costs more per query. Tool use in its general form: databases, web search, code execution, image generation, spreadsheet manipulation.The phrase to take away is “from static knowledge banks into dynamic agents that interact with external systems.” Code execution deserves a specific flag. An agent that can run code is extraordinarily capable and is also arbitrary code execution inside your environment. It belongs in a sandbox with no network access and no credentials, every time, without exception. Planning : build a roadmap of subtasks before executing, rather than working linearly.Two named approaches your engineers will mention. ReAct — reasoning and acting interleaved, so the agent thinks, acts, observes the result, and thinks again. ReWOO — reasoning decoupled from observation, so the plan is formed up front and executed with fewer model calls. The practical distinction for a budget conversation: ReAct is adaptive and expensive because every step involves the model; ReWOO is cheaper and less able to recover when reality departs from the plan. The figure glosses ReWOO as “Reasoning With Open Ontology” in one place and “Reasoning WithOut Observation” in another. The second is the correct expansion — worth knowing before someone in the room checks. Multi-agent , with the three organisational shapes named explicitly on the right: collaborative (peers sharing progress), supervised (a supervisor coordinating and verifying), and hierarchical (decisions cascading through levels).These are the three shapes human organisations use, for the same reasons. The supervised pattern is the one most enterprises should start with, because it creates a single place where quality is verified and a single answer to “who is accountable.” The analogy to project management is in the source text, and it is fair. Just note that it inherits the failure modes too: unclear ownership, handoff loss, and meetings that produce nothing. Architectures & Frameworks What the reference designs look like, and what you will be sold
A catalogue rather than a diagram to read line by line. Single versus multi-agent at the top; the coordination patterns in the middle — parallel, sequential, loop, router, aggregator, network, hierarchical ; six worked examples on the right. Point at two specifically. Router is the architecture from the end of the last session — classify the request, send it to the right handler. Human-in-the-loop (example 2) is the one that should appear in most enterprise designs and frequently does not. The value of a catalogue like this in a design review is that it turns “we’re building an agent” into “we’re building a supervised hierarchical system with a router in front,” which is a sentence you can actually interrogate. The classical taxonomy, from the Russell and Norvig textbook, and it is genuinely clarifying: simple reflex (condition-action rules), model-based reflex (keeps an internal model of a partially observable world), goal-based (searches and plans toward a goal), utility-based (optimises a utility function under uncertainty), and learning agents (a critic and a learning element that improve performance over time). Most LLM agents shipping today are goal-based. Utility-based agents are rarer and more consequential, because a utility function is an explicit statement of what the organisation values — and anything not in it gets traded away. That is the slide’s real lesson for leaders: if you let a system optimise, you have to be able to write down what “better” means. Most organisations discover they cannot. Note also that “learning agent” means the system changes after deployment. Anything that changes itself needs monitoring, not just testing. A real production-shaped architecture, numbered one to nine. Query in, system prompt and query parsing, a switch between a general language model and a dedicated reasoning model, a retrieval agent that fans out to a vector database, a semantic database and external search engines, short- and long-term memory, then a compiled output. Two details worth pointing at. First, the switch between model types: routing cheap questions to a cheap model and hard ones to an expensive reasoning model is one of the main levers on unit economics. Second, retrieval agents A and B running against different sources — internal knowledge and the public web — which is an obvious place for a data-leakage control. This is roughly what a serious internal “ask anything” system looks like. Note how little of it is the model. The layered enterprise reference architecture: input layer, orchestration layer, the agents themselves, a data storage and retrieval layer, then output and service layers. The band across the bottom is the one to dwell on: safety and control, ethics and responsible AI, regulatory and compliance, interoperability, versioning and evaluation, human-AI collaboration. Drawn as a foundation under everything, which is the correct picture and rarely the correct project plan. Note “monitoring and observability” sitting inside the orchestration layer — the same lesson as the RAG session. If you cannot see what the system did, you cannot improve it or defend it. Also note the data layer holds vector stores and knowledge graphs and structured data. The interesting enterprise systems are not purely vector-based. The tooling landscape: LangChain, LangGraph, CrewAI, Microsoft Semantic Kernel, AutoGen, Smolagents, AutoGPT — with a comparison table adding LlamaIndex, Swarm and PydanticAI. Do not memorise it; this layer moves faster than any slide can track. Read the shape instead: some are general application frameworks, some are graph-based orchestration, some are role-based team frameworks, and some enforce structured output. The weakness column is the honest one. “Debugging is hard” against the most popular framework is a real finding, and it connects straight back to observability. The leadership point: a framework is a convenience layer, not an architecture. The decisions that matter — which tools, what autonomy, what gets logged, who approves — are the same in all of them. Don’t let the framework be the architecture What a framework gives you Plumbing: tool calling, state passing, retries, streaming, traces. Genuinely useful, and increasingly commoditised.
What it does not give you The autonomy boundary, the approval thresholds, the audit record, the evaluation set, and the answer to who is accountable for an action.
The question to ask “If we replaced this framework next year, what would we have to rebuild?” If the answer includes your guardrails or your audit trail, they are in the wrong place.
This layer is young and consolidating. Design so that the framework is replaceable, because it may well be replaced.
Teams choose a framework in week one and inherit its assumptions for the life of the system. Worth one deliberate conversation rather than a default. The portability test is the practical one. Guardrails, logging and approval logic should live in your own service layer, in front of the tools, not inside framework callbacks. If someone presents a framework choice as the architecture decision, the architecture decision has not been made yet. In the Business Where this is actually running, and where it is heading
Part eight: the industry picture, read with appropriate scepticism.
Customer service and clinical operations. Salesforce Agentforce handling interactions end to end; Microsoft Copilot agents across Microsoft 365; clinical workflow orchestration across triage, bed management and lab scheduling, exchanging data over HL7 FHIR. Two things to point out rather than read. First, “maintains zero-data-retention for privacy compliance” — a vendor claim , and exactly the kind of claim to put in a contract rather than a slide. Second, “maintains human-in-the-loop oversight for safety” in the pharmaceutical column: note that the highest-stakes domain on the slide is the one that keeps a human in the loop. General caution: these are largely announcements and vendor case studies. Treat them as evidence that the category is real, not as evidence that any specific number is. Capital-intensive industries: agents across oilfields interacting with digital twins, a multi-agent framework for industrial processes at BMW, natural-language queries over IoT sensor data with failure prediction, and autonomous finance reconciling statements and running compliance checks. The pattern across all four: the agent sits on top of systems that already had good structured data and clear rules. That is not a coincidence, and it is the most useful thing on the slide. Say it plainly: the organisations getting value from agents are the ones that did their data and process work first. If your master data is a mess, an agent will make expensive decisions from it faster. The finance row is the one closest to most of this room — reconciliation and compliance checking, high-volume rule-following work with a clear right answer. The progression: traditional AI reacting to inputs, AI agents with perception-action loops, agentic AI as proactive self-improving systems. And the transformation: from automating single tasks to managing operations. The three challenges listed are the right three, and they are governance problems rather than model problems: interpretability , safety , and accountability — “establishing responsibility frameworks.” That last one is where this room comes in. There is no technical solution to the question of who is responsible when an autonomous system acts. It is an organisational decision that has to be made before deployment, not after an incident. “Integration with legacy enterprise infrastructure” under strategic outlook is the unglamorous truth: most of the work ahead is plumbing into systems built decades ago. The autonomy dial Level The system… Appropriate when What must exist 1 · Advise Drafts or recommends; a human does everything Judgement-heavy, high-stakes, or novel work Nothing beyond normal review 2 · Act on approval Prepares the action; a human clicks Reversible but material actions A reviewer who has time to actually look 3 · Act and notify Acts within limits; a human is told after High-volume, low-value, easily reversed Hard ceilings in code, alerting, and an undo 4 · Act silently Acts; only exceptions surface Well-understood, measured, low-variance work Monitoring, sampling, and a named owner
The level is set per tool , not per system. The same agent can read at level 4, draft at level 1, and refund at level 2.
This is the slide to photograph, and the one to bring to your own governance conversation. The critical design insight is the footnote: autonomy is set per action, not per system. Most disagreements about “how autonomous should this be” dissolve once you break it into individual tools. Level 2 has a specific failure mode worth naming — rubber-stamping . An approval step where the reviewer approves 200 items an hour is a level 3 system with extra paperwork and a person to blame. If you rely on approval, measure the rejection rate. Level 3 is where most enterprise value sits today, and it is only safe with ceilings enforced in code and a working undo. Class Discussion Five questions. Small groups, then report back.
Discussion Question 1 Setting the Dial Your service organisation wants an agent that can issue refunds, update shipping addresses, apply account credits, and cancel subscriptions.
Assign an autonomy level to each of those four actions and justify the differences. Which one would you refuse to automate at all, and what would change your mind?
Looking for per-tool reasoning: address updates are low-stakes and reversible; refunds are material but bounded; account credits create liability; cancellations may be irreversible and have retention consequences. Push on reversibility as the organising criterion, and on the ceiling — a refund agent at level 3 up to $\$50$ and level 2 above it is a perfectly good answer. “What would change your mind” is the real question: usually measured error rates from a period at a lower level. Discussion Question 2 Workflow or Agent? A team proposes a multi-agent system to handle supplier onboarding: collect documents, verify registration, check sanctions lists, score risk, and create the vendor record.
How much of that is genuinely agentic, and how much is a workflow with one uncertain step? What would you approve, and what would you send back?
Most of it is a deterministic workflow. Sanctions screening in particular must be a deterministic check against an authoritative list — never a model’s judgement. The genuinely uncertain steps are document extraction from heterogeneous formats and perhaps risk scoring on unstructured inputs. The answer to look for: build the workflow, use models only at the uncertain steps, and do not let a model decide whether a sanctions hit is a match. Discussion Question 3 You are shown an agent design. Its tool list includes search_knowledge_base, send_email_to_customer, update_crm_record, issue_refund, and execute_sql.
Which of these worry you, and why? What controls would you require before any of them ships — and which would you strike from the list?
execute_sql is the one to strike, or confine to a read-only replica with a fixed schema. Arbitrary query execution driven by natural language is both a data-exfiltration and a data-integrity risk.send_email_to_customer is underrated: it is irreversible, it is external, and it speaks in the company’s voice.Controls to look for: per-tool authorisation, hard ceilings in the wrapper rather than the prompt, idempotency, full audit logging, and a rollback path. Discussion Question 4 Who Is Accountable? An agent in your firm takes a defensible-looking action that turns out to be wrong and costs a client money. The trace shows the model chose a reasonable path from the information it had; the information was stale.
Who is accountable — and how would you have had to structure the project beforehand for that answer to be clear?
The answer is never “the model.” Candidates: the process owner who set the autonomy level, the data owner whose feed was stale, the engineering owner who did not check freshness. What has to exist beforehand: a named owner per tool, an agreed autonomy level, data freshness requirements written down, and a trace you can reconstruct. Connect to the Responsible AI session — this is the accountability gap that framework material addresses directly. Discussion Question 5 Synthesis Take the RAG project from the last session — the knowledge assistant over policies and handbooks. Your CEO now asks why it can only answer questions when “everyone says agents can actually do things.”
Redesign it as an agent. What tools would you give it, at what autonomy level, with what guardrails? What does the phase-one scope look like, and what would you tell the CEO you are deliberately *not* doing yet?
Strong answers start at level 1 and level 2 tools: draft a response, raise a ticket, schedule a meeting, prefill a form. Nothing irreversible in phase one. The deliberate omissions are the interesting part: no writes to systems of record, no external communication, no financial actions. Best answers note that the evaluation harness from the RAG session must be extended — you are now measuring actions taken, not just answers given, and “was the answer right” becomes “was the action correct, authorised, and reversible.” Takeaways RAG is a pattern; an agent is a process The retrieval system becomes a tool the agent chooses to use. Everything you built last session survives — as a component.
Every tool is a permission A one-line function signature is a standing grant of authority to a probabilistic system. Review it as such.
Set the autonomy dial per action, not per system Read at level 4, draft at level 1, spend money at level 2. Ceilings belong in code, not in prompts.
Most “agentic” proposals are workflows with one uncertain step Build the deterministic part deterministically. Reach for a team of agents only when the work has genuinely different kinds of task.
If one sentence survives the session: the question is not what the system can do, it is what it is allowed to do without asking. The through-line across all three sessions: the model is not the system, the system is not one system, and now — the system does not only speak, it acts. Each step adds capability and subtracts the ability to test exhaustively. Agent foundations and the classical taxonomy
Stuart Russell & Peter Norvig, Artificial Intelligence: A Modern Approach — the sensor/actuator definition and the five classic agent types (simple reflex, model-based, goal-based, utility-based, learning).
The four agentic design patterns
Yugank Aman, “Top Agentic AI Design Patterns for Architecting AI Systems,” Medium — credited on the figures themselves. The Self-RAG comparison originates with Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (2023).
Architecture diagrams
The agentic search architecture is credited on the figure to @rakeshgohel01 . Framework comparisons reflect a fast-moving landscape and will date quickly.
About these figures
Several diagrams in this deck were generated with NotebookLM ; the industry slides report vendor and press claims that have not been independently verified. Useful as a map of the category — not as evidence for any specific number.
Worth saying the last card out loud. In a session about delegating action to machines, being explicit about which claims are verified and which are marketing is part of the lesson. If anyone wants to go deeper: Russell and Norvig for the foundations, and the Self-RAG paper for a concrete, readable example of reflection applied to retrieval. 
