Quick Navigation
- The shift from automation to agency
- Agents vs traditional automation
- The agent loop — how they actually work
- Agentic reasoning patterns
- Protocols — MCP and A2A
- Tool use — giving agents hands
- Memory — what agents remember
- Multi-agent systems
- Governance — controlling agents
- The agent architecture in one diagram
- Cheat sheet
The shift from automation to agency
A chatbot answers your question. An agent does the work.
That distinction — between AI you talk to and AI that acts on your behalf — is the single most important shift happening in AI right now. And it's happening faster than most organisations are prepared for.
Traditional automation follows rules. AI agents follow goals. A traditional automation says: "When an email arrives with the word 'urgent' in the subject, flag it." An agent says: "Monitor my inbox, categorise emails, draft responses for routine ones, flag the ones that need my attention, and summarise the rest."
The agent doesn't need every step defined. It figures out the steps from the goal. That is both the power and the risk.
This guide walks through what agents are, how they work, the protocols that are making them interoperable (MCP for connecting to tools, A2A for connecting to each other), and the governance you need before you let one act without your direct approval.
flowchart TD
GOAL["User defines a goal"] --> PLAN["Agent plans\nBreaks goal into steps"]
PLAN --> ACT["Agent acts\nUses tools via MCP"]
ACT --> OBSERVE["Agent observes\nChecks results, retrieves context"]
OBSERVE --> DECIDE{"Goal achieved?"}
DECIDE -->|"No"| ACT
DECIDE -->|"Yes"| DONE["Delivers result"]
DECIDE -->|"Stuck"| ASK["Asks human for guidance"]
Agents are not magic. They are structured loops — plan, act, observe, decide — powered by LLMs and connected to tools via protocols like MCP. The loop is simple. The emergent behaviour from scaling it is not.
Try it yourself — The agent opportunity scan
List three processes in your work that follow goals rather than rules. If a process changes frequently or has unpredictable inputs, it's an agent candidate. If it's stable and predictable, traditional automation is better.
| Process | Why it needs flexibility, not fixed rules | Current pain |
|---|---|---|
| e.g. Processing customer refund requests | Each case has different context and history | Takes 20 minutes per case, inconsistent outcomes |
Agents vs traditional automation
People confuse AI agents with traditional automation. They're fundamentally different — and the differences matter for what you can build and what can go wrong.
flowchart TD
COMP["Agents vs Automation"]
COMP --> TRAD["Traditional Automation\nRule-based · Fixed steps\nBrittle · Predictable"]
COMP --> AGENT["AI Agents\nGoal-based · Flexible steps\nAdaptive · Emergent"]
TRAD --> T1["IF email contains 'urgent'\nTHEN flag it"]
TRAD --> T2["Every rule must be defined"]
TRAD --> T3["Breaks when conditions change"]
AGENT --> A1["Monitor inbox and flag\nwhat seems urgent"]
AGENT --> A2["Figures out steps from the goal"]
AGENT --> A3["Adapts to new situations"]
| Traditional Automation | AI Agents | |
|---|---|---|
| How it works | Follows explicit rules | Pursues goals |
| Flexibility | Fixed — handles known scenarios | Adaptive — handles novel situations |
| Decision-making | Rule-based | Context-aware |
| Failure mode | Breaks on unexpected input | May take unexpected actions |
| Predictability | Highly predictable | Emergent behaviour |
| Setup effort | High — define every rule | Lower — define goal and constraints |
| Best for | Stable, well-defined processes | Dynamic, ambiguous tasks |
The automation spectrum is worth understanding. It runs from simple rule-based scripts, through RPA bots and AI-augmented automation, to goal-driven agents, to multi-agent systems that coordinate autonomously. Each level is more capable — and more risky — than the last.
Agents are not always the right choice. For stable, well-defined processes, traditional automation is more reliable and cheaper. The governance implications increase dramatically as you move up the spectrum. Choose the level that fits the task, not the one that sounds most impressive.
Try it yourself — Your automation spectrum
For each process you listed earlier, where does it sit on the spectrum? Your highest governance risk is where to start with the most oversight.
| Process | Best level | Why? | Governance risk |
|---|---|---|---|
| e.g. Processing refund requests | Agent | Needs judgment on edge cases | High — financial decisions |
The agent loop — how they actually work
AI agents feel complex. But their core architecture is a simple loop. Understanding the loop is understanding the agent.
Every agent follows a version of the Observe-Orient-Decide-Act cycle:
flowchart TD
START["Goal received"] --> OBS["Observe\nGather information\nfrom tools and context"]
OBS --> ORIENT["Orient\nUnderstand current state\nAssess progress"]
ORIENT --> DEC["Decide\nChoose next action"]
DEC --> ACT["Act\nExecute the action\nuse a tool, generate output"]
ACT --> CHECK{"Goal\nachieved?"}
CHECK -->|"No"| OBS
CHECK -->|"Yes"| DONE["Deliver result"]
| Component | What it does | Example |
|---|---|---|
| Observe | Gathers information from tools, context, and memory | Reads a file, searches the web, checks a database |
| Orient | Assesses current state and progress toward goal | "I have 3 of the 5 data points I need" |
| Decide | Chooses the next action based on current state | "I need to search for the remaining 2 data points" |
| Act | Executes the chosen action | Calls the search tool, processes results |
The LLM is the reasoning engine at the centre of this loop — it decides what to do next. The tools are the hands. The memory is the continuity that lets the agent build on previous work instead of starting from zero each time.
This architecture is sometimes called ReAct — Reasoning and Acting interleaved. The LLM thinks about what it needs to do, then does it, then observes the result, then thinks again. The loop continues until the goal is achieved or the agent determines it needs human help.
Try it yourself — Design your first agent
Pick one process from your opportunity scan. Design the agent. If you can't fill in the guardrails, you're not ready to deploy this agent.
| Component | Your design |
|---|---|
| Goal — what should it achieve? | |
| Tools — what does it need access to? | |
| Observation — how does it know if it's working? | |
| Human handoff — when should it ask for help? | |
| Guardrails — what should it never do? |
Agentic reasoning patterns
Agents need reasoning strategies — not just "what to do" but "how to think." Different tasks require different reasoning patterns.
flowchart TD
PATTERNS["Agentic Patterns"]
PATTERNS --> REACT["ReAct\nReasoning + Acting\nInterleaved thinking and doing"]
PATTERNS --> COT["Chain-of-Thought\nStep-by-step reasoning\nSequential logic"]
PATTERNS --> TOT["Tree-of-Thought\nExploring multiple paths\nBranching reasoning"]
PATTERNS --> PE["Plan-and-Execute\nPlan first, then execute\nSeparate planning from acting"]
PATTERNS --> REFLECT["Reflection\nSelf-evaluation and correction\nIterative improvement"]
| Pattern | How it works | Best for | Trade-offs |
|---|---|---|---|
| ReAct | Interleaves reasoning and action — think, act, observe, repeat | General-purpose agent tasks | Can get stuck in loops |
| Chain-of-Thought | Explicit step-by-step reasoning before answering | Complex analysis, math, logic | Slower, more tokens |
| Tree-of-Thought | Explores multiple reasoning paths, selects best | Creative problems, exploration | Expensive, complex |
| Plan-and-Execute | Creates full plan first, then executes steps | Complex multi-step tasks | Planning overhead |
| Reflection | Generates output, evaluates it, improves it | Quality-critical outputs | Multiple iterations |
ReAct is the foundation pattern — most agent frameworks build on it. Chain-of-Thought connects directly to the prompt engineering techniques covered elsewhere. Tree-of-Thought enables genuine augmentation — AI as a thinking partner exploring options you haven't considered. Plan-and-Execute is what you want for complex workflows. Reflection is what you want when quality matters more than speed.
Try it yourself — Pattern matching
For your agent design above, which reasoning pattern fits best? Your best fit is the pattern to implement first.
| Pattern | Does it fit? | Why or why not? |
|---|---|---|
| ReAct | ||
| Chain-of-Thought | ||
| Tree-of-Thought | ||
| Plan-and-Execute | ||
| Reflection |
Protocols — MCP and A2A
Without standards, every agent is an island — custom integrations, no interoperability, vendor lock-in. Protocols create a common language for agents to connect to tools and to each other.
Two protocols are shaping the agent ecosystem right now.
flowchart TD
PROT["Agent Protocols"]
PROT --> MCP["MCP\nModel Context Protocol\nConnect to tools and data"]
PROT --> A2A["A2A\nAgent-to-Agent Protocol\nAgents discover and communicate"]
MCP --> MCP1["Anthropic-led\nOpen standard\nJSON-RPC based"]
A2A --> A2A1["Google-led\nOpen standard\nHTTP + JSON"]
MCP (Model Context Protocol) is an open protocol created by Anthropic that standardises how AI models connect to external tools and data sources. Think of it as USB for AI — one protocol to connect any tool to any model. Write a tool once, use it with any MCP-compatible model. The ecosystem is growing rapidly — IDEs, databases, APIs are all adopting it.
A2A (Agent-to-Agent Protocol) is an open protocol created by Google that enables agents to discover, communicate, and collaborate with each other — even across organisational boundaries. Agents expose "Agent Cards" describing their capabilities. Other agents find them and send tasks. No custom integration required.
| MCP | A2A | |
|---|---|---|
| Scope | Tool and data connection | Agent-to-agent communication |
| Transport | JSON-RPC over stdio or HTTP | HTTP + JSON |
| Discovery | Server lists available tools | Agent Cards describe capabilities |
| Standardisation | Open — Anthropic-led | Open — Google-led |
| Maturity | Growing rapidly | Emerging |
Function calling is the native mechanism underneath both — each LLM provider has their own format for how a model invokes a tool. MCP and A2A build on top of that to create interoperability.
Protocols create ecosystems. Tools built for MCP work with any MCP-compatible model. A2A enables what people are calling the "agent economy" — agents selling services to other agents. These are open standards, not locked to one vendor. Early adoption creates competitive advantage.
Tool use — giving agents hands
An LLM alone can only generate text. An LLM with tools can take actions in the real world. Tools are what transform a chatbot into an agent.
flowchart LR
AGENT["Agent decides\n'I need to search the web'"] --> TOOL_CALL["Tool call\nsearch_web(query='AI news')"]
TOOL_CALL --> TOOL["Tool executes"]
TOOL --> RESULT["Result returns"]
RESULT --> AGENT2["Agent processes result\ncontinues toward goal"]
| Category | Examples | What it enables |
|---|---|---|
| Information | Web search, file read, database query | Research and data gathering |
| Communication | Email send, Slack message, notification | Interaction with people |
| Computation | Code execution, data analysis, calculation | Processing and calculation |
| Action | API calls, system commands, workflow triggers | Taking actions in external systems |
| Creation | File write, document generation, code commit | Producing outputs |
| Agent services | Other agents via A2A protocol | Delegating to specialists |
Tool descriptions are critical. The LLM chooses tools based on their descriptions, so poor descriptions lead to wrong tool selection. Tool permissions are a governance concern — what should an agent be allowed to do? The tool ecosystem determines what an agent can accomplish — more tools means more capability, which means more risk.
Try it yourself — Your tool permission matrix
For your agent, define access levels. Any tool without clear permission and approval is a governance gap.
| Tool | Should agent have access? | Read only or read/write? | Approval needed? |
|---|---|---|---|
| e.g. Customer database | Yes | Read only | No |
| e.g. Email system | Yes | Read/write | Yes — for sending |
Memory — what agents remember
Without memory, every interaction starts from zero. With memory, agents can build on previous work, learn from experience, and maintain continuity.
Agent memory operates at four levels:
flowchart TD
MEM["Agent Memory"]
MEM --> SHORT["Short-term\nCurrent conversation context"]
MEM --> RAG["RAG\nRetrieve relevant knowledge\nfrom external sources"]
MEM --> LONG["Long-term\nPersistent knowledge base"]
MEM --> EPISODIC["Episodic\nRecords of past actions and outcomes"]
| Type | Scope | Duration | Example |
|---|---|---|---|
| Short-term | Current task | Session | "I've already gathered 3 of 5 data points" |
| RAG | External knowledge | On-demand | "Retrieve relevant policy documents" |
| Long-term | Cross-session | Persistent | "This user prefers detailed technical answers" |
| Episodic | Specific events | Persistent | "Last time this query was run, the API returned an error" |
RAG — Retrieval-Augmented Generation — is the pattern where agents retrieve relevant information from external sources and inject it into their context before generating a response. This grounds the agent in real, current data rather than relying solely on training data.
flowchart LR
QUERY["User Query"] --> EMBED["Embed\nConvert to vector"]
EMBED --> SEARCH["Search\nVector database"]
SEARCH --> RETRIEVE["Retrieve\nRelevant chunks"]
RETRIEVE --> INJECT["Inject\nInto LLM context"]
INJECT --> GENERATE["Generate\nGrounded response"]
Without short-term memory, agents repeat work and lose context. Without long-term memory, they can't learn from experience. Without episodic memory, they repeat mistakes. Memory is the difference between a tool and a teammate.
Try it yourself — Your memory design
For your agent, define what to remember and for how long. Any privacy concern flagged means you need data governance review before implementing that memory type.
| Memory type | What should it remember? | How long should it persist? | Privacy concern? |
|---|---|---|---|
| Short-term | Current task progress | This session only | Low |
| RAG | Company policies, procedures | As long as documents are valid | Medium — access control |
| Long-term | User preferences | Indefinitely | High — consent needed |
| Episodic | Past actions, errors | Until superseded | Medium — audit trail |
Multi-agent systems
Complex tasks often require multiple skills — research, analysis, writing, coding. No single agent excels at everything. Multi-agent systems divide work among specialised agents.
flowchart TD
GOAL["Complex Goal"] --> ORCH["Orchestrator\nDecomposes goal,\nassigns to specialists"]
ORCH --> A1["Research Agent\nGathers information"]
ORCH --> A2["Analysis Agent\nProcesses data"]
ORCH --> A3["Writing Agent\nCreates output"]
ORCH --> A4["Review Agent\nChecks quality"]
A1 --> SYNTH["Synthesis\nCombine results"]
A2 --> SYNTH
A3 --> SYNTH
A4 --> SYNTH
SYNTH --> FINAL["Final Output"]
| Pattern | How it works | Best for |
|---|---|---|
| Orchestrator | One agent coordinates, others execute | Complex tasks with clear sub-tasks |
| Pipeline | Agents work sequentially, each adding value | Workflows with distinct stages |
| Debate | Agents argue different perspectives | Decision-making, quality assurance |
| Swarm | Agents self-organise around goals | Dynamic, unpredictable environments |
| A2A Network | Agents discover and call each other via A2A | Cross-organisational collaboration |
Multi-agent systems mirror organisational structures — specialised roles, coordination, communication. The orchestrator role is analogous to a project manager. Governance becomes more complex — who is accountable when multiple agents collaborate?
Try it yourself — Do you need multi-agent?
If you answered "yes" to two or more, multi-agent may help. If "no" to most, start with a single agent.
| Question | Answer |
|---|---|
| Does the task require multiple distinct skills? | |
| Can one agent handle all the tools needed? | |
| Would parallel processing speed things up? | |
| Do different parts need different reasoning patterns? |
Governance — controlling agents
The more autonomous an agent is, the more important governance becomes. An agent that can take actions can also take wrong actions — at scale, at speed, without human review.
flowchart TD
GOV["Agent Governance"]
GOV --> G1["Permissions\nWhat can the agent do?"]
GOV --> G2["Oversight\nWho watches the agent?"]
GOV --> G3["Guardrails\nWhat stops the agent?"]
G1 --> P1["Tool access · Data access · Action scope"]
G2 --> O1["Human review · Logging · Monitoring"]
G3 --> R1["Rate limits · Kill switches · Approval gates"]
| Level | Control | Example |
|---|---|---|
| Permissions | Define what tools and data the agent can access | Agent can read files but not delete them |
| Oversight | Monitor what the agent is doing in real-time | Dashboard showing current actions |
| Guardrails | Hard limits that stop the agent | Rate limits, approval gates, kill switches |
| Accountability | Clear human ownership of agent actions | Every agent has a named human owner |
Agent governance extends the Responsible AI principles to autonomous systems. The Agency mode from the AI Fluency framework is where agents operate — and where diligence is most critical. Accountability is non-negotiable: the agent cannot be held responsible. The human owner can.
Try it yourself — Your agent governance checklist
For your agent design. Any "no" is a deployment blocker.
| Governance item | Done? | Owner |
|---|---|---|
| Named human owner assigned | ||
| Tool permissions defined and documented | ||
| Kill switch tested and functional | ||
| All actions logged and auditable | ||
| Incident response plan covers agent failures | ||
| Rate limits and approval gates in place |
The agent architecture in one diagram
flowchart TD
GOAL["Goal"] --> LOOP["Agent Loop\nObserve → Orient → Decide → Act"]
LOOP --> TOOLS["Tools\nHands to act with"]
TOOLS --> MEMORY["Memory\nContext to build on"]
MEMORY --> MULTI["Multi-Agent\nSpecialised collaboration"]
MULTI --> GOV["Governance\nPermissions, oversight, guardrails"]
The short version:
Agents follow goals, not rules — and that shift from "do this step" to "achieve this outcome" is what changes what AI can do for you. Everything else — protocols, guardrails, accountability — follows from that single change in how you think about what the system is for.
Cheat sheet — all the key terms
| Term | Plain English | Where it fits |
|---|---|---|
| AI Agent | Goal-driven AI that plans, acts, and uses tools | Beyond chatbots |
| Agent loop | Observe → Orient → Decide → Act | How agents work |
| ReAct | Reasoning and acting interleaved | The foundation pattern |
| Chain-of-Thought | Step-by-step reasoning before acting | Transparent reasoning |
| Tree-of-Thought | Exploring multiple reasoning paths | Creative problems |
| Plan-and-Execute | Plan first, then execute steps | Complex multi-step tasks |
| Reflection | Generate, evaluate, improve | Quality-critical outputs |
| MCP | Standardised protocol for connecting to tools | Layer 5 — tool interface |
| A2A | Protocol for agent-to-agent communication | Multi-agent coordination |
| Function calling | How LLMs invoke tools natively | The mechanism underneath |
| Tool use | Bridge between thinking and doing | What agents can actually do |
| RAG | Retrieve external knowledge before generating | Grounding in real data |
| Short-term memory | Current conversation context | The session |
| Long-term memory | Persistent knowledge across sessions | Continuity |
| Episodic memory | Records of past actions and outcomes | Learning from experience |
| Multi-agent | Specialised agents working together | Complex tasks |
| Permissions | What the agent is allowed to do | Governance layer 1 |
| Oversight | Monitoring what the agent is doing | Governance layer 2 |
| Guardrails | Hard limits — rate limits, kill switches | Governance layer 3 |
| Accountability | Named human owner for every agent | Non-negotiable |
How to know if this landed
You'll know this has landed when someone can explain the difference between automation and agency using their own example. When they consider an agent use case, they can identify which agentic pattern fits and why. When they understand what MCP does and can describe why it matters without needing the technical detail. When they can describe what A2A enables — and when it's overkill. When their agent design includes a governance framework with permissions, oversight, and a named human owner. When they know when not to use an agent — when traditional automation is the better choice. And when they can explain the agent loop to someone who hasn't read this guide.
What the workshop reveals
The governance conversation is where the most uncomfortable moments happen in this workshop.
People come in excited about what agents can do. They leave understanding what agents can do without asking. The demonstration — watching an agent take an unexpected but technically correct action that would have been a problem in a real context — is the moment the room goes quiet.
That's the right moment. It's not fear. It's clarity. The agent isn't being malicious. It's doing exactly what it was designed to do — pursue a goal with flexibility. The problem is that the goal wasn't specific enough, or the guardrails weren't tight enough, or nobody thought about what "done" actually means.
The MCP conversation lands differently after this session too. Before, people think about agents as custom integrations — build a tool, wire it up, test it, hope it works. After, they understand that MCP is the standard interface. Write a tool once, use it with any MCP-compatible model. The ecosystem argument clicks: organisations that build on these standards today will be ahead as the ecosystem matures.
The multi-agent design exercise is where the most creative thinking happens. Once people understand that agents can specialise — one for research, one for analysis, one for writing, one for review — they start seeing their own workflows differently. The orchestrator pattern maps directly onto how good project managers work. The debate pattern maps onto how good teams make decisions. The technology isn't changing the way people work. It's making visible the patterns that were already there.
Book a Workshop
Ready to explore what AI agents can do for your organisation — safely and strategically?
or
2-day workshop + coaching includes agent architecture and design workshop, agentic patterns selection for your use cases, MCP integration planning for your tool ecosystem, RAG pipeline design for knowledge-grounded agents, multi-agent system design with A2A protocol, governance framework with permissions and oversight, agent readiness assessment, and agent use case prioritisation with roadmap.