Jahanzaib

Field guide · 9 patterns

AI agent architecture patterns, drawn from systems I shipped

The patterns I reach for when I build agents for clients. Each one has a diagram, when to use it and when not to, how it fails, how many model calls it costs per task, and the guardrails it needs. Every pattern points to the case studies where I used it.

Find my patternCompare all nine
  • 11 case studies mapped
  • Diagrams in the HTML
  • Sources checked Oct 10, 2026
Agent architecture patterns from code driven to model drivenEight patterns ordered by how much the model decides the path, from Event driven workflow with one AI step to Orchestrator with sub agents as tools, each with its model calls per task. A human approval gate can sit on any of them.CODE DECIDES THE PATHworkflows: predictable, cheap, easy to debugMODEL CALLS PER TASK07 One AI step1 per event02 Prompt chainS03 RouterR + specialist06 Retrieval (RAG)1 + Q09 Voice pipelineN + T08 Evaluator loop2 × R01 Single agentT + 104 Orchestrator1 + Σ(Tᵢ + 1) + 1THE MODEL DECIDES THE PATHagents: flexible, slower, costlier to run and debug05 Approval gate fits on any of them0 extra
Ordered by how much the model decides the path. The placement is my judgement; the split between workflows and agents is from Anthropic.

Start here

Start with the cheapest pattern that works

Most systems I ship are workflows with one or two model steps, not autonomous agents. Anthropic makes the same point in its guide to building agents: start with the simplest approach, and add agentic complexity only when it pays for itself, because agentic systems trade latency and cost for better task performance. The patterns below run roughly in that order of cost.

Real systems combine them. A voice agent is a single agent wrapped in audio. An underwriting system is a pipeline with an approval gate on top. Read the pattern you need, then the layers it calls for.

Diagram key

  • Model call
  • Plain code
  • Tool or API
  • Person
  • Data store
  • Input or output
  • Fallback or human path

Which pattern fits

Answer a few questions, get a starting point

Seven questions at most. The first ones pick the base pattern; the last three add the layers most production systems need.

0 of 5 answered

What starts the task?
Could you draw the steps as a flowchart today?

Phone calls skip this: the voice pipeline is the outer shape either way.

Can an action move money, change records or reach a customer?
Must the answer come from your own documents?
Can you write down what a good output looks like, and is quality worth paying twice for?

Your starting point

Answer the first questions and the base pattern appears here. The layers light up as you answer the rest.

All nine, matches lit

The logic is a plain decision tree, not a model: the trigger and the shape of the steps pick the base pattern, and the last three answers add layers.

Pattern 01

Single agent with tools

One model in a loop: pick a tool, read the result, decide again.

This is what most people mean by an AI agent. One model holds the conversation, chooses from a small set of tools, and keeps going until it can answer. It is the pattern I start from when the steps cannot be written down in advance but the job stays inside one domain.

Single agent with tools: architecture diagramA request reaches one agent. The agent calls one tool at a time, reads the result, and loops until it can answer or hits a turn limit set in code.RequestAgentmodel picks next stepAnswerToollook up orderToolupdate recordToolsend messagedoneloops until doneor max turns hit
A request reaches one agent. The agent calls one tool at a time, reads the result, and loops until it can answer or hits a turn limit set in code.

Use it when

  • The next step depends on what the last tool returned, so you cannot hard code the path
  • The job lives in one domain with a handful of tools, say orders, tracking and returns
  • A person is in the conversation and expects the system to figure out what they need

Skip it when

  • You can write the steps down as a flowchart. Code it as a workflow instead
  • The agent would need more than about ten tools from unrelated domains. Split it
  • Every action is irreversible and high value. Put an approval gate in front first

How it fails, and what I do about it

Loops on a tool that keeps failing, burning calls without progress
A turn limit in code, error messages the model can act on, and a stop after two identical failures
Picks the wrong tool because two tool descriptions overlap
Fewer tools with distinct names and descriptions; split the agent before adding a tenth tool
Context grows every turn until answers get worse and each call costs more
Trim tool results down to the fields the next step needs

Cost profile

calls = T + 1

T is the number of tool calls the agent makes before it answers.

Three tool calls means four model calls. Each call resends the growing conversation, so input tokens rise every turn.

What moves the bill

  • Tool turns per task
  • Conversation length resent each turn
  • The turn limit you set

Guardrails it needs

  • A hard turn limit enforced in code, not in the prompt
  • Least privilege tools: read by default, writes scoped to one record
  • Validate tool arguments before anything executes
  • A spend cap per user and per day
  • A trace of every tool call and its result

Where I shipped it

What the framework docs say3 sources

Pattern 02

Prompt chain with gates

Fixed steps in a fixed order, with code checks between them.

Not an agent at all, and often the better build. Each step is one model call with a narrow job, and plain code checks the output before the next step runs. Document processing lives here: extract, classify, compare, summarize.

Prompt chain with gates: architecture diagramA document arrives and passes through fixed steps in order: text extraction, a classification call, a gate check written in code, a comparison call, and a summary call. The result lands in a reviewer queue. If the gate fails, the run stops and a human is flagged.Document arrivesExtract textClassify sectionsmodel call 1Gate checkcode, not a modelCompare to rulesmodel call 2Write summarymodel call 3Reviewer queuepassGate fails: stop the runand flag a human
A document arrives and passes through fixed steps in order: text extraction, a classification call, a gate check written in code, a comparison call, and a summary call. The result lands in a reviewer queue. If the gate fails, the run stops and a human is flagged.

Use it when

  • The task always runs the same steps in the same order
  • Each step is easier for a model when it does one narrow thing
  • You need the same input to produce the same shape of output every time

Skip it when

  • The steps change with the input. Use a router or a single agent
  • One model call can do the whole job well. Do not split it for the sake of it
  • Latency matters more than accuracy, since steps add up

How it fails, and what I do about it

An early step fails quietly and every later step builds on the mistake
A gate after each step that checks structure and completeness in code
A new document type breaks the fixed chain
Route unknown types to a human instead of forcing them through
Latency adds up step by step
Run independent steps in parallel and keep each prompt short

Cost profile

calls = S

S is the number of model steps, fixed when you design the chain.

Three model steps means three calls on every document. The bill is a multiplication you can do before you build.

What moves the bill

  • Steps in the chain
  • Document length sent to each step
  • Retries after a gate fails

Guardrails it needs

  • Schema validated output at every step
  • Gates that check structure in code, never another prompt asking if it looks fine
  • Stop and flag on a failed gate instead of guessing
  • Every prompt versioned with the step it belongs to

Where I shipped it

What the framework docs say2 sources

Pattern 03

Router plus specialists

Classify first, then hand the request to the one path built for it.

A cheap first step decides what kind of request this is, and each kind gets its own prompt, tools and rules. The router does not have to be a large model. A small model, rules, or a trained classifier all count.

Router plus specialists: architecture diagramAn incoming request goes to a router, which can be a small model, rules or a trained classifier. The router sends it down exactly one path: specialist A, specialist B, or a human queue when confidence is low.Incoming requestRoutersmall model, rules or MLSpecialist Aown prompt, toolsSpecialist Bown prompt, toolsHuman queuelow confidenceOne path runs per request
An incoming request goes to a router, which can be a small model, rules or a trained classifier. The router sends it down exactly one path: specialist A, specialist B, or a human queue when confidence is low.

Use it when

  • Requests fall into distinct categories that need different handling
  • Tuning one prompt for every category makes some categories worse
  • Easy requests can go to a cheaper model and hard ones to a stronger one

Skip it when

  • Categories blur together and the router would be guessing
  • One prompt already handles every category well
  • Requests change category halfway through. A single agent copes better

How it fails, and what I do about it

Ambiguous requests get routed to the wrong specialist
A confidence threshold and a fallback route that can handle anything, slowly
Categories drift as the business changes
Review a sample of routed requests every month and update the rules or retrain
Specialists copy logic from each other and drift apart
Shared tools and policies, separate prompts

Cost profile

calls = R + specialist

R is 1 for a model router and 0 for rules or a trained classifier.

A small model router plus a one call specialist is two calls, and the router can run on the cheapest model you have.

What moves the bill

  • Router model choice
  • Which specialist runs
  • Share of requests on the fallback path

Guardrails it needs

  • A confidence threshold with a human or fallback route
  • Log the route chosen and the score behind it
  • A labeled sample of real requests to test the router before every change
  • Specialists only get the tools their category needs

Where I shipped it

My published router is a trained ML model routing leads, not an LLM triage agent. The Anthropic post counts both as routing.

What the framework docs say3 sources

Pattern 04

Orchestrator with sub agents as tools

A manager model plans, delegates bounded jobs to sub agents, and owns the final answer.

The heaviest pattern on this page. One orchestrator breaks the task down, calls specialist sub agents the way a single agent calls tools, and merges what comes back. Plan and execute is a close cousin: the plan is written first, then executed step by step. I only reach for either when the subtasks genuinely cannot be known in advance.

Orchestrator with sub agents as tools: architecture diagramA task reaches an orchestrator model that plans, delegates to three sub agents as if they were tools, and merges their results. Each sub agent runs its own tool loop. The exceptions sub agent escalates to a human with full context.TaskOrchestratorplans, delegates, mergesResultSub agentvalidateSub agentrouteSub agentexceptionsHumangets full contextEach sub agent runsits own tool loop,so calls multiply
A task reaches an orchestrator model that plans, delegates to three sub agents as if they were tools, and merges their results. Each sub agent runs its own tool loop. The exceptions sub agent escalates to a human with full context.

Use it when

  • The subtasks depend on the input and cannot be predicted
  • Each subtask needs its own tools, rules and context that would overload one agent
  • One component has to own the final answer and combine several results

Skip it when

  • You can list the subtasks in advance. Orchestrate in code, it is cheaper and easier to debug
  • A single agent with five tools would do the job
  • Cost per task has a tight ceiling

How it fails, and what I do about it

Context is lost at the handoff, so a sub agent solves the wrong problem
Typed task briefs between agents rather than free text
Cost and latency multiply with every sub agent loop
A budget per task, and code orchestration wherever the steps are known
Nobody can say which agent caused a bad result
A trace ID that follows the task through every agent

Cost profile

calls = 1 + Σ(Tᵢ + 1) + 1

One planning call, each sub agent i runs Tᵢ tool calls plus its own answer, and one merge call.

Three sub agents with two tool calls each: 1 + 9 + 1 = 11 model calls for one task.

What moves the bill

  • Number of sub agents per task
  • Tool turns inside each sub agent
  • Context passed at each handoff

Guardrails it needs

  • Tool level guardrails, because checks on the manager agent do not cover delegated work
  • One budget per task across all sub agents
  • Clear responsibility boundaries, one owner per decision
  • An exception path to a human with the full context attached
  • End to end tracing across every agent

Where I shipped it

What the framework docs say4 sources

Pattern 05

Human approval gate

The agent proposes, code decides the risk, a person approves what matters.

Not a standalone architecture but a layer that sits on any of the others. Code, not the model, decides which actions are risky. Safe ones run; risky ones pause with their state saved until someone approves. This is how an agent gets near money, records and customers without a bad day.

Human approval gate: architecture diagramAn agent proposes an action. A policy check written in code decides the risk. Low risk actions are auto approved and executed. Anything else pauses with its state saved until a human approves or rejects it. Approved actions execute with an audit log; rejected ones go back to the agent with a reason.Agent proposesrefund, write, sendPolicy checkcode decides the riskAuto approvewithin policyPause, save stateHuman reviewsapprove or rejectExecute and logaudit trail keptlow riskneeds reviewyesReject: the reason goes backto the agent, nothing runs
An agent proposes an action. A policy check written in code decides the risk. Low risk actions are auto approved and executed. Anything else pauses with its state saved until a human approves or rejects it. Approved actions execute with an audit log; rejected ones go back to the agent with a reason.

Use it when

  • An action moves money, changes records or reaches a customer
  • Compliance needs a named person and an audit trail on each decision
  • You are early in a rollout and still learning what the agent gets wrong

Skip it when

  • Every action is reversible and low stakes. Review a sample afterwards instead
  • Nobody is staffed to respond quickly, so the queue would stall the business
  • The volume is so high that reviewers would rubber stamp

How it fails, and what I do about it

Reviewers rubber stamp because everything needs approval
Gate only actions that move money, change records or reach customers
Paused runs are lost when the server restarts
A durable checkpoint store, never process memory
The approval queue becomes the bottleneck
Timeouts, escalation, and auto approve rules for the safe majority

Cost profile

calls = 0 extra

The gate is code plus a person. It adds waiting time, not model calls.

An agent that needed four calls still needs four. The task now takes as long as the reviewer takes to respond.

What moves the bill

  • Share of actions that need review
  • Reviewer response time
  • State storage while runs are paused

Guardrails it needs

  • The risk policy lives in code, never in the prompt
  • Fail closed: anything the policy cannot read goes to review
  • Durable state so a paused run survives a restart
  • An audit log of who approved what, and when
  • A timeout and escalation if nobody responds

Where I shipped it

What the framework docs say3 sources

Pattern 06

Retrieval grounded agent

Answer only from your own documents, cite them, and hand off when unsure.

The model is not asked to know anything. It is asked to find the right passages in your documents and answer from them, with the source attached. Most chatbots that fail in production fail at retrieval, not at the model.

Retrieval grounded agent: architecture diagramA question triggers a hybrid search over the document index, combining vectors and BM25. Results are reranked and passed to the model, which answers only from those sources and cites them. A confidence check sends high confidence answers to the user with sources and low confidence ones to a human.QuestionHybrid searchvectors plus BM25Docs indexchunks, metadataRerankAnswer from sourcescites every claimConfidence checkAnswerwith sourcesHumanhandoffhighlow
A question triggers a hybrid search over the document index, combining vectors and BM25. Results are reranked and passed to the model, which answers only from those sources and cites them. A confidence check sends high confidence answers to the user with sources and low confidence ones to a human.

Use it when

  • The answer lives in your documents, tickets or knowledge base
  • Users need to check the source, not just trust the reply
  • The content changes often enough that fine tuning would always be stale

Skip it when

  • The answer needs live data from a system. Give the agent a tool instead
  • The whole corpus fits comfortably in one prompt and rarely changes
  • Nobody owns keeping the documents current

How it fails, and what I do about it

Retrieves the wrong chunk and answers confidently
Hybrid search plus reranking, and the source shown so users can check
Stale documents produce stale answers
Incremental reindexing and a content gap report
Instructions hidden in a document hijack the answer
Treat retrieved text as data, and never let it reach write tools

Cost profile

calls = 1 + Q

Q is extra query rewriting or retrieval rounds, zero for plain retrieval.

Plain retrieval is one model call plus one search and one rerank per question. An agentic version that searches twice adds a model call per round.

What moves the bill

  • Chunks stuffed into the prompt
  • Retrieval rounds per question
  • Index refresh jobs

Guardrails it needs

  • A citation on every answer
  • Answer only from retrieved text, and say so when nothing matches
  • A confidence threshold with human handoff
  • Retrieved documents treated as untrusted input
  • Reindex on change and log what is stale

Where I shipped it

What the framework docs say2 sources

Pattern 07

Event driven workflow with one AI step

A trigger, plain code, exactly one model judgement, and a threshold.

The pattern I ship most and the one clients ask for least. A webhook or schedule starts a workflow that is ordinary code, except for one step where a model scores, classifies, forecasts or extracts. A threshold decides what happens next. The model step can be an LLM or a trained ML model.

Event driven workflow with one AI step: architecture diagramA webhook or schedule starts the run. Plain code fetches and enriches the data. One model step scores, classifies or extracts. A threshold in code decides: above it, the workflow acts by routing, writing or alerting; below it, the item goes to a review queue.Webhook or scheduleFetch and enrichplain codeOne model stepscore, classify, extractThresholdcode, tunableActroute, write, alertReview queuebelow thresholdabovebelowExactly one model call per event
A webhook or schedule starts the run. Plain code fetches and enriches the data. One model step scores, classifies or extracts. A threshold in code decides: above it, the workflow acts by routing, writing or alerting; below it, the item goes to a review queue.

Use it when

  • Something happens in a system and needs one judgement call
  • Volume is high and cost per run has to be predictable
  • The output feeds a decision that a threshold can make

Skip it when

  • The task needs a back and forth with a person
  • The judgement needs several dependent steps. Use a prompt chain
  • No model is needed at all. Plain automation is cheaper

How it fails, and what I do about it

A duplicate event triggers a duplicate action
Idempotency keys on every run
Silent failure: events stop and nobody notices
Alert when expected events stop arriving
The threshold is set once and never revisited
Track false positives in the review queue and tune the number

Cost profile

calls = 1 per event

The model runs once; everything else is code.

10,000 events a month means 10,000 calls. Price one call and you have priced the month.

What moves the bill

  • Event volume
  • Input size per call
  • Model choice for the one step

Guardrails it needs

  • Idempotency so a retried event does not act twice
  • The threshold in config, so tuning needs no deploy
  • A dead letter queue for failures
  • Alerts on volume drops and error spikes

Where I shipped it

In these three the single step is a trained ML or vision model rather than an LLM. The shape is the same.

What the framework docs say2 sources

Pattern 08

Evaluator loop

One model drafts, another scores it against a written checklist, with a round cap.

Useful when quality is measurable and worth paying twice for. At runtime it is a generator and an evaluator passing a draft back and forth. Offline it is the same idea at a slower pace: real transcripts and low confidence answers reviewed every week, feeding prompt changes.

Evaluator loop: architecture diagramA task and a written checklist go to a generator model, which writes a draft. An evaluator model scores the draft against the checklist. If it passes, it ships. If not, feedback goes back to the generator. When the round cap is hit, the work goes to a human.Task and checklistGeneratorwrites a draftEvaluatorscores the checklistPass: ship itRound cap hitsend to a humandraftfixpassmax rounds
A task and a written checklist go to a generator model, which writes a draft. An evaluator model scores the draft against the checklist. If it passes, it ships. If not, feedback goes back to the generator. When the round cap is hit, the work goes to a human.

Use it when

  • You can write down what a good output looks like as a checklist
  • A first draft is usually close and a critique reliably improves it
  • Quality matters more than a second or two of latency

Skip it when

  • There is no clear way to judge the output
  • The first draft is already good enough most of the time
  • Latency or cost per task is tightly capped

How it fails, and what I do about it

Endless polishing: the loop never converges
A round cap and a pass threshold
The evaluator shares the generator blind spots
A different prompt, rubric or model, plus human spot checks
Cost doubles for gains nobody can measure
Use it only where quality is measured and worth the price

Cost profile

calls = 2 × R

R is the number of rounds until the evaluator passes the draft, capped in code.

A cap of three rounds means at most six calls. A first draft that passes costs two.

What moves the bill

  • Round cap
  • Pass rate on the first draft
  • Length of the draft resent each round

Guardrails it needs

  • A written checklist the evaluator scores against
  • A hard cap on rounds
  • The evaluator on a different prompt or model from the generator
  • Escalation to a human when the cap is hit
  • An offline eval set from real cases to catch drift

Where I shipped it

In these case studies the evaluation loop runs offline, on real transcripts and low confidence logs, rather than as a second model call on every request.

What the framework docs say2 sources

Pattern 09

Voice agent pipeline

Speech to text, an agent with tools, text to speech, on every turn of a phone call.

A single agent with tools, wrapped in audio. The architecture is simple; the difficulty is time. Every turn goes through telephony, transcription, the model, any tool calls and speech synthesis, and the caller hears every hop as silence.

Voice agent pipeline: architecture diagramA caller speaks on a phone line. Telephony streams the audio to speech to text. The transcript goes to an agent model with tools such as a CRM, calendar and listings. The reply goes through text to speech and the caller hears it. Every turn repeats the loop, so each hop adds delay the caller can hear.Callerphone lineTelephonySpeech to textstreamingAgentmodel plus toolsCRM, calendarlistings, bookingText to speechCaller hears replyEvery turn repeats this loop, so each hopadds delay the caller can hear
A caller speaks on a phone line. Telephony streams the audio to speech to text. The transcript goes to an agent model with tools such as a CRM, calendar and listings. The reply goes through text to speech and the caller hears it. Every turn repeats the loop, so each hop adds delay the caller can hear.

Use it when

  • Calls arrive when nobody can answer them
  • The conversation follows a known qualification or booking flow
  • The result has to land in a CRM or calendar while the caller is still on the line

Skip it when

  • Calls are rare, long and emotionally complex
  • The tools behind it are slow and cannot be made faster
  • You cannot record or transcribe calls under your consent rules

How it fails, and what I do about it

Talks over the caller or misses the end of their turn
Tune turn detection and handle barge in yourself
Each tool call adds silence on the line
Short filler responses, fast tools and prefetching the obvious data
Mishears names, numbers and addresses
Read it back and confirm before anything is written

Cost profile

calls = N + T

N is caller turns and T is tool calls across the call. Speech to text and text to speech run on every turn as well.

A 10 turn call with one booking lookup is about 11 model calls, plus 10 rounds of transcription and speech.

What moves the bill

  • Call length in turns
  • Tool calls per call
  • Speech and telephony billed per minute

Guardrails it needs

  • A latency budget per turn, measured end to end
  • Turn detection and interruption handling you own
  • Read back and confirm before booking or writing
  • Transfer to a human on request or after repeated failures
  • Recording and transcript retention that matches your consent rules

Where I shipped it

What the framework docs say2 sources

Side by side

All nine on complexity, latency, cost and debuggability

These are my relative ratings from building these systems, not benchmarks. Cost per task follows the model call formula on each row; your real bill depends on the model and the tokens per call.
  • 01Single agent with tools

    calls = T + 1

    Complexity
    Medium
    Latency
    MediumSeconds, grows with each tool turn
    Cost per task
    MediumT + 1 calls
    Debuggability
    Medium
  • 02Prompt chain with gates

    calls = S

    Complexity
    Low
    Latency
    LowFixed, sum of the steps
    Cost per task
    LowS calls, known in advance
    Debuggability
    Easy
  • 03Router plus specialists

    calls = R + specialist

    Complexity
    Low
    Latency
    LowOne extra hop before the work
    Cost per task
    LowRouter plus one specialist
    Debuggability
    Easy
  • 04Orchestrator with sub agents as tools

    calls = 1 + Σ(Tᵢ + 1) + 1

    Complexity
    Very high
    Latency
    Very highSlowest, sub agent loops add up
    Cost per task
    Very highPlan, every sub agent loop, merge
    Debuggability
    Very hard
  • 05Human approval gate

    calls = 0 extra

    Complexity
    Low
    Latency
    Very highMinutes to hours when a person must respond
    Cost per task
    Very lowNo extra model calls
    Debuggability
    Very easy
  • 06Retrieval grounded agent

    calls = 1 + Q

    Complexity
    Medium
    Latency
    LowSearch and rerank add a hop
    Cost per task
    LowOne call plus search
    Debuggability
    Medium
  • 07Event driven workflow with one AI step

    calls = 1 per event

    Complexity
    Very low
    Latency
    Very lowOne call, then code
    Cost per task
    Very lowOne call per event
    Debuggability
    Very easy
  • 08Evaluator loop

    calls = 2 × R

    Complexity
    Medium
    Latency
    HighEach round adds a draft and a review
    Cost per task
    HighTwo calls per round
    Debuggability
    Medium
  • 09Voice agent pipeline

    calls = N + T

    Complexity
    High
    Latency
    Very lowEach turn has to feel instant
    Cost per task
    MediumModel, speech and telephony per turn
    Debuggability
    Hard

Shipped, not demoed

How the patterns combine in real systems

Every one of the 11 case studies below is mapped from its own write up: the steps and the stack it lists. Most use more than one pattern.

Sources

Primary sources for every framework claim

Official documentation and the original guide, read on Oct 10, 2026. Framework APIs move fast; if a page has changed since, the link goes to the current version.
  1. 01Building effective agents

    Anthropic, published Dec 19, 2024, checked Oct 10, 2026

    https://www.anthropic.com/engineering/building-effective-agents

    The post now carries a note that much of the tooling it describes has changed since December 2024. The workflow and agent patterns it names are what I cite.

  2. 02LangGraph docs: Workflows and agents

    LangChain, checked Oct 10, 2026

    https://docs.langchain.com/oss/python/langgraph/workflows-agents

  3. 03LangGraph docs: Interrupts

    LangChain, checked Oct 10, 2026

    https://docs.langchain.com/oss/python/langgraph/interrupts

  4. 04CrewAI docs: Flows

    CrewAI, checked Oct 10, 2026

    https://docs.crewai.com/en/concepts/flows

  5. 05OpenAI Agents SDK: Agent orchestration

    OpenAI, checked Oct 10, 2026

    https://openai.github.io/openai-agents-python/multi_agent/

  6. 06OpenAI Agents SDK: Human in the loop

    OpenAI, checked Oct 10, 2026

    https://openai.github.io/openai-agents-python/human_in_the_loop/

  7. 07OpenAI Agents SDK: Guardrails

    OpenAI, checked Oct 10, 2026

    https://openai.github.io/openai-agents-python/guardrails/

  8. 08OpenAI Agents SDK: Running agents

    OpenAI, checked Oct 10, 2026

    https://openai.github.io/openai-agents-python/running_agents/

  9. 09OpenAI Agents SDK: Voice pipeline

    OpenAI, checked Oct 10, 2026

    https://openai.github.io/openai-agents-python/voice/pipeline/

  10. 10n8n docs: AI Agent node

    n8n, checked Oct 10, 2026

    https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/

Case study details come from my own write ups on this site. Most clients are under NDA, so they are described by industry and role, never by name, except Fig and Bloom.

Related

Not sure which pattern your system needs?

Bring the workflow you want to automate. I will tell you which pattern I would start with, what it costs per task to run, and where it is likely to break.

Book Meeting