RichardHam.co.uk Blog

Tag: agentic

  • Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    The conversation around AI in business has shifted. For the past two years, most organisations have experimented with generative AI as a productivity tool — drafting documents, summarising meetings, answering questions. The model receives input, produces output, and a human reviews the result.

    That is no longer the whole picture.

    Across the organisations I work with, AI is moving from answering questions to taking actions. Agents execute n8n workflows that move data between systems. They trigger Hermes agents that read, write, and decide. They call APIs, update records, send messages, and make operational decisions — sometimes with human approval, sometimes without.

    This is agentic AI: systems that do not just respond, but act. It creates a governance problem that clever prompts alone cannot solve.

    The Governance Gap

    When a human makes a decision in a business process, there is usually a trace. An email sent, a form submitted, a system log entry, a manager’s sign-off. When something goes wrong, you can reconstruct the sequence of events. You can ask: what were they asked to do, what did they do, and why?

    When an AI agent executes an action, that trace often does not exist. The agent receives a prompt, processes it through one or more model calls, and performs an action. If the action is wrong — if it updates the wrong record, sends a message to the wrong person, or executes a workflow it should not have — the organisation is left with a result and no explanation.

    This is not a theoretical risk. In my own infrastructure, I have built agentic workflows that interact with live systems. The difference between a safe deployment and an unsafe one is not the quality of the prompt. It is whether the system logs enough information to reconstruct what happened after the fact.

    What Happens Without Audit Trails

    Without audit trails, three things break down.

    You cannot reconstruct events. If an agent produces an incorrect output or takes an unintended action, you need to know what input it received, which model or tool it called, what intermediate decisions it made, and what action it executed. Without this, debugging is guesswork. You are trying to diagnose a problem without access to the patient’s notes.

    You cannot establish accountability. When an automated system causes harm — a data breach, a financial error, a compliance failure — someone needs to be able to explain what happened. Under UK GDPR, the accountability principle requires organisations to demonstrate compliance, not just claim it. If your AI agent processes personal data and you cannot show what it did with that data, you are not compliant. It does not matter how good the system is in theory.

    You cannot improve the system. Agentic AI systems iterate. You adjust prompts, change tool configurations, add guardrails. Without structured logs of what each execution actually did, you are optimising in the dark.

    What a Practical Audit Trail Looks Like

    An audit trail for an agentic AI system does not need to be complex. It needs to be consistent and complete. At minimum, each agent execution should capture:

    • Input received. What was the agent asked to do? This includes the user’s request, any system context, and the prompt that was constructed.
    • Decision chain. What steps did the agent take? Which tools did it call? What intermediate outputs did it produce? For multi-step agents, this is the sequence of reasoning that led to the final action.
    • Action taken. What did the agent actually do? Which API was called, which record was updated, which message was sent.
    • Output produced. What was the final result returned to the user or passed to the next step in the workflow.
    • Timestamp and identity. When did this happen, and which agent or workflow executed it?

    This is not excessive. It is the same information you would expect from any business system that takes actions on data. The fact that the system is powered by a language model does not change the requirement — it increases it, because the system’s behaviour is less deterministic and harder to predict.

    The Regulatory Dimension

    For UK organisations, this is not optional. UK GDPR Article 5(2) establishes the accountability principle: you must be able to demonstrate that you comply with data protection principles. If an AI agent processes personal data — and most business agents do — you need to show what data it accessed, what it did with that data, and on what basis.

    Article 30 requires records of processing activities. An agent that processes client records, employee data, or customer information is conducting processing activity. If you cannot produce a log of that activity, you do not have the records the regulation requires.

    For financial services firms, the FCA’s operational resilience framework adds another layer. Important business services must withstand disruption and recover. If your AI agents are part of an important business service — processing transactions, managing client communications, monitoring risk — you need to understand how they behave, what they depend on, and what happens when they fail. Audit trails are the evidence base for your resilience assessment.

    How to Implement Audit Trails in Agent Workflows

    The good news is that the tooling exists. You do not need to build this from scratch.

    Structured logging at every node. In n8n workflows, each node can be configured to log its input and output. For agentic workflows, you should log at minimum the trigger, each decision point, and the final action. Use a consistent schema — timestamp, node name, input summary, output summary, and execution status — so that logs are searchable and comparable.

    Observability platforms. Tools like Langfuse are designed for exactly this purpose. They capture the full execution trace of an agent: prompt, model response, tool calls, and final output. When connected to your workflow engine, they give you a queryable record of every agent execution without building custom logging infrastructure.

    Immutable storage. Audit logs must be tamper-evident. If the log can be modified after the fact, it is not an audit trail — it is a diary. Store logs in append-only storage with access controls that prevent modification. This can be as simple as writing to a write-once bucket or using a logging service that enforces retention policies.

    Structured output from agents. Design your agents to return structured output, not just free text. A JSON response that includes the action taken, the target system, and the rationale is far more useful for auditing than a paragraph of prose. This also makes it easier to validate agent behaviour programmatically — you can check that the action taken is within the set of permitted actions before it executes.

    Regular review. Audit trails are only useful if someone looks at them. Build a review cadence — weekly for high-risk agents, monthly for lower-risk ones — where you sample executions and check for anomalies.

    The Bottom Line

    The organisations that will get the most value from agentic AI are not the ones with the most sophisticated prompts. They are the ones that can trust their agents to act safely, verify what those agents did, and improve them over time.

    Audit trails are the foundation of that trust. They are how you move from hoping your agents behave to knowing they do. They are how you satisfy regulators, reassure boards, and sleep at night.

    If you are deploying agentic AI in your organisation — or planning to — audit infrastructure is not a phase-two consideration. It is a prerequisite.

    If you are building agentic AI systems and need help establishing the governance, architecture, and audit infrastructure to support them, the AI & Automation Architecture service covers exactly this. For a broader conversation about where your organisation stands, get in touch.

  • How Multi-Agent Operations Work in Practice

    How Multi-Agent Operations Work in Practice

    Most organisations still treat AI agents like a single chat window with extra buttons. That is fine for a demo. It is not fine when the work touches production systems.

    The difference is operational, not magical. The teams getting value from agents are the ones that add roles, checkpoints, and ownership.

    What works

    A reliable setup usually has four pieces:

    • a coordinator that defines the task and checks the output
    • worker agents that do independent chunks in parallel
    • state that lives somewhere everyone can inspect
    • review points before anything risky moves forward

    That is not glamorous, but it works.

    A simple example

    If three services are acting up at once, a good coordinator breaks the problem apart and sends each service to a separate worker. The workers do not need to talk to each other because the tasks are independent. The coordinator then compares the results and decides whether to approve the fix or escalate.

    That pattern saves time without turning the system into a black box.

    The cost question

    People often assume agent work must be expensive. In practice, the opposite is usually true. The cheap model can do the repetitive work. The better reasoning model is reserved for coordination and review.

    That split matters. It keeps the system affordable and keeps judgment where it belongs.

    What to do first

    1. Decide who owns the outcome.
    2. Identify which tasks can run in parallel.
    3. Make state visible.
    4. Add checkpoints where mistakes would hurt.

    That is enough to get started. The rest is tuning.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • How Multi-Agent Operations Work in Practice

    e

    Most organisations still treat AI agents like a single chat window with extra buttons. That is fine for a demo. It is not fine when the work touches production systems.

    The difference is operational, not magical. The teams getting value from agents are the ones that add roles, checkpoints, and ownership.

    What works

    A reliable setup usually has four pieces:

    • a coordinator that defines the task and checks the output
    • worker agents that do independent chunks in parallel
    • state that lives somewhere everyone can inspect
    • review points before anything risky moves forward

    That is not glamorous, but it works.

    A simple example

    If three services are acting up at once, a good coordinator breaks the problem apart and sends each service to a separate worker. The workers do not need to talk to each other because the tasks are independent. The coordinator then compares the results and decides whether to approve the fix or escalate.

    That pattern saves time without turning the system into a black box.

    The cost question

    People often assume agent work must be expensive. In practice, the opposite is usually true. The cheap model can do the repetitive work. The better reasoning model is reserved for coordination and review.

    That split matters. It keeps the system affordable and keeps judgment where it belongs.

    What to do first

    1. Decide who owns the outcome.
    2. Identify which tasks can run in parallel.
    3. Make state visible.
    4. Add checkpoints where mistakes would hurt.

    That is enough to get started. The rest is tuning.

Powered by