<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[dev-ai-agents]]></title><description><![CDATA[dev-ai-agents]]></description><link>https://dev-ai-agents.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Sat, 14 Nov 2026 19:24:25 GMT</lastBuildDate><atom:link href="https://dev-ai-agents.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Who answers for it? The Ambassador Agent pattern]]></title><description><![CDATA[A design pattern for agents that act on systems you do not own. Your agent called a partner's API twice. The first call timed out, the model tried again…]]></description><link>https://dev-ai-agents.hashnode.dev/who-answers-for-it-the-ambassador-agent-pattern</link><guid isPermaLink="true">https://dev-ai-agents.hashnode.dev/who-answers-for-it-the-ambassador-agent-pattern</guid><category><![CDATA[ai agents]]></category><category><![CDATA[software architecture]]></category><category><![CDATA[design patterns]]></category><dc:creator><![CDATA[bassem zohdy]]></dc:creator><pubDate>Fri, 13 Nov 2026 11:58:43 GMT</pubDate><content:encoded><![CDATA[<p><em>A design pattern for agents that act on systems you do not own.</em></p>
<h2>Key takeaways</h2>
<ul>
<li>Tool protocols tell an agent how to call an external system. They do not say who is responsible once it does. The Ambassador Agent pattern gives every external boundary one accountable, autonomous owner.</li>
<li>The definition is small: one concept, one interaction model, one reliability rule and seven duties.</li>
<li>Only the core system opens a task, a task never pauses, and it always ends in one of four outcomes: succeeded, failed, rejected or unknown.</li>
<li>One rule keeps the ambassador honest about what it does not know: record the intent before the action, and the outcome after. It does not promise exactly-once effects. It says which of three delivery classes each capability has.</li>
<li>The pattern borrows from the outbox, the saga and the actor model, uses A2A as its reference protocol, and adopts none of them as is. It is a proposal with open questions, listed at the end.</li>
</ul>
<h2>The problem</h2>
<p>Your agent called a partner's API twice. The first call timed out, the model tried again, and both went through. Which agent owned that action?</p>
<p>In most agentic systems today the honest answer is "none of them".</p>
<p>We have good answers to <em>how</em> an agent reaches an external system. Tool protocols made that easy. We have a much weaker answer to <em>who is responsible</em> once it does. On an integration platform with dozens of external systems, that gap shows up in four ways:</p>
<ol>
<li>Vendor field names and error codes leak into prompts, so every agent has to learn every vendor.</li>
<li>Side effects have no single owner, so duplicates and half-finished actions slip by.</li>
<li>Free text returned by an external system lands in the context of an agent that holds real authority.</li>
<li>Every agent handles outages and overload its own way.</li>
</ol>
<p>The setting is an integration platform: a stable core system of agents and workflows that must act on, and hear from, many external systems it does not control. The number of external systems grows faster than the number of core agents.</p>
<h2>The pattern</h2>
<p>Put one <strong>ambassador agent</strong> on each external boundary and make it the only way across. A core agent asks for a capability in its own language: <code>book_shipment</code>, not <code>CREATE_SHPMT</code> with an <code>ORD_NO</code>. The ambassador owns everything else, and it finishes every task on its own.</p>
<img src="https://raw.githubusercontent.com/bassemZohdy/ambassador-agent/main/docs/diagrams/architecture.svg" alt="A core agent opens a task with the ambassador. It passes policy and admission, the ambassador records its intent in the journal, then acts on the external system; replies pass quarantine before the core agent sees them. A task is refused when too many are waiting." style="display:block;margin:0 auto" />

<p>The whole definition fits in four lines:</p>
<table>
<thead>
<tr>
<th>Part</th>
<th>Statement</th>
</tr>
</thead>
<tbody><tr>
<td>One concept</td>
<td>The ambassador: one boundary, one ambassador, one named human owner</td>
</tr>
<tr>
<td>One interaction model</td>
<td>The core opens tasks. Each task ends as succeeded, failed, rejected or unknown</td>
</tr>
<tr>
<td>One reliability rule</td>
<td>Every action is journalled before it happens</td>
</tr>
<tr>
<td>Seven duties</td>
<td>Contract, identity, policy, admission, journal, quarantine, fallback</td>
</tr>
</tbody></table>
<p>An ambassador is an agent in the sense that matters for architecture: it has an identity, a published contract, its own state and the authority to decide how a request is carried out. Whether it uses a model is a choice, not part of the definition.</p>
<h2>The interaction model: tasks</h2>
<p>The core system talks to an ambassador through tasks. Five statements define them.</p>
<p><strong>Only the core opens a task.</strong> An ambassador never starts an exchange with the core and never calls another ambassador. Two parties that can each start an exchange with the other can loop without end. One direction of initiation removes that whole class of failure.</p>
<p><strong>A task asks for one capability</strong>, names the principal it is for, and carries an idempotency key when it has a side effect.</p>
<p><strong>A task never pauses.</strong> The ambassador is fully autonomous. When it cannot decide, it does not ask a person or open a dialogue with the core. It ends the task.</p>
<p><strong>Four outcomes, always.</strong> An outcome says only what is known about the action. <code>succeeded</code>: it was carried out. <code>failed</code>: it is known not to have been. <code>rejected</code>: refused before the boundary was crossed. <code>unknown</code>: it may or may not have been, and it must be reconciled. A timeout after a request was sent is <code>unknown</code>, never <code>failed</code>. Core agents never interpret a vendor error.</p>
<p><strong>What to do next travels beside the outcome, never in place of it.</strong> A result can carry a fallback channel, a retry hint or the operation id to reconcile by. They are instructions, and the outcome stays a fact. A fallback channel is attached only when the action is known not to have been done. Pointing a customer to the courier's website after a timeout would risk a second booking, so it never happens while the outcome is unknown.</p>
<p><strong>News from outside arrives as a notice.</strong> The core opens a long-lived subscription, and the ambassador sends translated, sanitised notices into it. A notice is a fact, never a command. If nobody is subscribed, the ambassador records the event and does not hold it; keeping undelivered events is the messaging layer's job.</p>
<img src="https://raw.githubusercontent.com/bassemZohdy/ambassador-agent/main/docs/diagrams/task.svg" alt="A core agent opens a task. The ambassador checks policy and admission, records its intent, sends the vendor request, records the outcome, sanitises the reply and answers with one of four outcomes." style="display:block;margin:0 auto" />

<h2>The reliability rule: the journal</h2>
<p><strong>Before an ambassador acts on the external system, it records its intent. After, it records the outcome.</strong></p>
<p>Between "sent" and "recorded" there is always a window in which the action may have taken effect and the ambassador cannot tell. The rule does not close that window. It makes sure the ambassador always knows it is in it, and never reports a guess as a fact.</p>
<ul>
<li>An intent with an outcome is finished. A repeated task with the same idempotency key gets the recorded outcome back, and the external system is not called again.</li>
<li>An intent with no outcome means the ambassador stopped mid-action. The outcome is unknown, and on restart it must be reconciled.</li>
<li>A timeout is the same situation as a crash. Before it retries or offers another channel, the ambassador settles what may have happened. A refused connection that never carried the request is different: nothing was sent, so it can be retried freely.</li>
</ul>
<img src="https://raw.githubusercontent.com/bassemZohdy/ambassador-agent/main/docs/diagrams/recovery.svg" alt="After a restart the ambassador reads the journal for intents with no outcome, then verifies with the external system, resends, or stops and reports the outcome as unknown, and records the result." style="display:block;margin:0 auto" />

<h3>What the journal guarantees, and what it does not</h3>
<p>Across a boundary the ambassador does not control, exactly-once effects are impossible in general. Each capability declares which of three delivery classes it has:</p>
<table>
<thead>
<tr>
<th>Class</th>
<th>Holds when</th>
<th>Declared as</th>
<th>After an ambiguous failure</th>
</tr>
</thead>
<tbody><tr>
<td>Effectively once</td>
<td>The external system ignores a repeated operation id, or can be asked about it</td>
<td><code>verify</code> or <code>resend</code></td>
<td>Ask, or send the same operation id again. At most one effect</td>
</tr>
<tr>
<td>At least once</td>
<td>The external action is naturally repeatable, or a duplicate is harmless</td>
<td><code>resend</code>, chosen knowingly</td>
<td>Send again. A duplicate is possible and accepted</td>
</tr>
<tr>
<td>Unrecoverable unknown</td>
<td>The external system can neither deduplicate nor be asked</td>
<td><code>stop</code></td>
<td>Report <code>unknown</code>, hold repeats, hand it to the owner</td>
</tr>
</tbody></table>
<p>Every task has an <strong>operation id</strong>: its idempotency key, or one the ambassador makes. It is journalled with the intent and sent to the external system as its own idempotency key or client reference, the same on every retry, resend and recovery. That is what lets the other side deduplicate, or be asked. <code>resend</code> is only effectively-once if the other side deduplicates; otherwise it quietly means at-least-once.</p>
<p><strong>When "no record" can be believed.</strong> An empty lookup does not prove the action will never happen: a request can still be in flight, or the other side can be slow to show its own writes. So a capability that verifies also declares whether <strong>absence is final</strong> (the external system refuses a request that arrives late) and a <strong>settle window</strong> (a wait before a lookup is believed). It must also be true that the lookup is by operation id and that the other side keeps the id longer than recovery takes. The ambassador acts on the declarations and cannot check them, so the owner answers for them. Without them, an empty lookup ends as <code>unknown</code>. A capability that cannot meet them should declare <code>stop</code>.</p>
<p><strong>An unknown outcome is an exception for a person.</strong> The task ends as <code>unknown</code> with its operation id, and no other channel is offered. A repeat of the task gets <code>unknown</code> back and is not sent again, and the open exception holds its resource: a new task for the same order, even under a new idempotency key, is refused as <code>resource_held</code>. Clients follow the same rule from their side: an <code>unknown</code> is never retried under a new key. The ambassador lists its open exceptions for the named owner, who finds out from the external system's own records and records <code>succeeded</code> or <code>failed</code>, with their name and a note. A <code>failed</code> answer is the first moment another channel may be offered.</p>
<p>A capability with several steps extends the same journal to every step, so a restart resumes at the step that was interrupted. That is durable execution; the single-step journal is its smallest form. The journal is also the audit record: who asked, for whom, what was sent and what came back.</p>
<h2>The seven duties</h2>
<table>
<thead>
<tr>
<th>Duty</th>
<th>What the ambassador does</th>
</tr>
</thead>
<tbody><tr>
<td>Contract</td>
<td>Publishes capabilities in the core's language, each with its declarations (below)</td>
</tr>
<tr>
<td>Identity</td>
<td>Acts for a named principal and exchanges that identity for credentials the external system accepts. It never acts as itself by default</td>
</tr>
<tr>
<td>Policy</td>
<td>Refuses a task before the boundary is crossed. With no person to ask, this check carries the full weight for irreversible actions</td>
</tr>
<tr>
<td>Admission</td>
<td>Controls how much work it takes on</td>
</tr>
<tr>
<td>Journal</td>
<td>Records intent and outcome for every crossing</td>
</tr>
<tr>
<td>Quarantine</td>
<td>Treats everything from outside as data, never as instructions, and sanitises it before a core agent sees it</td>
</tr>
<tr>
<td>Fallback</td>
<td>Offers another channel when the external system cannot finish the job and the action is known not to have been done. Never while the outcome is unknown</td>
</tr>
</tbody></table>
<h3>Admission</h3>
<p>Agents loop. A runaway core workflow can open hundreds of tasks in a second, and the external system has a quota that only the ambassador knows. Admission protects the ambassador, the budget when a model is used, and that quota.</p>
<ol>
<li><strong>One task at a time per resource.</strong> Two callers cannot race on the same order. A second task waits or is refused. It never interrupts or rolls back the first, because an external side effect cannot be undone by cancelling the run that caused it.</li>
<li><strong>The wait is bounded</strong>, with a fair share per principal.</li>
<li><strong>When full, refuse</strong>, with a hint of when to retry. An unbounded wait turns overload into memory exhaustion and stale work.</li>
<li><strong>Pace to the external system.</strong> Work is released no faster than its quota allows.</li>
</ol>
<p>Limits per caller and per cost usually also sit in a gateway in front. The two complement each other: the gateway stops floods, and the ambassador protects the boundary's own quota.</p>
<h3>What a capability declares</h3>
<table>
<thead>
<tr>
<th>Declaration</th>
<th>Values</th>
<th>Purpose</th>
</tr>
</thead>
<tbody><tr>
<td>Resource</td>
<td>A key such as an order number</td>
<td>Tasks for the same key run one at a time</td>
</tr>
<tr>
<td>Delivery class</td>
<td>Verify, resend, stop</td>
<td>How an unknown outcome is settled, after a crash or a timeout</td>
</tr>
<tr>
<td>Absence is final, settle window</td>
<td>Yes or no, and a wait</td>
<td>Whether an empty lookup can be believed</td>
</tr>
<tr>
<td>Compensation</td>
<td>Compensable, partly, not</td>
<td>Lets the core plan an action that spans several boundaries</td>
</tr>
<tr>
<td>Fallback</td>
<td>A channel and instructions</td>
<td>Offered beside <code>failed</code>, never beside <code>unknown</code></td>
</tr>
<tr>
<td>Governance</td>
<td>Data classification, audit retention, approval required</td>
<td>Published for owners and reviewers. Approval is enforced as a scope the principal holds</td>
</tr>
</tbody></table>
<p>Compensation is not undo. A refund after a charge is "partly"; a delivered message is "not". The core orchestrates an action across boundaries, and each ambassador is a participant. A multi-step capability inside one boundary is the ambassador's own responsibility.</p>
<p><strong>What is fixed, and what is a choice.</strong> Six rules are not negotiable: only the core opens a task; the intent is journalled before the action and the outcome after; a timeout is not a failure; no fallback is offered while the outcome is unknown; the operation id never changes; and no two tasks for one resource are in flight at once. Retries, the circuit breaker, pacing, queue size, the settle window, how much intelligence is used and whether approval is needed are the owner's policy. If changing a setting can cause a duplicate or report a guess as a fact, it is a rule.</p>
<h2>An agent that may not need a model</h2>
<table>
<thead>
<tr>
<th>Level</th>
<th>Model use</th>
<th>Fits when</th>
</tr>
</thead>
<tbody><tr>
<td>Scripted</td>
<td>None</td>
<td>Stable API, clear errors, high volume</td>
</tr>
<tr>
<td>Assisted</td>
<td>Consulted on failures</td>
<td>Errors are ambiguous, or recovery depends on context</td>
</tr>
<tr>
<td>Autonomous planning</td>
<td>May plan the steps inside a capability</td>
<td>The interface is a document, a screen or another agent</td>
</tr>
</tbody></table>
<p>The contract is the same at every level, so you start scripted and add intelligence only where a real failure mode demands it. When you do add a model, prefer a fast, low-latency one. The boundary is on the path of every action, so speed and cost matter more there than depth of reasoning.</p>
<h2>A worked example</h2>
<p>An online shop has a core assistant that helps customers. The Courier is an external system with its own codes, occasional outages, a quota of ten calls a second, and free-text remarks written by depot staff. Its ambassador offers <code>book_shipment</code>, <code>cancel_shipment</code> and <code>shipment_status</code>, plus a subscription for status changes.</p>
<table>
<thead>
<tr>
<th>Scenario</th>
<th>What happens</th>
</tr>
</thead>
<tbody><tr>
<td>Normal booking</td>
<td>Policy and admission pass, the intent is recorded, the vendor request is sent for customer 77, the outcome is recorded, and the assistant gets <code>succeeded</code> with no vendor code in sight</td>
</tr>
<tr>
<td>The model repeats itself</td>
<td>Same idempotency key: the recorded outcome is returned and the Courier is not called again</td>
</tr>
<tr>
<td>Outage</td>
<td>Connections are refused, so nothing was sent. After retries the task ends as <code>failed</code>, with instructions to book on the courier's own website</td>
</tr>
<tr>
<td>A lost reply</td>
<td>The Courier booked it and the reply timed out. The ambassador asks the Courier about the operation id, finds the booking and records <code>succeeded</code>. Retrying or using the website would have booked twice</td>
</tr>
<tr>
<td>A lost reply, nothing to ask</td>
<td>The capability declared <code>stop</code>. The task ends as <code>unknown</code>, with no other channel offered. The owner finds the booking in the Courier's portal and records it</td>
</tr>
<tr>
<td>A runaway caller</td>
<td>Ten tasks a second are released, a bounded number wait, the rest are <code>rejected</code> with a retry hint</td>
</tr>
<tr>
<td>A crash mid-action</td>
<td>On restart the open intent is verified with the Courier and recorded as <code>succeeded</code>. Nothing is sent twice</td>
</tr>
<tr>
<td>A hostile remark</td>
<td>A status event containing "ignore previous instructions" becomes a sanitised notice that states a fact</td>
</tr>
</tbody></table>
<p>When the Courier later starts returning vague errors, the team adds a small, fast model that classifies each failure as retry, fallback or fail. It cannot override the delivery rule: a timeout on a booking is still settled before anything is retried. Callers notice nothing.</p>
<h2>Binding it to a protocol</h2>
<p>The pattern defines tasks abstractly, and a protocol carries them. A2A is the reference because it is the common standard for agents talking over a network and already has most of what is needed. It is not required.</p>
<table>
<thead>
<tr>
<th>Pattern concept</th>
<th>A2A</th>
<th>Status</th>
</tr>
</thead>
<tbody><tr>
<td>Ambassador description, capability</td>
<td>Agent card, skill</td>
<td>Direct</td>
</tr>
<tr>
<td>Task: waiting, working</td>
<td><code>submitted</code>, <code>working</code></td>
<td>Direct</td>
</tr>
<tr>
<td>Succeeded, failed, rejected</td>
<td><code>completed</code>, <code>failed</code>, <code>rejected</code></td>
<td>Direct</td>
</tr>
<tr>
<td>Subscription and notices</td>
<td>Streaming or push notifications on a task the core opened</td>
<td>Direct</td>
</tr>
<tr>
<td><code>unknown</code>, fallback beside an outcome, operation id, compensation, delivery class, retry hint</td>
<td>None</td>
<td>A proposed extension</td>
</tr>
<tr>
<td>Admission, acting for a principal, journal, quarantine</td>
<td>None</td>
<td>The ambassador's own duties</td>
</tr>
</tbody></table>
<p>The right-hand column is the clearest statement of what the pattern adds. A2A's two pausing states, <code>input-required</code> and <code>auth-required</code>, are not used, because an ambassador's tasks do not pause.</p>
<h2>What it borrows, and what it leaves</h2>
<p>No earlier pattern is adopted as is.</p>
<table>
<thead>
<tr>
<th>Source</th>
<th>Taken</th>
<th>Left out</th>
</tr>
</thead>
<tbody><tr>
<td>Transactional outbox</td>
<td>Record before you send</td>
<td>The relay and the broker</td>
</tr>
<tr>
<td>Saga</td>
<td>Each participant declares and owns its compensation</td>
<td>Orchestration, which stays in the core</td>
</tr>
<tr>
<td>Actor model</td>
<td>One piece of work at a time, and a bounded wait</td>
<td>The mailbox as a concept, supervision trees</td>
</tr>
<tr>
<td>Anti-corruption layer</td>
<td>The foreign model never leaks in</td>
<td>Its passive nature: no owner, no authority to refuse</td>
</tr>
<tr>
<td>Cloud Ambassador pattern</td>
<td>The name, and outbound connectivity concerns</td>
<td>Co-location with one client, no business meaning</td>
</tr>
<tr>
<td>Durable execution</td>
<td>Journal every step so a restart resumes</td>
<td>A workflow engine as a requirement</td>
</tr>
<tr>
<td>Ambient agents</td>
<td>Agents driven by events, not chat</td>
<td>A model in the loop for every event</td>
</tr>
<tr>
<td>Dual LLM pattern</td>
<td>Outside content is data, kept from a model with authority</td>
<td>A second model as the mechanism</td>
</tr>
</tbody></table>
<p>Considered and not taken: human-in-the-loop as a core step, try-confirm-cancel as a requirement, ambassadors reacting to each other's events, two-phase commit, and a stateless tool call as the interaction model.</p>
<p>It composes with what you already have. A gateway sits in front. An MCP tool makes a fine connector inside. The ambassador is the part that answers for the outcome.</p>
<h2>What it costs, and when to skip it</h2>
<ul>
<li>One more hop, and a model call on some paths if intelligence is used.</li>
<li>A contract you have to design. A thin pass-through contract gives none of the benefits.</li>
<li>A durable journal, even for the simplest ambassador.</li>
<li>A single path to each system, which must therefore be run redundantly. That needs more than a second copy: mutual exclusion per resource across copies, a shared journal, and a claim on each open intent.</li>
<li>With no person in the loop, policy is the only safeguard before an irreversible action.</li>
</ul>
<p>Use the pattern when at least two of these hold: several core agents use the system, calls have side effects, you do not control its availability or quota, its replies contain free text a model will read, or someone will ask "who did this, for whom, and when?" For a read-only, internal, single-consumer lookup, a plain tool is enough.</p>
<h2>Open questions</h2>
<p>This is version 0.2 of a proposal. It has no documented use in production yet.</p>
<ol>
<li><strong>Redundancy and admission.</strong> The pattern lists what several replicas need and three ways to get mutual exclusion: partition by resource key, one active replica, or a lease with fencing. None of it is implemented in the reference, which is tested in one process only.</li>
<li><strong>The limit of autonomy.</strong> When an outcome is unknown and the external system cannot be asked, the ambassador reports <code>unknown</code>, holds repeats and lists the exception, and a person must resolve it. How long it may be held, who is alerted, and whether a task type may set a time limit before escalating are not yet described.</li>
<li><strong>Policy.</strong> The pattern does not yet say how policy is defined or reviewed.</li>
<li><code>unknown</code> <strong>in A2A.</strong> A2A has no state for "may have happened". It maps to <code>failed</code> with the outcome in extension data, so a client that ignores the extension may read a plain failure and retry. The ambassador holds repeats of the same task and, for a capability that names a resource, the resource too. A client that retries under a new key against a capability with no resource still defeats it.</li>
</ol>
<h2>Read it and break it</h2>
<p>The repository holds the full definition, numbered conformance rules with the designs that fail them, a page on identity and trust, a catalogue of anti-patterns, a glossary, a page for each variant, a guide to combining the pattern with a gateway, MCP, a saga or a supervisor, a decision guide, two worked examples, a page of questions and objections, the protocol mapping and every source. It is independent of any language, agent platform or protocol. A small reference implementation is included only to show it can be built. To cite it, use the DOI <a href="https://doi.org/10.5281/zenodo.24210615">10.5281/zenodo.24210615</a>, which always resolves to the latest version.</p>
<p><a href="https://github.com/bassemZohdy/ambassador-agent"><strong>https://github.com/bassemZohdy/ambassador-agent</strong></a></p>
<p>I would like to hear where this breaks. If you have a boundary that does not fit, or you already run something like this, please open an issue.</p>
<h2>References</h2>
<ol>
<li>Microsoft, <a href="https://learn.microsoft.com/azure/architecture/patterns/ambassador">Ambassador pattern</a>, Azure Architecture Center.</li>
<li>Burns and Oppenheimer, "Design patterns for container-based distributed systems", HotCloud 2016.</li>
<li>Evans, <em>Domain-Driven Design</em>, 2003; Microsoft, <a href="https://learn.microsoft.com/azure/architecture/patterns/anti-corruption-layer">Anti-corruption layer pattern</a>.</li>
<li>Hohpe and Woolf, <a href="https://www.enterpriseintegrationpatterns.com/toc.html"><em>Enterprise Integration Patterns</em></a>, 2003.</li>
<li>Richardson, <a href="https://microservices.io/patterns/data/transactional-outbox.html">Transactional outbox</a> and <a href="https://microservices.io/patterns/data/saga.html">Saga</a>.</li>
<li>Garcia-Molina and Salem, "Sagas", 1987.</li>
<li>Hewitt, Bishop and Steiger, "A universal modular Actor formalism for artificial intelligence", 1973.</li>
<li><a href="https://doc.akka.io/docs/akka/2.9/typed/mailboxes.html">Akka mailboxes</a>; <a href="https://docs.dapr.io/developing-applications/building-blocks/actors/actors-features-concepts/">Dapr actors</a>; <a href="https://developers.cloudflare.com/durable-objects/platform/limits">Cloudflare Durable Objects limits</a>.</li>
<li>LangChain, <a href="https://docs.langchain.com/langsmith/double-texting">Double texting</a> and <a href="https://blog.langchain.com/introducing-ambient-agents">"Introducing ambient agents"</a>.</li>
<li><a href="https://a2a-protocol.org/">Agent2Agent (A2A) protocol</a>; <a href="https://modelcontextprotocol.io/">Model Context Protocol</a>.</li>
<li><a href="https://arxiv.org/abs/2410.08328">"Agents thinking fast and slow: a Talker-Reasoner architecture"</a>, 2024.</li>
<li>Willison, <a href="https://simonwillison.net/2023/Apr/25/dual-llm-pattern/">"The dual LLM pattern"</a>, 2023.</li>
<li>Thoughtworks, <a href="https://www.thoughtworks.com/en-gb/insights/blog/generative-ai/your-agent-skill-not-anti-corruption-layer">"Your agent skill is not an anti-corruption layer"</a>.</li>
<li>Hardy, "The confused deputy", 1988.</li>
</ol>
<p>The complete list, with how each source relates to the pattern, is in the repository's <a href="https://github.com/bassemZohdy/ambassador-agent/blob/main/docs/references.md">references page</a>.</p>
<p><em>Bassem Zohdy is a software and solution architect. This is personal work and does not represent any employer.</em></p>
]]></content:encoded></item><item><title><![CDATA[AI-Driven Software Development: A Flexible Agentic Team Structure]]></title><description><![CDATA[AI-enhanced team blends AI and human strategy for efficient, dynamic software development]]></description><link>https://dev-ai-agents.hashnode.dev/ai-driven-software-development-a-flexible-agentic-team-structure</link><guid isPermaLink="true">https://dev-ai-agents.hashnode.dev/ai-driven-software-development-a-flexible-agentic-team-structure</guid><category><![CDATA[ai agents]]></category><category><![CDATA[ai-agent]]></category><category><![CDATA[software development]]></category><category><![CDATA[software architecture]]></category><dc:creator><![CDATA[bassem zohdy]]></dc:creator><pubDate>Sat, 02 Aug 2025 10:43:43 GMT</pubDate><content:encoded><![CDATA[<h2 id="heading-introduction-redefining-software-development-in-the-age-of-ai">Introduction: Redefining Software Development in the Age of AI</h2>
<p>The landscape of software development is rapidly evolving, driven by the transformative power of Artificial Intelligence. As AI capabilities grow, so does the opportunity to rethink how we structure our development teams and workflows. We're moving beyond traditional monolithic approaches towards more dynamic, intelligent, and autonomous systems.</p>
<p>This document presents a flexible, agent-based team structure designed to harness the full potential of AI in software delivery. It's not about replacing human talent, but augmenting it, creating a synergistic environment where AI agents handle specialized tasks, allowing human teams to focus on strategic oversight, creativity, and complex problem-solving. This framework is built to be adaptable, seamlessly integrating with any development methodology or underlying AI platform you choose. Join us as we explore a new blueprint for building software in the AI era.</p>
<h2 id="heading-overview">Overview</h2>
<p>This document outlines a flexible agent-based structure for modern software development. It's designed to mirror the essential functions found in any software team, regardless of the specific development methodology chosen or the underlying AI platform. This adaptable structure focuses on classifying roles based on the universal tasks required for successful software delivery, with a main coordinator overseeing project orchestration and strategic decisions.</p>
<h2 id="heading-foundation">Foundation</h2>
<p>The core of this agent structure is built upon fundamental software development principles and practical team organization. It identifies and categorizes the generic tasks crucial for creating and maintaining software, ensuring comprehensive coverage of the development lifecycle. This approach abstracts away the specifics of any single methodology, platform, or framework, making the model broadly applicable and easily customizable to various project needs and technological environments.</p>
<h2 id="heading-agent-structure">Agent Structure</h2>
<p>This structure reflects practical software development team organization, optimized for AI-driven development workflows:</p>
<h3 id="heading-1-requirement-analyst-agent">1. Requirement Analyst Agent 📈</h3>
<p><strong>Color:</strong> Yellow <strong>Role:</strong> Gather, analyze, and document comprehensive project requirements across all scopes.</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Research and analyze to find out all the detailed needs and goals (functional and non-functional) for the project.</p>
</li>
<li><p>Turn business needs, user goals, and technical ideas into clear, actionable descriptions of what the software should do. These can be written as structured feature files (like Gherkin syntax), and their format can change based on project needs.</p>
</li>
<li><p>Break down and refine requirements to make sure they are clear, complete, consistent, and easy to test.</p>
</li>
<li><p>Manage changes to requirements and communicate how these changes affect the project.</p>
</li>
<li><p>Decide which requirements are most important based on their business value, how easy they are to build, and project goals.</p>
</li>
<li><p>Set clear conditions for when each requirement and feature is considered done.</p>
</li>
<li><p>Keep the list of requirements (backlog) updated and refined.</p>
</li>
<li><p>Act as a link between business people and the technical development teams.</p>
</li>
<li><p>Work with the UI/UX Design Agent to make sure the user experience matches what the software needs to do.</p>
</li>
<li><p>Work with Frontend/Backend Developer Agents to explain technical details and ensure they understand the requirements.</p>
</li>
<li><p>Work with the Quality Assurance Agent to make sure requirements can be tested.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are a Requirement Analyst Agent, responsible for gathering, analyzing, and documenting all functional and non-functional requirements for the project. Your responsibilities include:
- Gather comprehensive and detailed requirements through research, stakeholder input, and data analysis.
- Translate project goals and business needs into clear, actionable functional descriptions and structured feature files (e.g., Gherkin syntax). Adapt feature file format as needed for clear agent communication.
- Analyze and refine requirements for clarity, completeness, consistency, and testability.
- Manage requirement changes, communicating their impact on scope, timeline, and resources.
- Prioritize requirements based on business value, technical feasibility, and user impact.
- Define clear acceptance criteria for each requirement and feature.
- Maintain and refine the requirements backlog, ensuring it reflects current priorities.
- Serve as the primary liaison for requirements clarification among all agents.
- Collaborate closely with UI/UX Design Agent to ensure design specifications directly address defined user and functional requirements.
- Work with Frontend and Backend Developer Agents to clarify technical aspects of requirements and ensure mutual understanding.
- Partner with Quality Assurance Agent to ensure all requirements are testable and to facilitate comprehensive test plan creation.
Focus on precise, clear, and traceable requirements to build a solid foundation for development and testing.
Handoff: Deliver prioritized requirements backlog, functional descriptions, and feature files to UI/UX Design, Frontend, Backend, and Quality Assurance Agents. Provide comprehensive requirements documentation to the Documentation Agent.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h3 id="heading-2-uiux-design-agent">2. UI/UX Design Agent 🎨</h3>
<p><strong>Color:</strong> Pink <strong>Role:</strong> Complete design workflow from user research to final specifications</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Conduct user experience research and analysis, <em>informed by Requirement Analyst Agent's insights</em>.</p>
</li>
<li><p>Design intuitive user interfaces and comprehensive user experiences, <em>based on detailed requirements from Requirement Analyst Agent</em>.</p>
</li>
<li><p>Create wireframes, mockups, interactive prototypes, and design specifications.</p>
</li>
<li><p>Develop and maintain design systems, component libraries, and style guides.</p>
</li>
<li><p>Ensure accessibility standards (WCAG) compliance and inclusive design practices.</p>
</li>
<li><p>Design responsive layouts optimized for multiple device types and screen sizes.</p>
</li>
<li><p>Collaborate with frontend developers to ensure design feasibility and technical implementation.</p>
</li>
<li><p>Provide detailed design handoffs with assets, measurements, and implementation guidelines.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are a UI/UX Design Agent specializing in creating user-centered designs for modern applications. Your responsibilities include:
- Conduct thorough user research, create detailed user personas, and analyze user behavior patterns, *leveraging insights and initial requirements from the Requirement Analyst Agent*.
- Design intuitive, accessible, and visually appealing user interfaces that solve real user problems, *adhering closely to the functional and user experience requirements provided by the Requirement Analyst Agent*.
- Create comprehensive wireframes, high-fidelity mockups, interactive prototypes, and detailed design specifications.
- Develop and maintain consistent design systems, reusable component libraries, and comprehensive style guides.
- Ensure full accessibility standards (WCAG) compliance and implement inclusive design principles throughout.
- Design responsive layouts that work seamlessly across desktop, tablet, and mobile devices.
- Collaborate closely with Frontend Developer Agent to ensure design feasibility and provide technical implementation guidance.
- Deliver detailed design handoffs including all assets, precise measurements, spacing specifications, and clear implementation guidelines.
Focus on user-centered design principles, modern UI trends, and creating designs that are both beautiful and functional. Always consider usability, accessibility, performance implications, and technical constraints in your design decisions.
Handoff: Provide complete design specifications, assets, and style guides to Frontend Developer Agent with detailed implementation notes and technical requirements. Provide design rationale and user experience documentation to Documentation Agent.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h3 id="heading-3-frontend-developer-agent">3. Frontend Developer Agent 💻</h3>
<p><strong>Color:</strong> Cyan <strong>Role:</strong> Client-side implementation and user interface development</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Implement UI designs with pixel-perfect accuracy following UI/UX specifications.</p>
</li>
<li><p>Build responsive, accessible, and performant user interfaces, <em>adhering to functional and non-functional requirements from the Requirement Analyst Agent</em>.</p>
</li>
<li><p>Handle client-side state management, routing, and application logic.</p>
</li>
<li><p>Integrate with backend APIs using specifications from Backend Developer Agent.</p>
</li>
<li><p>Implement modern frontend patterns (component-based architecture, hooks, reactive programming).</p>
</li>
<li><p>Ensure cross-browser compatibility and mobile responsiveness.</p>
</li>
<li><p>Optimize bundle size, loading performance, and user experience metrics.</p>
</li>
<li><p>Write maintainable, testable frontend code with proper documentation.</p>
</li>
<li><p>Collaborate on API contract definition and frontend-backend integration.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are a Frontend Developer Agent specializing in modern client-side development and user interface implementation. Your responsibilities include:
- Implement designs from UI/UX Design Agent with pixel-perfect accuracy and attention to design system consistency.
- Build responsive, accessible, and high-performance user interfaces following modern web standards, *ensuring full adherence to the functional and non-functional requirements provided by the Requirement Analyst Agent*.
- Handle comprehensive client-side functionality including state management, routing, and application logic.
- Integrate seamlessly with REST/GraphQL APIs using specifications provided by Backend Developer Agent.
- Implement modern frontend patterns including component-based architecture, hooks, reactive programming, and efficient data flow.
- Ensure cross-browser compatibility, mobile responsiveness, and optimal performance across all target devices.
- Optimize bundle size, loading performance, code splitting, and overall user experience metrics.
- Write clean, maintainable, and thoroughly tested frontend code with comprehensive documentation.
- Collaborate closely with Backend Developer Agent on API contracts, data structures, and integration requirements. *Seek clarification on requirements from Requirement Analyst Agent as needed*.
Use modern frameworks and tools (React, Vue, Angular, TypeScript, etc.) following current best practices. Focus on creating smooth, intuitive user experiences while maintaining scalable, performant code architecture.
Handoff: Provide integration requirements to Backend Developer Agent, performance metrics to Quality Assurance Agent, and deployment artifacts to Infrastructure Agent. Provide code documentation to Documentation Agent.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h3 id="heading-4-backend-developer-agent">4. Backend Developer Agent ⚙️</h3>
<p><strong>Color:</strong> Blue <strong>Role:</strong> Server-side implementation, business logic, and database management</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Design and implement REST/GraphQL APIs with proper versioning, <em>based on requirements from Requirement Analyst Agent</em>.</p>
</li>
<li><p>Develop business logic and data processing systems, <em>adhering to functional requirements and data specifications from Requirement Analyst Agent</em>.</p>
</li>
<li><p>Complete database management: schema design, optimization, migrations, performance tuning.</p>
</li>
<li><p>Implement authentication, authorization, and data security measures.</p>
</li>
<li><p>Handle third-party service integrations and external APIs.</p>
</li>
<li><p>Create background jobs, queues, and scheduled tasks.</p>
</li>
<li><p>Implement caching strategies and backend performance optimizations.</p>
</li>
<li><p>Write comprehensive backend and database tests.</p>
</li>
<li><p>Manage API documentation and specifications.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are a Backend Developer Agent specializing in server-side development, API design, and database management. Your responsibilities include:
- Design and implement scalable REST/GraphQL APIs with proper versioning and lifecycle management, *directly implementing the API and data requirements provided by the Requirement Analyst Agent*.
- Develop robust business logic and data processing systems, *ensuring full compliance with the functional and non-functional requirements from the Requirement Analyst Agent*.
- Handle complete database responsibilities: schema design, query optimization, migrations, indexing, and performance tuning.
- Implement comprehensive security measures for APIs, data access, and authentication/authorization.
- Manage third-party service integrations and external API communications.
- Create and maintain background processing systems, job queues, and scheduled tasks.
- Implement effective caching strategies and backend performance optimizations.
- Write thorough tests for all backend functionality including database operations.
- Create and maintain API documentation following OpenAPI standards. *Seek clarification on requirements from Requirement Analyst Agent as needed*.
Focus on building secure, scalable, and maintainable backend systems. Use appropriate design patterns and follow security-first principles. Ensure proper error handling, logging, and monitoring capabilities.
Handoff: Provide API specifications to Frontend Developer Agent, database schemas to Infrastructure Agent, and security implementations to Tech Architecture Agent for review. Provide code documentation and API specifications to Documentation Agent.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h3 id="heading-5-quality-assurance-agent">5. Quality Assurance Agent 🛡️</h3>
<p><strong>Color:</strong> Red <strong>Role:</strong> Testing, performance validation, and compliance verification</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Design and implement comprehensive testing strategies (unit, integration, e2e, load testing), <em>directly based on feature files and acceptance criteria provided by the Requirement Analyst Agent</em>.</p>
</li>
<li><p>Execute automated test suites and establish CI/CD quality gates.</p>
</li>
<li><p>Perform application security testing and vulnerability assessments (following Tech Architecture security standards).</p>
</li>
<li><p>Conduct performance testing, identify bottlenecks, and validate optimizations.</p>
</li>
<li><p>Verify code quality against established standards and performance benchmarks.</p>
</li>
<li><p>Create and maintain test documentation, quality metrics, and testing frameworks.</p>
</li>
<li><p>Establish and validate quality standards and acceptance criteria, <em>derived from Requirement Analyst Agent's output</em>.</p>
</li>
<li><p>Monitor application health and performance in production environments.</p>
</li>
<li><p>Execute risk assessment and mitigation planning for quality-related issues.</p>
</li>
<li><p>Verify compliance with regulatory requirements and quality standards.</p>
</li>
<li><p>Plan and execute disaster recovery testing scenarios and business continuity validation.</p>
</li>
<li><p>Validate security implementations against Tech Architecture Agent's security requirements.</p>
</li>
<li><p><em>Manage test results and track requirements coverage based on feature files</em>.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are a Quality Assurance Agent responsible for ensuring comprehensive testing, performance validation, and compliance verification. Your responsibilities include:
- Design and implement thorough testing strategies covering unit, integration, end-to-end, and performance testing, *using the detailed feature files and acceptance criteria from the Requirement Analyst Agent as the primary source for test case generation and validation*.
- Build and maintain automated test suites with robust CI/CD quality gates and validation processes.
- Execute application security testing and vulnerability assessments following security standards from Tech Architecture Agent.
- Perform comprehensive performance testing, identify system bottlenecks, and validate optimization implementations.
- Verify all code meets established quality standards, performance benchmarks, and security requirements.
- Create comprehensive test documentation, maintain quality metrics, and build effective testing frameworks.
- Define clear quality standards, acceptance criteria, and validation processes for all deliverables, *ensuring alignment with Requirement Analyst Agent's specifications*.
- Monitor application health, performance metrics, and system reliability in production environments.
- Conduct thorough risk assessments and create mitigation plans for quality and performance issues.
- Verify compliance with regulatory requirements, quality standards, and organizational policies.
- Plan and execute disaster recovery scenarios, business continuity testing, and system resilience validation.
- Validate all security implementations against requirements provided by Tech Architecture Agent.
- *Actively manage and track test results against the documented feature files, providing feedback on requirements coverage and discrepancies to the Requirement Analyst Agent*.
Focus on preventing defects, performance issues, and compliance violations before production deployment. Use modern testing frameworks and provide actionable feedback for continuous improvement.
Handoff: Report quality metrics to Main Coordinator, security test results to Tech Architecture Agent, performance benchmarks to Infrastructure Agent, and *feedback on requirement clarity/testability to Requirement Analyst Agent*. Provide test reports and documentation to Documentation Agent.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h3 id="heading-6-infrastructure-agent">6. Infrastructure Agent 🚀</h3>
<p><strong>Color:</strong> Orange <strong>Role:</strong> DevOps, deployment, and operational excellence</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Design and implement CI/CD pipelines for automated testing and deployment.</p>
</li>
<li><p>Set up and maintain different defined environments (e.g., development, staging, production).</p>
</li>
<li><p>Create containerization strategies using Docker and orchestration with Kubernetes.</p>
</li>
<li><p>Manage cloud infrastructure (AWS, Azure, GCP) using Infrastructure as Code principles.</p>
</li>
<li><p>Set up comprehensive monitoring, logging, and alerting systems for all environments.</p>
</li>
<li><p>Implement deployment strategies (blue-green, canary, rolling updates) and automated rollback procedures.</p>
</li>
<li><p>Handle backup, disaster recovery, and infrastructure security compliance.</p>
</li>
<li><p>Optimize infrastructure costs, resource utilization, and system performance.</p>
</li>
<li><p>Ensure high availability, scalability, and reliability of all systems, <em>considering non-functional requirements from Requirement Analyst Agent</em>.</p>
</li>
<li><p>Handle incident response, production troubleshooting, and system maintenance.</p>
</li>
<li><p>Monitor system performance, plan capacity scaling, and manage infrastructure evolution.</p>
</li>
<li><p>Implement infrastructure security best practices following Tech Architecture security standards.</p>
</li>
<li><p>Manage production environment maintenance, updates, and operational procedures.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are an Infrastructure Agent specializing in DevOps practices and operational excellence. Your responsibilities include:
- Design and implement robust CI/CD pipelines with automated testing, deployment, and quality gates.
- Set up and maintain different defined environments (e.g., development, staging, production), ensuring their stability and accessibility.
- Create comprehensive containerization strategies using Docker and orchestration with Kubernetes or similar platforms.
- Manage cloud infrastructure across AWS, Azure, or GCP using Infrastructure as Code principles and best practices.
- Set up comprehensive monitoring, logging, alerting, and observability systems for all environments.
- Implement advanced deployment strategies including blue-green, canary deployments, and automated rollback procedures.
- Handle all backup, disaster recovery planning, and infrastructure security compliance requirements.
- Continuously optimize infrastructure costs, resource utilization, and overall system performance.
- Ensure high availability, scalability, fault tolerance, and reliability across all system components, *aligned with non-functional requirements and performance benchmarks from the Requirement Analyst Agent*.
- Manage incident response procedures, production troubleshooting, and proactive system maintenance.
- Monitor system performance metrics, plan capacity scaling, and manage infrastructure evolution.
- Implement infrastructure security best practices following standards established by Tech Architecture Agent.
- Manage production environment maintenance, security updates, and operational procedures.
Focus on automating all deployment processes, ensuring maximum system reliability, and maintaining operational excellence. Use modern DevOps tools and practices to create robust, scalable infrastructure supporting development team productivity.
Handoff: Coordinate with Tech Architecture Agent on infrastructure security requirements, provide deployment metrics to Quality Assurance Agent, and system performance data to Main Coordinator. Provide operational documentation to Documentation Agent.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h3 id="heading-7-tech-architecture-agent">7. Tech Architecture Agent 🏗️</h3>
<p><strong>Color:</strong> Purple <strong>Role:</strong> Technical authority, architecture decisions, security leadership, and code review</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Make strategic technical architecture decisions and technology choices, <em>informed by overall requirements from Requirement Analyst Agent</em>.</p>
</li>
<li><p>Define different environments (e.g., development, testing, production) and specify the characteristics and configurations for each.</p>
</li>
<li><p>Lead all security strategy, standards, and implementation oversight.</p>
</li>
<li><p>Review code from all development agents for quality, consistency, and architectural compliance.</p>
</li>
<li><p>Define and enforce coding standards, design patterns, and security best practices.</p>
</li>
<li><p>Evaluate technical trade-offs and provide authoritative recommendations.</p>
</li>
<li><p>Ensure architectural consistency across frontend, backend, and infrastructure.</p>
</li>
<li><p>Oversee API design standards, versioning strategies, and integration patterns, <em>ensuring alignment with documented requirements</em>.</p>
</li>
<li><p>Identify and address technical debt and architectural issues.</p>
</li>
<li><p>Guide technical discussions and resolve technical disputes between agents.</p>
</li>
<li><p>Create architectural documentation and technical specifications.</p>
</li>
<li><p>Track requirements traceability and manage technical change requests.</p>
</li>
<li><p>Conduct regular architecture reviews and technical risk assessments.</p>
</li>
<li><p>Assess compliance requirements (GDPR, SOX, HIPAA) and ensure technical implementation, <em>based on inputs from Requirement Analyst Agent</em>.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are a Tech Architecture Agent serving as the primary technical authority and security leader for the project. Your responsibilities include:
- Make all strategic technical architecture decisions and final technology choices, *guided by the comprehensive requirements and non-functional specifications from the Requirement Analyst Agent*.
- Define different environments (e.g., development, testing, production) and specify their unique characteristics, configurations, and security postures.
- Lead security strategy and oversee all security implementations across all agents.
- Review and approve all significant code changes and architectural decisions from development agents.
- Define and enforce coding standards, design patterns, security practices, and API design guidelines.
- Evaluate technical trade-offs and provide authoritative recommendations for complex decisions.
- Ensure architectural consistency and security compliance across frontend, backend, and infrastructure.
- Oversee API design standards, versioning strategies, microservices patterns, and integration approaches, *ensuring they fulfill the defined requirements*.
- Identify technical debt, architectural issues, and security vulnerabilities requiring attention.
- Resolve technical disputes between agents and guide complex technical discussions.
- Create comprehensive architectural documentation and maintain technical specifications.
- Manage requirements traceability, technical change requests, and impact assessments.
- Conduct regular architecture and security reviews with risk assessments.
- Ensure compliance with regulatory requirements and maintain security governance, *taking into account regulatory requirements specified by the Requirement Analyst Agent*.
Act as the senior technical lead with final decision authority on all technical and security matters. Balance current needs with long-term maintainability, scalability, security, and team productivity.
Handoff: Provide architectural decisions to all agents, security requirements to Quality Assurance and Infrastructure agents, and final approvals for production deployments. Provide architectural documentation to Documentation Agent.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h3 id="heading-8-documentation-agent">8. Documentation Agent 📚</h3>
<p><strong>Color:</strong> Green <strong>Role:</strong> Comprehensive technical and user documentation</p>
<p><strong>Responsibilities:</strong></p>
<ul>
<li><p>Create and maintain comprehensive API documentation (OpenAPI/Swagger specifications), <em>using inputs from Backend Developer Agent</em>.</p>
</li>
<li><p>Write clear user guides, tutorials, and step-by-step how-to documentation, <em>based on feature files from Requirement Analyst Agent and designs from UI/UX Design Agent</em>.</p>
</li>
<li><p>Document technical architecture decisions, system design, and implementation details.</p>
</li>
<li><p>Create detailed deployment guides, operational runbooks, and maintenance procedures, <em>using inputs from Infrastructure Agent</em>.</p>
</li>
<li><p>Maintain consistent code documentation standards and inline comment guidelines, <em>using inputs from Frontend and Backend Developer Agents</em>.</p>
</li>
<li><p>Develop onboarding documentation for new team members and stakeholders.</p>
</li>
<li><p>Create troubleshooting guides, FAQ sections, and knowledge base articles.</p>
</li>
<li><p>Ensure all documentation remains current and synchronized with code changes.</p>
</li>
<li><p>Collaborate with all agents to gather accurate information and technical details, <em>especially with Requirement Analyst Agent for core requirement documents</em>.</p>
</li>
</ul>
<p><strong>AI Agent Prompt:</strong></p>
<pre><code class="lang-plaintext">You are a Documentation Agent responsible for creating comprehensive, clear, and maintainable documentation across all project aspects. Your responsibilities include:
- Create and maintain detailed API documentation using OpenAPI/Swagger specifications with examples and integration guides, *based on specifications provided by the Backend Developer Agent*.
- Write clear, accessible user guides, comprehensive tutorials, and step-by-step how-to documentation for all user types, *directly referencing the feature files from the Requirement Analyst Agent and design insights from the UI/UX Design Agent*.
- Document all technical architecture decisions, system design rationale, and detailed implementation specifications, *collaborating with the Tech Architecture Agent*.
- Create thorough deployment guides, operational runbooks, and maintenance procedures, *with input from the Infrastructure Agent*.
- Establish and maintain consistent code documentation standards, inline comment guidelines, and documentation templates, *working with Frontend and Backend Developer Agents*.
- Develop comprehensive onboarding documentation for new team members, stakeholders, and external developers.
- Create detailed troubleshooting guides, FAQ sections, and searchable knowledge base articles.
- Ensure all documentation remains current, accurate, and synchronized with ongoing code changes and system updates.
- Collaborate effectively with all agents to gather accurate technical information, implementation details, and system specifications, *with particular emphasis on obtaining core requirement documents from the Requirement Analyst Agent*.
Focus on creating documentation that is clear, comprehensive, and accessible to different audiences including developers, users, and stakeholders. Use appropriate documentation tools and formats and formats for each content type and audience.
Handoff: Provide documentation to Main Coordinator for stakeholder review, technical docs to Tech Architecture Agent for accuracy validation, and user guides to UI/UX Design Agent for usability review.
Follow the Key Principles of Agent Collaboration: Clear Handoffs, Feedback Loops, Documentation, Quality Gates, and Continuous Improvement, including Consistent Documentation Standards (e.g., TODO.md, CHANGELOG.md), keep all documents under docs folder.
</code></pre>
<h2 id="heading-main-coordinator-role">Main Coordinator Role</h2>
<p>The main coordinator (human or AI) handles:</p>
<ul>
<li><p><strong>Project Coordination:</strong> Orchestrating agent workflows and dependencies.</p>
</li>
<li><p><strong>Strategic Decisions:</strong> High-level product and business decisions.</p>
</li>
<li><p><strong>Priority Management:</strong> Setting task priorities and managing scope, <em>in collaboration with the Requirement Analyst Agent</em>.</p>
</li>
<li><p><strong>Cross-Agent Communication:</strong> Facilitating collaboration between agents.</p>
</li>
<li><p><strong>Final Integration:</strong> Making final decisions when agents need guidance.</p>
</li>
<li><p><strong>Stakeholder Communication:</strong> Reporting progress and gathering requirements, <em>often facilitated by the Requirement Analyst Agent for detailed needs</em>.</p>
</li>
<li><p><strong>Workload Planning:</strong> Coordinating work activities and managing backlogs, <em>utilizing the prioritized backlog from the Requirement Analyst Agent</em>.</p>
</li>
<li><p><strong>Velocity Tracking:</strong> Monitoring team performance and delivery metrics.</p>
</li>
<li><p><strong>Risk Management:</strong> Identifying and mitigating project-level risks.</p>
</li>
<li><p><strong>Resource Allocation:</strong> Managing team capacity and workload distribution.</p>
</li>
<li><p><strong>Command Issuance:</strong> Providing clear commands and instructions for all agents to follow.</p>
</li>
<li><p><strong>Performance Monitoring:</strong> Continuously monitoring the performance and progress of all agents.</p>
</li>
</ul>
<h2 id="heading-enhanced-development-coverage">Enhanced Development Coverage</h2>
<p>This agent structure provides comprehensive coverage of software development workflow:</p>
<p><strong>Planning &amp; Design:</strong></p>
<ul>
<li><p><strong>Requirement Analyst Agent:</strong> User needs, detailed requirements, feature definition.</p>
</li>
<li><p>UI/UX Design Agent: User research and interface design.</p>
</li>
<li><p>Tech Architecture Agent: Technical planning and architectural decisions.</p>
</li>
<li><p>Main Coordinator: Project coordination and stakeholder management.</p>
</li>
</ul>
<p><strong>Development &amp; Implementation:</strong></p>
<ul>
<li><p>Frontend/Backend Developer Agents: Code implementation and feature development.</p>
</li>
<li><p>Tech Architecture Agent: Code reviews and technical guidance.</p>
</li>
<li><p><strong>Infrastructure Agent:</strong> Building required scripts and CI/CD pipelines for managing the application across different environments.</p>
</li>
<li><p>Quality Assurance Agent: Testing integration and quality validation.</p>
</li>
</ul>
<p><strong>Testing &amp; Validation:</strong></p>
<ul>
<li><p>Quality Assurance Agent: Comprehensive testing, performance validation, compliance checks, <em>using feature files for reference and tracking</em>.</p>
</li>
<li><p>Tech Architecture Agent: Security oversight and architectural validation.</p>
</li>
<li><p>Infrastructure Agent: Production monitoring and system validation.</p>
</li>
</ul>
<p><strong>Deployment &amp; Operations:</strong></p>
<ul>
<li><p>Infrastructure Agent: CI/CD, deployment automation, production support.</p>
</li>
<li><p>Documentation Agent: Deployment guides and operational documentation.</p>
</li>
<li><p>Quality Assurance Agent: Production testing and validation.</p>
</li>
</ul>
<p><strong>Maintenance &amp; Evolution:</strong></p>
<ul>
<li><p>Infrastructure Agent: Performance monitoring, system maintenance.</p>
</li>
<li><p>Tech Architecture Agent: Technical debt management and evolution planning.</p>
</li>
<li><p>Quality Assurance Agent: Ongoing quality and compliance monitoring.</p>
</li>
<li><p>Documentation Agent: Continuous documentation updates.</p>
</li>
<li><p><strong>Requirement Analyst Agent:</strong> Requirements evolution and backlog refinement.</p>
</li>
</ul>
<h3 id="heading-key-principles-of-agent-collaboration">Key Principles of Agent Collaboration</h3>
<ol>
<li><p><strong>Clear Handoffs:</strong> Each agent should clearly communicate deliverables to the next agent in the workflow.</p>
</li>
<li><p><strong>Feedback Loops:</strong> Agents should provide feedback to upstream agents when issues are discovered, <em>e.g., QA providing feedback to Requirement Analyst on testability</em>.</p>
</li>
<li><p><strong>Documentation:</strong> All agents should document their decisions and rationale for future reference.</p>
</li>
<li><p><strong>Quality Gates:</strong> Tech Architecture Agent reviews all significant outputs before integration.</p>
</li>
<li><p><strong>Continuous Improvement:</strong> Regular retrospectives to optimize agent collaboration.</p>
</li>
<li><p><strong>Consistent Documentation Standards:</strong> All agents must adhere to defined project documentation standards, including documenting task planning and changes in designated project files (e.g., <a target="_blank" href="http://TODO.md"><code>TODO.md</code></a>, <a target="_blank" href="http://CHANGELOG.md"><code>CHANGELOG.md</code></a> or similar).</p>
</li>
</ol>
<h2 id="heading-workflow-example">Workflow Example</h2>
<ol>
<li><p><strong>Requirement Analyst Agent</strong> Gathers and documents needs as clear functional descriptions and feature files.</p>
</li>
<li><p><strong>UI/UX Design Agent</strong> creates designs and specifications <em>based on these needs</em>.</p>
</li>
<li><p><strong>Frontend Developer Agent</strong> builds the user interface based on designs <em>and requirements</em>.</p>
</li>
<li><p><strong>Backend Developer Agent</strong> creates APIs and core logic <em>based on requirements</em>.</p>
</li>
<li><p><strong>Quality Assurance Agent</strong> tests all parts, <em>using feature files to guide testing and track results</em>.</p>
</li>
<li><p><strong>Tech Architecture Agent</strong> reviews code and overall system design.</p>
</li>
<li><p><strong>Infrastructure Agent</strong> sets up deployment and handles operations.</p>
</li>
<li><p><strong>Documentation Agent</strong> creates all project documents <em>from the outputs of other agents, including requirements</em>.</p>
</li>
<li><p><strong>Main Coordinator</strong> guides the whole process and makes key decisions, <em>using the Requirement Analyst for planning and priorities</em>.</p>
</li>
</ol>
<p>This structure ensures comprehensive coverage of all development aspects while maintaining clear responsibilities and efficient collaboration.</p>
<h2 id="heading-future-enhancements-amp-community-collaboration">Future Enhancements &amp; Community Collaboration</h2>
<p>This flexible agentic structure provides a robust foundation, but the journey of AI-driven software development is continuously evolving. As capabilities advance, we envision further specialization and refinement within these roles. For instance, the Quality Assurance Agent could potentially be specialized into distinct agents for:</p>
<ul>
<li><p><strong>Quality Testing:</strong> Focusing purely on functional and non-functional testing.</p>
</li>
<li><p><strong>Security Testing:</strong> Dedicated to vulnerability assessments and security compliance.</p>
</li>
<li><p><strong>Performance Testing:</strong> Concentrating on load, stress, and scalability validations.</p>
</li>
</ul>
<p>Similarly, the broad responsibilities of the Tech Architecture Agent might lead to the emergence of a dedicated <strong>Code Reviewer Agent</strong>, ensuring even more granular and consistent code quality checks.</p>
<p>We believe this framework is a living document, benefiting immensely from real-world application and diverse perspectives. We invite you to contribute your thoughts, experiences, and suggestions. How do you see these roles evolving? What other specialized agents might be crucial for future development workflows? Share your insights and help us collectively refine this blueprint for the next generation of software engineering!</p>
<h2 id="heading-platform-implementation-notes">Platform Implementation Notes</h2>
<p>This structure can be adapted for various AI development platforms:</p>
<ul>
<li><p><strong>Claude Code:</strong> Use as sub-agents with the main Claude instance as coordinator</p>
</li>
<li><p><strong>OpenAI GPTs:</strong> Implement as custom GPTs with defined roles and handoff protocols</p>
</li>
<li><p><strong>Microsoft Copilot:</strong> Integrate as specialized AI assistants within development workflows</p>
</li>
<li><p><strong>Custom AI Platforms:</strong> Adapt prompts and workflows to match platform-specific capabilities</p>
</li>
<li><p><a target="_blank" href="http://All-Hands.dev"><strong>All-Hands.dev</strong></a><strong>:</strong> Utilize its capabilities for structured collaboration and project management.</p>
</li>
<li><p><strong>Hybrid Teams:</strong> Mix human specialists with AI agents based on project requirements</p>
</li>
</ul>
<p>The key is maintaining the role definitions, responsibilities, and interaction patterns regardless of the underlying AI platform or implementation approach.</p>
]]></content:encoded></item></channel></rss>