[{"content":"Agent design patterns are reusable architectures for organising an agentic system: how many agents there are, what each does, and who decides what happens next. That last point is the most useful way to tell them apart. In some patterns, code you wrote fixes the order of steps. In others, a model decides at runtime. Model-decided patterns adapt better but cost more calls, tokens and latency.\nChoosing a pattern Start from the requirements, not the pattern:\nTask shape. Are the steps known in advance, or open-ended? Does a model need to direct the work? Latency. Is a fast, interactive response needed, or is a slower, more thorough result acceptable? Cost. Can the budget support several model calls per request? Human judgment. Are some decisions high-stakes, safety-critical or subjective? If the task is predictable or fits in a single model call (summarising, translating, classifying), don\u0026rsquo;t use an agent at all. Otherwise, start with a single agent and add structure only when a requirement forces it. Revisit the choice as the workload changes.\nSynthesis: the guide gives criteria, not a flowchart. This is one way to read them as a decision path:\nflowchart TD A[\u0026#34;New task\u0026#34;] --\u0026gt; B{\u0026#34;Predictable, or one model call?\u0026#34;} B -- yes --\u0026gt; N[\u0026#34;No agent: call the model directly\u0026#34;] B -- no --\u0026gt; C[\u0026#34;Start with a single agent\u0026#34;] C --\u0026gt; D{\u0026#34;Struggling as tools and responsibilities grow?\u0026#34;} D -- no --\u0026gt; K[\u0026#34;Keep the single agent\u0026#34;] D -- \u0026#34;needs constant re-planning\u0026#34; --\u0026gt; R[\u0026#34;ReAct\u0026#34;] D -- \u0026#34;steps known in advance\u0026#34; --\u0026gt; W[\u0026#34;Fixed workflow: sequential, parallel, loop\u0026#34;] D -- \u0026#34;steps depend on the input\u0026#34; --\u0026gt; O[\u0026#34;Model-orchestrated: coordinator, hierarchical, swarm\u0026#34;] C -. \u0026#34;high-stakes decisions\u0026#34; .-\u0026gt; H[\u0026#34;Add human-in-the-loop\u0026#34;] The patterns Single agent One model with a set of tools and a detailed system prompt. It plans and picks tools itself: the plain agent loop.\nUse for: multi-step tasks needing external data, and as the first version of any agent. Watch for: quality drops (wrong tool choice, failures, latency) as tools and responsibilities grow. That\u0026rsquo;s the signal to move to ReAct or multi-agent. flowchart LR U[\u0026#34;Request\u0026#34;] --\u0026gt; A[\u0026#34;Agent \u0026#43; system prompt\u0026#34;] A \u0026lt;--\u0026gt; T[\u0026#34;Tools\u0026#34;] A --\u0026gt; F[\u0026#34;Answer\u0026#34;] ReAct (reason and act) A single agent that cycles explicitly through Thought (reason about the next step), Action (call a tool or answer) and Observation (record the result), until it reaches an answer, an iteration limit or an error.\nUse for: dynamic tasks that need continual re-planning. Trade-off: cheaper than multi-agent, and the reasoning trace helps debugging. But the loop adds latency, quality depends on the model\u0026rsquo;s reasoning, and one bad tool result can mislead the final answer. flowchart LR Q[\u0026#34;Request\u0026#34;] --\u0026gt; T[\u0026#34;Thought\u0026#34;] --\u0026gt; A[\u0026#34;Action: call a tool\u0026#34;] --\u0026gt; O[\u0026#34;Observation\u0026#34;] --\u0026gt; T T -- \u0026#34;answer ready\u0026#34; --\u0026gt; F[\u0026#34;Final answer\u0026#34;] Fixed workflows (code decides the order) These subagent arrangements use predefined control flow with no model orchestration. They\u0026rsquo;re cheaper, faster and predictable, but rigid.\nPattern Shape Use for Watch for Sequential A → B → C; each output feeds the next Structured, repeatable pipelines (extract → clean → load) Can\u0026rsquo;t skip unneeded steps Parallel Fan out to agents running at once, then merge Independent sub-tasks, or gathering several views quickly Higher burst cost; merging conflicting results is hard Loop Repeat a sequence until an exit condition Polling, self-correction A bad exit condition means runaway cost Sequential\nflowchart LR I[\u0026#34;Input\u0026#34;] --\u0026gt; A[\u0026#34;Agent A\u0026#34;] --\u0026gt; B[\u0026#34;Agent B\u0026#34;] --\u0026gt; C[\u0026#34;Agent C\u0026#34;] --\u0026gt; O[\u0026#34;Output\u0026#34;] Parallel\nflowchart LR I[\u0026#34;Input\u0026#34;] --\u0026gt; A[\u0026#34;Agent A\u0026#34;] \u0026amp; B[\u0026#34;Agent B\u0026#34;] \u0026amp; C[\u0026#34;Agent C\u0026#34;] A \u0026amp; B \u0026amp; C --\u0026gt; M[\u0026#34;Merge\u0026#34;] --\u0026gt; O[\u0026#34;Output\u0026#34;] Loop\nflowchart LR I[\u0026#34;Input\u0026#34;] --\u0026gt; A[\u0026#34;Agent A\u0026#34;] --\u0026gt; B[\u0026#34;Agent B\u0026#34;] --\u0026gt; X{\u0026#34;Exit condition met?\u0026#34;} X -- no --\u0026gt; A X -- yes --\u0026gt; O[\u0026#34;Output\u0026#34;] Two loop variants focus on output quality:\nReview and critique (generator–critic): a generator drafts and a critic checks the draft against criteria (accuracy, format, safety), then approves it or sends it back. An example is a code generator paired with a security-auditor critic that runs tests. This is verification built into the architecture. Iterative refinement: one or more agents improve a shared result over several passes until it meets a quality bar or hits an iteration limit. Good for drafting, planning and debugging code. Review and critique\nflowchart LR R[\u0026#34;Request\u0026#34;] --\u0026gt; G[\u0026#34;Generator\u0026#34;] --\u0026gt; D[\u0026#34;Draft\u0026#34;] --\u0026gt; C{\u0026#34;Critic: meets criteria?\u0026#34;} C -- \u0026#34;no, with feedback\u0026#34; --\u0026gt; G C -- yes --\u0026gt; O[\u0026#34;Output\u0026#34;] Dynamic orchestration (a model decides) Pattern Shape Use for Watch for Coordinator A model routes each request to specialist agents Varied inputs to a structured process (e.g. support: status, return, or refund) Extra calls for every routing decision Hierarchical decomposition A root agent splits the task, sub-agents split further, workers execute Ambiguous, open-ended work (research, planning) Hard to design and debug; nested calls make it slow and costly Swarm Agents talk all-to-all, critique and hand off, with no central supervisor Very complex problems that benefit from debate The most complex and costly pattern; needs exit conditions to converge Coordinator\nflowchart TD R[\u0026#34;Customer request\u0026#34;] --\u0026gt; C[\u0026#34;Coordinator: a model picks the route\u0026#34;] C --\u0026gt; A[\u0026#34;Order status agent\u0026#34;] C --\u0026gt; B[\u0026#34;Returns agent\u0026#34;] C --\u0026gt; D[\u0026#34;Refunds agent\u0026#34;] Hierarchical decomposition\nflowchart TD R[\u0026#34;Root agent: research project\u0026#34;] --\u0026gt; G[\u0026#34;Gather\u0026#34;] R --\u0026gt; N[\u0026#34;Analyse\u0026#34;] R --\u0026gt; W[\u0026#34;Write report\u0026#34;] G --\u0026gt; G1[\u0026#34;Worker\u0026#34;] G --\u0026gt; G2[\u0026#34;Worker\u0026#34;] N --\u0026gt; N1[\u0026#34;Worker\u0026#34;] N --\u0026gt; N2[\u0026#34;Worker\u0026#34;] Swarm\nflowchart LR U[\u0026#34;Request\u0026#34;] --\u0026gt; D[\u0026#34;Dispatcher\u0026#34;] D \u0026lt;--\u0026gt; M[\u0026#34;Market research\u0026#34;] D \u0026lt;--\u0026gt; E[\u0026#34;Engineering\u0026#34;] D \u0026lt;--\u0026gt; F[\u0026#34;Finance\u0026#34;] M \u0026lt;--\u0026gt; E E \u0026lt;--\u0026gt; F F \u0026lt;--\u0026gt; M Special requirements Human-in-the-loop: the agent pauses at set checkpoints for a person to approve, correct or add input. An example is a compliance officer approving a redacted dataset before release. It\u0026rsquo;s one of the strongest guardrails, at the cost of building the review system. Custom logic: your own code branches between other patterns. For example, a refund agent runs parallel checks, then branches to either a refund or a sequential store-credit flow. This is the most flexible option, but also the most work to build and maintain. Human-in-the-loop\nflowchart LR A[\u0026#34;Agent works\u0026#34;] --\u0026gt; C{\u0026#34;Checkpoint\u0026#34;} --\u0026gt; H[\u0026#34;Human reviews\u0026#34;] H -- approve --\u0026gt; N[\u0026#34;Agent continues\u0026#34;] H -- \u0026#34;correct or add input\u0026#34; --\u0026gt; A Custom logic (the refund example)\nflowchart TD Q[\u0026#34;Refund request\u0026#34;] --\u0026gt; C[\u0026#34;Coordinator: custom code\u0026#34;] C --\u0026gt; V[\u0026#34;In parallel: verify purchaser, check eligibility\u0026#34;] V --\u0026gt; E{\u0026#34;Eligible?\u0026#34;} E -- yes --\u0026gt; P[\u0026#34;Refund processor\u0026#34;] E -- no --\u0026gt; S[\u0026#34;Store-credit flow, sequential\u0026#34;] P --\u0026gt; F[\u0026#34;Response agent\u0026#34;] S --\u0026gt; F Cross-cutting concerns Cost and latency grow with every added agent, loop or cycle. Most patterns trade extra model calls for quality. Exit conditions are mandatory for loop, refinement and swarm patterns: an iteration cap, a time limit or a goal. Context per agent. Isolate it, persist what later steps need, and compress large data. See context engineering. Synthesis: the patterns compose. Real systems often nest them, for example a coordinator whose specialists run sequential or generator–critic loops. The custom-logic pattern is the general case of that. Sources Choose a design pattern for your agentic AI system (Google Cloud): all 12 patterns, selection criteria and trade-offs The Anatomy of a Modern AI Agent: the single agent loop and subagent trade-offs ","permalink":"https://coolloic.github.io/blog/wiki/concepts/agent-design-patterns/","summary":"Reusable architectures for arranging one or many agents, and how to choose between them.","title":"Agent design patterns"},{"content":"Agent guardrails are the limits on what an agent is allowed to do. The more capable an agent is, the more they matter. Good guardrails are what let autonomy increase over time instead of requiring step-by-step supervision.\nLayers Sandboxing. Run code in isolated environments (containers, microVMs) so mistakes stay contained. Permissions. Read-only actions run freely. Writes, deletions and anything public-facing need approval or an explicit policy. See tools. Treating inputs as data. Web pages, emails, tool results and MCP responses can contain text that looks like instructions. An agent that obeys what it reads is open to prompt injection. Fetched content should inform the agent, never command it. Human-in-the-loop At predefined checkpoints the agent pauses for a person to approve, correct or supply input. This is the standard choice for high-stakes, safety-critical or subjective decisions, such as approving the release of a redacted health dataset. It improves safety at the cost of building and maintaining the review system (Google Cloud).\nFor multi-agent systems, the same guide recommends controlling agent traffic, giving each agent least-privilege identity, and registering trusted tools and subagents. It names Google products for each of these.\nRelated Agent loop: the harness that runs the loop is where guardrails are enforced.\nSources The Anatomy of a Modern AI Agent Choose a design pattern for your agentic AI system (Google Cloud) ","permalink":"https://coolloic.github.io/blog/wiki/concepts/agent-guardrails/","summary":"Sandboxing, permissions and input handling that bound what an agent can do.","title":"Agent guardrails"},{"content":"The agent loop is the minimal structure that makes a language model an agent. The model is called repeatedly. Each turn it either asks for one or more tool calls, which the harness executes and appends to the conversation, or it answers without calling a tool, which ends the loop.\nwhile True: response = model.generate(messages, tools=tools) messages.append(response) if not response.tool_calls: return response.text for call in response.tool_calls: messages.append(run(call)) Key properties No hard-coded control flow. There is no separate planner or state machine. The model decides each next step. The harness only executes. It runs the requested tools, returns results, and enforces guardrails. Quality lives outside the loop. How well the model chooses depends on its tools, its context (context engineering) and its ability to check results (verification). Contradiction: The Anatomy of a Modern AI Agent says agents have no hard-coded control flow. Google Cloud\u0026rsquo;s pattern guide treats predefined workflows (sequential, parallel, loop) as legitimate agent patterns that are cheaper and more predictable than letting a model decide. Synthesis: the open loop described here is the model-orchestrated case. Fixed workflows wrap agents in code-driven control flow. See agent design patterns.\nReAct is a named form of this loop in which the model explicitly writes a Thought before each Action and records each Observation. This makes its reasoning traceable, at the cost of latency.\nRelated Tools · Subagents, which nest the loop inside itself\nSources The Anatomy of a Modern AI Agent Choose a design pattern for your agentic AI system (Google Cloud) ","permalink":"https://coolloic.github.io/blog/wiki/concepts/agent-loop/","summary":"The core of every AI agent: a model choosing actions in a loop until the task is done.","title":"Agent loop"},{"content":"Context engineering is the practice of controlling what is in an agent\u0026rsquo;s context window at each step: system prompt, tool definitions, conversation history and tool results. The window is finite, and models use information less well as it fills with noise. Managing context is arguably the most important skill in building agents.\nTechniques Load on demand. Give the agent search and read tools rather than pre-loading documents. This is how coding agents work in codebases far larger than their window. Keep tool output lean. Summarise, paginate and truncate. A 50,000-line log dump wastes context. Compact long sessions. Near the limit, replace the history with a summary that keeps decisions and open threads. Write things down. Notes in files (plans, progress logs, to-do lists) let an agent recover its state after a reset or compaction. Delegate. Subagents do context-heavy work in a fresh window and return only a summary. In multi-agent systems the same principles apply per agent: isolate each agent\u0026rsquo;s context, persist what later steps need, and compress large data before passing it on (Google Cloud).\nRelated Agent loop\nSources The Anatomy of a Modern AI Agent Choose a design pattern for your agentic AI system (Google Cloud) ","permalink":"https://coolloic.github.io/blog/wiki/concepts/context-engineering/","summary":"Deciding what goes into an agent\u0026rsquo;s finite context window, and when.","title":"Context engineering"},{"content":"Welcome to my new blog! This is a sample post. Edit or delete it, then write your own.\nHow this blog works Each post is a Markdown file in content/posts/. Create a new one with:\nhugo new content posts/my-next-post.md New posts start as drafts. Set draft: false when you\u0026rsquo;re ready to publish.\nFormatting You get bold, italics, links, lists, tables, and code:\ndef greet(name: str) -\u0026gt; str: return f\u0026#34;Hello, {name}!\u0026#34; Feature Supported Dark mode ✅ Search ✅ RSS ✅ ","permalink":"https://coolloic.github.io/blog/posts/hello-world/","summary":"The first post on this blog: what it is and how it\u0026rsquo;s built.","title":"Hello, World"},{"content":"The Model Context Protocol (MCP) is an open standard for connecting agents to external capabilities. A service runs an MCP server that exposes tools, resources and prompts once, and any MCP-compatible agent (the client) can use them.\nWhy it matters Before MCP, every agent framework had its own tool format, so each integration was rebuilt for each framework. With MCP, an integration is built once and reused everywhere. The source compares this to USB for hardware: standardise the plug and the ecosystem grows on its own. In practice, connecting an agent to an issue tracker, documentation or a database is often configuration rather than custom code. Related Tools · Agent guardrails: content returned by MCP servers is data, not instructions.\nSources The Anatomy of a Modern AI Agent ","permalink":"https://coolloic.github.io/blog/wiki/concepts/model-context-protocol/","summary":"Open standard for exposing tools, resources and prompts to any compatible agent.","title":"Model Context Protocol (MCP)"},{"content":"What I\u0026rsquo;m focused on at the moment. Last updated November 13, 2026.\nThis blog A home for technical writing on cutting-edge AI: models, agents, tooling, and what I learn building with them.\nSource: github.com/coolloic/blog Built with: Hugo and the PaperMod theme, deployed to GitHub Pages with GitHub Actions Status: just launched 🚀 ","permalink":"https://coolloic.github.io/blog/now/","summary":"What I\u0026rsquo;m working on right now.","title":"Now"},{"content":" What: architecture guide, Google Cloud Architecture Center Author: Samantha He (Technical Writer, Google Cloud), with 16 Google contributors Date: not shown on the page (read 2026-11-13) Original: docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system Summary The guide catalogues reusable architectures for agentic systems and gives a three-step way to choose one: define requirements, review the patterns, then match the pattern to the workload. It covers a single-agent baseline, eight multi-agent patterns, ReAct, human-in-the-loop and custom logic. Its central advice is to start with one agent and add structure only when a requirement demands it. Implementation pointers are Google-specific (ADK, Cloud Run, Agent Gateway/Identity/Registry), but the patterns themselves are general.\nKey claims Choose a pattern by four requirements: task characteristics (fixed steps or open-ended), latency, cost budget, and the need for human judgment. Tasks that are predictable or need a single model call (summarise, translate, classify) are often better served without agents. Start with a single agent. Its performance degrades as tools and responsibilities grow, and that is the signal to consider ReAct or multi-agent. Workflow patterns (sequential, parallel, loop) use predefined control flow with no model orchestration, which makes them cheaper and faster but rigid. Model-orchestrated patterns (coordinator, hierarchical decomposition, swarm) adapt at runtime but cost more calls, tokens and latency. Swarm is the most complex and costly. Loop and swarm patterns need explicit exit conditions, or they risk runaway cost and non-convergence. Every agent needs well-managed context: isolate it per agent, persist it across steps, compress large data. Human-in-the-loop improves safety at critical points but requires building an external review system. No evaluation guidance is given. Feeds Agent design patterns · Agent loop · Subagents · Context engineering · Verification and evals · Agent guardrails\n","permalink":"https://coolloic.github.io/blog/wiki/sources/google-cloud-choose-agentic-design-pattern/","summary":"Google Cloud Architecture Center guide to 12 agent design patterns and how to choose between them.","title":"Source: Choose a design pattern for your agentic AI system (Google Cloud)"},{"content":" What: blog post on this site Author: Loic Date: 2026-11-13 Original: The Anatomy of a Modern AI Agent Summary The post argues that an AI agent is, at its core, a language model running in a loop that picks actions and sees their results. The loop itself is simple. What separates a reliable agent from a demo is the engineering around it: tool design, context management, delegation, verification and guardrails.\nKey claims An agent is an LLM in a loop: generate, execute the requested tool calls, append the results, repeat until the model stops calling tools. Tool quality depends on interface design (name, description, schema). Overlapping tools cause wrong choices. MCP standardises how tools are exposed, so integrations are built once and reused by any compatible agent. Context is finite, and models degrade as it fills with noise. \u0026ldquo;Context engineering\u0026rdquo; (on-demand loading, lean tool output, compaction, written notes) is the key skill. Subagents give sub-tasks a fresh context and return summaries. That\u0026rsquo;s worth it only when the sub-tasks are independent, because handoffs are lossy and cost tokens. Agents need feedback that comes from outside the model (tests, screenshots, citations). Builders need evals. Guardrails (sandboxing, permissions, treating fetched content as data) are what allow autonomy to grow safely. Feeds Agent loop · Tools · Model Context Protocol · Context engineering · Subagents · Verification and evals · Agent guardrails\n","permalink":"https://coolloic.github.io/blog/wiki/sources/anatomy-of-a-modern-ai-agent/","summary":"Blog post mapping an AI agent as a loop plus tools, context, delegation, verification and guardrails.","title":"Source: The Anatomy of a Modern AI Agent"},{"content":"Subagents are agents started by a main agent to handle a focused sub-task, each in its own fresh context window. Each one runs its own agent loop and returns a summary, not its full transcript.\nTrade-offs Benefit: clean context. A subagent can read hundreds of files and return a few paragraphs, which keeps the main agent\u0026rsquo;s window clear. This is a context engineering technique as much as a way to run work in parallel. Benefit: parallelism. Independent sub-tasks such as search, implementation and review can run at the same time. Cost: lossy handoffs. A subagent knows only what its brief says, and the main agent sees only the summary. Cost: tokens. Each subagent pays for its own context. Rule of thumb: delegate when sub-tasks are truly independent. Otherwise the overhead outweighs the gain. Arrangements How subagents are wired together is an architectural choice. It can be a fixed order (sequential, parallel or loop), routing by a coordinator model, multi-level hierarchical decomposition, or an all-to-all swarm. Google\u0026rsquo;s guide advises starting with a single agent and moving to multi-agent only when one agent must juggle several distinct responsibilities. See agent design patterns.\nRelated Verification and evals, where independent reviewer subagents are a common use.\nSources The Anatomy of a Modern AI Agent Choose a design pattern for your agentic AI system (Google Cloud) ","permalink":"https://coolloic.github.io/blog/wiki/concepts/subagents/","summary":"Delegating focused sub-tasks to agents with fresh context windows.","title":"Subagents"},{"content":"\u0026ldquo;Agent\u0026rdquo; is one of the most overloaded words in tech right now. Chatbots, workflow builders and coding assistants are all called agents. Under the marketing, though, the systems that actually work share a small, surprisingly simple core. Almost all of the interesting engineering happens around that core.\nThis post is my attempt to map it out: what an agent is, the pieces it\u0026rsquo;s made from, and the problems that separate a demo from something you\u0026rsquo;d trust with real work.\nAn agent is a loop The simplest useful definition: an agent is a language model running in a loop, choosing actions and seeing their results until the task is done.\ndef run_agent(task: str, tools: dict, model) -\u0026gt; str: messages = [{\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: task}] while True: response = model.generate(messages, tools=list(tools.values())) messages.append(response.as_message()) if not response.tool_calls: # model decided it\u0026#39;s done return response.text for call in response.tool_calls: # execute what it asked for result = tools[call.name].run(**call.arguments) messages.append(tool_result(call.id, result)) That\u0026rsquo;s it. No planner module and no hard-coded state machine. The model decides what to do next, the harness carries it out, and the result goes back into the conversation. Every serious agent system has this loop at its centre.\nThe loop isn\u0026rsquo;t the hard part. The hard part is everything that decides whether the model makes good choices inside it.\n1. Tools: how the agent touches the world A model on its own can only produce text. Tools turn that text into actions: reading files, running commands, querying databases, calling APIs.\nTwo lessons keep coming up:\nTool design is interface design. The model only knows a tool through its name, description and parameter schema. Vague descriptions get vague usage. A good tool reads like a well-written function signature with a docstring a new colleague could follow. Fewer, sharper tools beat many overlapping ones. If two tools could plausibly do the same job, the model will sometimes pick the wrong one. Consolidate. MCP: a standard plug for tools For a long time every agent framework had its own way to define tools, so every integration was rebuilt for every framework. The Model Context Protocol (MCP) fixes this with an open standard. A service exposes its tools, resources and prompts once, as an MCP server, and any MCP-compatible agent can use them.\nIt\u0026rsquo;s the same move USB made for hardware: agree on the plug, and the ecosystem builds itself. In practice, connecting an agent to your issue tracker, docs or database is now often a matter of configuration rather than custom code.\n2. Context: the agent\u0026rsquo;s working memory Everything the agent knows at a given step is in its context window: the system prompt, the tool definitions, the conversation so far and every tool result. That window is finite. More importantly, models get worse at using information as the window fills with noise.\nThis has given rise to what people now call context engineering, the discipline of deciding what goes into the window and when:\nLoad on demand, don\u0026rsquo;t pre-load. Instead of stuffing every document into the prompt, give the agent tools to search and read, and let it pull in what it needs. This is how coding agents work across codebases far larger than any context window. Keep tool output lean. A tool that returns 50,000 lines of logs burns context. Return summaries, paginate and truncate sensibly. Compact long sessions. When a long-running task nears the limit, summarise the history and carry on from the summary, keeping decisions and open threads and dropping the raw transcripts. Write things down. Agents that keep notes in files (plans, progress logs, to-do lists) can recover their state after a reset, much as a person picks up their notebook the next morning. If I had to name the single skill that most separates good agent builders from struggling ones, it would be this one.\n3. Subagents: divide and delegate A single loop with one growing context eventually hits a ceiling. The current answer is delegation: a main agent hands focused sub-tasks to subagents, each with a fresh context window.\n┌──────────────┐ │ Main agent │ ← holds the goal and the plan └──────┬───────┘ ┌────────────┼────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌──────────┐ ┌──────────┐ │ Search │ │ Implement│ │ Review │ ← each starts clean, │ subagent│ │ subagent │ │ subagent │ returns only a summary └─────────┘ └──────────┘ └──────────┘ The benefit isn\u0026rsquo;t just doing work in parallel. Each subagent can read hundreds of files and send back three paragraphs, so the main agent\u0026rsquo;s context stays clean. The cost is real too: every handoff is lossy, and subagents burn tokens. Delegation pays off when sub-tasks are genuinely independent. Otherwise it adds overhead.\n4. Verification: closing the loop on quality Models are confident, which is not the same as correct. The agents that work well have ways to check their own work against reality:\nCoding agents run the tests, the type checker and the linter, and read the errors. Browser agents take screenshots and look at what actually rendered. Research agents cite sources and re-read them. The pattern is the same everywhere: give the agent a feedback signal that doesn\u0026rsquo;t come from the model itself. An agent that can run the tests will fix its own bugs. An agent that can\u0026rsquo;t will ship them confidently.\nThe same idea applies one level up, to you as the builder. You need evals: a set of realistic tasks with checkable outcomes, run every time you change a prompt, tool or model. Without them, every change is a guess.\n5. Guardrails: autonomy with boundaries The more an agent can do, the more it matters what it\u0026rsquo;s allowed to do. Production agents typically layer:\nSandboxing: run code in isolated environments (containers, microVMs) so mistakes stay contained. Permissions: read-only actions run freely, while writes, deletions and anything public-facing need approval or explicit policy. Treating inputs as data: web pages, emails and tool results can contain text that looks like instructions. An agent that obeys whatever it reads is vulnerable to prompt injection. Content the agent fetches should inform it, never command it. Getting these boundaries right is what lets you raise autonomy over time instead of babysitting every step.\nPutting it together A modern agent, then, is:\nLayer Question it answers The loop What should I do next? Tools / MCP What can I act on? Context What do I know right now, and what can I drop? Subagents What can I hand off? Verification How do I know it worked? Guardrails What am I allowed to do? The model keeps getting better, and every improvement makes the loop more capable for free. But the gap between an impressive demo and a reliable system is almost entirely in the other five rows. That\u0026rsquo;s where I plan to spend my time, and where future posts on this blog will dig in.\nIf you\u0026rsquo;re building agents too, I\u0026rsquo;d love to hear what\u0026rsquo;s working for you and what isn\u0026rsquo;t. Find me on GitHub.\n","permalink":"https://coolloic.github.io/blog/posts/anatomy-of-an-ai-agent/","summary":"Strip away the hype and an AI agent is a loop, some tools, and a lot of careful context management. Here\u0026rsquo;s how the pieces fit together and where the real engineering lives.","title":"The Anatomy of a Modern AI Agent"},{"content":"Tools are functions the harness exposes to the model, each with a name, a description and a parameter schema. They are the only way an agent loop affects anything outside the model: reading files, running commands, querying data, calling APIs.\nDesign principles Tool design is interface design. The model knows a tool only through its name, description and schema. Vague descriptions produce vague usage. Write them like a docstring for a new colleague. Fewer, sharper tools. Overlapping tools make the model pick the wrong one some of the time. Consolidate them. Lean output. Tool results go into the context window, so large outputs crowd out what matters. See context engineering. Risk varies by tool. Read-only tools can run freely, while writes and outward-facing actions need guardrails. Related Model Context Protocol, a standard way to expose tools to any agent.\nSources The Anatomy of a Modern AI Agent ","permalink":"https://coolloic.github.io/blog/wiki/concepts/tools/","summary":"Functions an agent can call to act on the world; their design is interface design for a model.","title":"Tools"},{"content":"Verification gives an agent a feedback signal that doesn\u0026rsquo;t come from the model itself, so it can check its work against reality. Evals do the same for the people building the agent.\nFor the agent Models are confident, which is not the same as correct. Effective agents check their output:\nCoding agents run tests, type checkers and linters, and read the errors. Browser agents take screenshots of what actually rendered. Research agents cite sources and re-read them. An agent that can run the tests fixes its own bugs. One that can\u0026rsquo;t ships them confidently.\nFor the builder Evals are a set of realistic tasks with checkable outcomes, run every time a prompt, tool or model changes. Without them, every change is a guess.\nAs architecture The review-and-critique (generator–critic) pattern builds verification into the system: a separate critic agent checks output against criteria, or runs tests, before it\u0026rsquo;s accepted. Each revision cycle costs another model call. See agent design patterns.\nNote: the Google Cloud pattern guide gives no evaluation guidance, so builder-side evals still rest on the agents post.\nRelated Agent loop · Subagents\nSources The Anatomy of a Modern AI Agent Choose a design pattern for your agentic AI system (Google Cloud) ","permalink":"https://coolloic.github.io/blog/wiki/concepts/verification-and-evals/","summary":"Feedback from outside the model, for the agent at runtime and for the builder over time.","title":"Verification and evals"},{"content":"Hi, I\u0026rsquo;m Loic. Write a few lines about yourself here.\n","permalink":"https://coolloic.github.io/blog/about/","summary":"\u003cp\u003eHi, I\u0026rsquo;m Loic. Write a few lines about yourself here.\u003c/p\u003e","title":"About"},{"content":"Format: YYYY-MM-DD · ingest|query|lint · summary\n2026-11-13 · ingest · The Anatomy of a Modern AI Agent (blog post) → 1 source, 7 concepts (created 8, updated 0) 2026-11-13 · ingest · Choose a design pattern for your agentic AI system (Google Cloud) → 1 source, 6 concepts (created 2, updated 5); 1 contradiction flagged on agent-loop ","permalink":"https://coolloic.github.io/blog/wiki/log/","summary":"Every ingest, query and lint run on this wiki, newest last.","title":"Log"}]