Agentic

Building for Agentic AI - Agent SDKs & Design Patterns

The true value of AI agents lies in loops and self-correction rather than raw reasoning power.

AI Practice

11 Sep 2025 • 27 min read

Introduction and Scope
Agentic Workflow Pattern
HITL (Human-in-the-Loop) Design
Is this Agentic AI or just Agentic Workflows?
Agent SDK Interoperability: A2A and MCP
LLM Provider Support
Agent Conversation Tracing and Debugging
Ecosystem, Vendor Lock-in and Others
Which SDK should I use?

1. Introduction and Scope

Who is This For?

This evaluation is designed for developers, architects, product managers, and technologists who are looking to build agentic systems, whether you’re exploring options for your next project, evaluating SDKs for team adoption, or simply aiming to deepen your understanding of agentic workflows and capabilities.

Which SDKs Are We Looking At, and Why?

For our methodology, we consider the usage of the SDKs on how well they support the construction of agentic systems, via metrics such as the range of agentic design patterns they enable, as well as developer-centric features like tracing and debugging.

This approach is designed to be extensible and reusable, providing a goal-oriented framework that can be applied consistently to assess any SDK, not just the ones included in our current analysis.

Since we work fairly extensively with the 3 major cloud providers (Azure, AWS, Google) across WOG, we included their native SDKs. OpenAI and LangChain SDKs are also included as reference points given their widespread adoption globally.

For better clarity, here is the version of each SDK we use in this blog post:

What will not be covered?

We will not be deep diving into agent implementation code since examples are abundant in the official documentation as well as around the internet.

Security & Safety Disclaimer

This article focuses on design patterns and developer ergonomics; it does not cover security, safety, or compliance controls for AI agent systems. Topics such as data governance, authentication/authorization, secrets management, PII handling, prompt-injection/jailbreak defenses, red-teaming, content moderation, auditability, and regulatory requirements are intentionally out of scope. Please apply your organisation’s security review process before any production use — treat this as a technical comparison, not a security endorsement.

2. Agentic Workflow Patterns

Before we discuss the SDK capabilities, we should look at the foundational patterns that shape how agents operate in practice. In this section, we will go through six common agentic workflow patterns: Sequential Pipeline, Planner-Decider (Orchestrator/Handoff), Graph/DAG (Non-Linear Workflow), Supervisor-Worker (Hierarchical), Broadcast / Federated and Agent-as-Tool. These patterns provide useful mental models for understanding the different ways agents can be structured and coordinated.

Sequential Pipeline Pattern

In a Sequential Pipeline, agents are arranged in a linear chain: Each agent’s output feeds directly into the next agent in order. This pattern is ideal when tasks must happen in a strict sequence, with each step building on the previous one.

Imagine a process that needs to handle a lot of PDFs files, summarise them, identify key entities (names, dates, topics), then arrange them in proper folder structure. You could design an agentic workflow like this: A PDF goes through a Summariser Agent, then its summary goes to an Entity Extractor Agent, then extracted entities go to a Document Classifier Agent, and finally the classification goes to a File Organiser Agent. Each agent adds to or transforms the data for the next step. This ensures a step-by-step refinement of the document.

Planner-Decider (Orchestrator/Handoff) Pattern

The Planner-Decider pattern features an orchestrator agent that plans or routes tasks to other agents best suited to execute them. One agent “decides” what needs to be done or who should do it, rather than a fixed chain. This often manifests as a handoff: the planner agent hands off control to a specialist agent mid-workflow when appropriate. It’s useful for dynamic task delegation and conditional workflows.

Now, let’s use the document processing as an example again with slight differences. Imagine you have to handle files in these 2 scenarios by using the same agent workflow:

Scenario A: You have a few phone photos of the receipt and want the application to extract the information and place this photo in a proper folder.

Scenario B: You have a 40-page employment contract PDF, and you want the application to run policy checkers due to potential risk clauses, redact the PII (Personal identifiable Information), then provide the summary and save the final document properly.

It seems that you have to design 2 sequential pipelines to handle these 2 workflows, but in fact, it can be done by a single Planner-Decider design pattern:

Cast of agents

Coordinator (Planner): decides the path; aggregates final result
OCR Agent: turns scans/images into text
PII Redactor: masks personal data
Summariser: produces brief summary
Extractor: pulls structured fields (e.g., invoice total, vendor)
Classifier: labels doc type (invoice/contract/resume/other)
Policy Checker: flags risky terms in contracts
File Organiser: move files to the proper folder

How the planner decides

If scanned/image-based → call OCR first.
If it contains PII (names, emails, SSNs) → call PII Redactor before storing/forwarding.
Always call Classifier to know the doc type.
If invoice → call Extractor (vendor, date, amount) → optional Summariser.
If long (>10 pages) → Summariser before anything expensive, to give a quick preview.
If contract → Policy Checker (risk clauses) → Summariser.
Aggregate results → return final package (clean text + type + key fields + summary + flags).

Path walk-throughs

The application receives mixed documents (invoices, contracts, resumes). A single Coordinator (Planner) Agent looks at each document and decides which specialists to call and in what order. Specialists don’t call each other, only the planner does the routing.

Scenario A:

Input: A phone photo of a receipt (image), 1 page.

Planner path: OCR → Classifier → Extractor → File Organizer

Why: It’s an image (needs OCR). The classifier says “invoice/receipt.” Extractor gets totals. No PII beyond business info; doc is short, so no summary.

Scenario B:

Input: Native PDF, 40 pages, includes names/emails.

Planner path: Summariser (quick preview) → Classifier → PII Redactor → Policy Checker → Summariser (final, now on redacted text) → File Organiser

Graph/DAG (Non-Linear Workflow) Pattern

A Graph/DAG workflow generalizes the pipeline by allowing branching and merging of agent paths. Instead of a single line, the control flow forms a directed acyclic graph (DAG): multiple agents can run in parallel on different subtasks, and their results can converge into subsequent agents. This pattern suits complex tasks where some steps can happen concurrently or where there are conditional branches.

Let’s take the document processing workflow again as an example: Consider processing a document by branching the workflow: a Summariser Agent and an Entity Extractor Agent operate in parallel on the same document (one produces a summary while the other pulls out structured data). Their outputs are then merged and passed to a Document Classifier Agent, which uses both the summary and extracted entities to classify the document. Finally, the classification goes to an Organiser Agent. This forms a graph: the document feeds into two parallel agents, then their two outputs feed into one agent.

Supervisor-Worker (Hierarchical) Pattern

The Supervisor-Worker pattern (a special case of hierarchy) involves a primary supervisor agent overseeing one or more worker agents. The supervisor manages the high-level goal, delegates sub-tasks to workers, and integrates or verifies their outputs. Unlike the planner-decider which often hands off completely, a supervisor might remain in the loop, coordinating multiple workers and possibly performing a final review or decision. This resembles a manager and team relationship. Let’s take the customer support workflow as an example:

Cast of agents

Supervisor agent:

Support Lead (owns goals, routing, reviews)

Worker agents:

Intent Classifier — tags each message (billing, tech, password, complaint…)
Account Lookup Agent — pulls plan, region, past tickets from CRM
Knowledge Searcher — finds the best help-center article or macro
Draft Responder — writes a tailored reply
Policy Checker — enforces refund/credit limits, legal phrasing
Tone & QA Editor — fixes clarity, empathy, grammar
SLA Scheduler — sets follow-ups, escalates if deadlines risk being missed

How it runs (Supervisor stays in the loop)

Intake & plan: Support Lead ingests a batch of emails and asks:

Intent Classifier → “Label each, add urgency score.”
Account Lookup → “Attach customer context for each ticket.”

2. Parallel work per ticket: For each ticket:

Knowledge Searcher finds 1–2 relevant articles.
Draft Responder writes a reply using the article + customer context.

3. Supervisor review & checks: Support Lead bundles outputs and calls:

Policy Checker → “Is refund amount within tier limits? Any restricted promises?”
Tone & QA Editor → “Make it clear, empathetic, concise (≤180 words).”

4. Revision loop: If Policy Checker flags an issue, Support Lead sends it backto Draft Responder:

“Remove unconditional refund; offer troubleshooting first + partial credit option.”
Lead repeats until checks pass.

5. Finalise & logistics:

The Support Lead approves the reply.
SLA Scheduler sets a 48-hour follow-up (or escalates high-urgency cases).
The ticket is updated in CRM with resolution notes and linked articles.

Broadcast / Federated Pattern

The Broadcast / Federated pattern fans out the same input to multiple peer agents at once, then fans in their independent results to a central Aggregatorthat selects, votes, or synthesises the outcome. Peers do not depend on each other’s outputs; each works in parallel on the identical request. This is ideal when you want coverage, redundancy, diversity, or speed (e.g., take the best price, the fastest acceptable answer, or a majority vote), without building inter-step dependencies like a pipeline or graph. Let’s take a chicken rice delivery workflow as an example:

Cast of agents

Coordinator:

Order Aggregator (collects quotes, normalises fields, ranks, selects)

Peers (receive the same request):

Grab Food Agent — searches chicken rice options, returns {restaurant, items, total_price, ETA_min, delivery_fee, rating, promo}
Food Panda Agent — same schema
Deliveroo Agent — same schema
Direct Restaurant Agent(s) — restaurants with in-house delivery and their own APIs/menus

How it runs (Broadcast fan-out, fan-in)

Intake & constraints: Order Aggregator receives:

Dish: “chicken rice” (hawker or restaurant)
Address / postal code
Budget ≤ S$18, ETA ≤ 35 minutes, rating ≥ 4.2
Preferences (white vs roasted, extra chili, no spring onion), and any voucher rules

Fan-out (parallel queries): The Aggregator broadcasts the exact same query to all peers concurrently. Each peer independently searches its catalog, applies stock/availability, and returns a structured quote. No peer waits on another.

Fan-in & normalisation: The Aggregator collects responses until a timeout (e.g., 2–3s):

Normalise fields (price to S$, unify item names, standardise ETA).
Dedupe restaurants that appear on multiple platforms (prefer lower fee / better ETA).
Filter by constraints (budget/ETA/rating).
Score & rank.

Agent-as-Tool Pattern

The Agent-as-Tool pattern treats one agent as a callable tool for another agent. In other words, a primary agent can invoke a secondary agent’s capabilities just like it would call an API or function, rather than handing off full control. This pattern effectively nests agents: the top-level agent remains in charge of the interaction, and whenever it needs a specific subtask done, it calls a subordinate agent (providing it some input) and waits for the result to incorporate into its own reasoning. This approach keeps a single coherent “thread of conversation” while still leveraging multiple specialised agents. Here we provide an example for dinner planning.

User asks

“Book a nice birthday dinner next Saturday at 7pm for 6 people, near Orchard. Keep it under SGD $40 per person, and make sure there are vegetarian options.”

Cast of agents

Restaurant Finder — looks up places that fit location, price, cuisine, and ratings.
Menu & Diet Checker — scans menus to confirm vegetarian choices and typical spend.
Reservation Helper — checks table availability at 7pm for 6 and drafts a booking message.

How it runs (one clean path)

Chatbot → Restaurant Finder: Returns 5 candidates near Orchard with ~$25–$38/pax and good reviews.
Chatbot → Menu & Diet Checker on those 5: Confirms 3 have solid vegetarian mains (not just salad) and fit the budget.
Chatbot → Reservation Helper on the top pick: Finds a 7:00 pm slot for 6; drafts “Birthday dinner” note and seating preference.
Chatbot shows you:

The chosen restaurant (why it was picked)
1–2 backups
The ready-to-send booking message

Agent SDK Support in Various Workflow Patterns

The table summaries workflow-pattern coverage by SDK.

References

LangGraph:

OpenAI Agents SDK:

Google ADK:

AWS Strands SDK:

Microsoft 365 Agent SDK:

3. HITL (Human-in-the-Loop) Design

Human-in-the-loop (HITL) patterns let humans review, approve, or override an AI agent’s decisions before execution. In practice, this often means pausing an agent’s workflow at critical steps (e.g. before a risky tool call) so a person can intervene, or explicitly handing off control to a human for approval or additional input. In general, there are four types of HITL patterns:

Approve or Reject

Pause the agent workflow before a critical step, such as an API call, to review and approve the action. If the action is rejected, you can prevent the agent workflow from executing the step, and potentially take an alternative action. Let’s take the previous document process as the example here: imagine the Document Classifier proposes a folder path & filename (e.g. Legal/Contracts/2025/Acme_MSA_2025–07–22.pdf) for your approval before saving it.

Review and Edit

A human can review and edit the temporary deliverable of the agent in the workflow. This is useful for correcting mistakes or updating the deliverable with additional information. Let’s take document processing as an example here: Summariser returns a draft, and you edit the summary by adding some key notes, then the updated summary is persistent to pass to Entity Extractor for the next step.

Review Before Tool Calls

Similar to the “Review and Edit” pattern, but it’s to verify a tool that the agent is going to use. This is particularly critical in applications where the tool calls requested by the agent may be sensitive or require human oversight. Here we take the previous dinner planning agent as an example: Before the Reservation Helper’s “book table” call, a human review is in place to decide whether to go for backup plans.

Multi-turn Conversation in a Multi-agent Setup

A multi-turn conversation involves multiple back-and-forth interactions between an agent and a human, which can allow the agent to gather additional information from the human in a conversational manner. This design pattern is useful in an LLM application consisting of multiple agents. Let’s take the dinner planner workflow as an example again. Here, we need to make the Chatbot more aware of how human preferences evolve (i.e., “quiet ambience > cheapest price”). HITL becomes an ongoing dialogue, not a single gate.

Agent SDK Support in various HITL Pattern

The table compares agent SDK support across HITL patterns.

References

OpenAI Agent SDK:

Human in the loop | OpenAI Agents SDK

Google ADK:

LangGraph:

AWS Strands Agent SDK:

Example Tools Package — Strands Agents

4. Is this Agentic AI or Just Agentic Workflows?

Agentic AI is typically characterized by its level of autonomy in determining the path of operations. Some of these patterns like Sequential Pipeline are often just agentic workflows, whereas Graph/DAG and Broadcast/Federated patterns can be agentic AI if the decision paths are dynamic and autonomous — i.e. not always if-else.

Can HITL patterns also be Agentic AI?

Refer to the picture above.

The consideration for level of autonomy still applies. In this context, it depends on the role of the human. If the human is there for approval and/or goal-setting, it can be agentic AI. However, if the human decides which agents to route the flow to, then it’s just an agentic workflow.

5. Agent SDK Interoperability: A2A and MCP

The Agent-to-Agent (A2A) protocol (launched April 2025) is an open, vendor-neutral JSON-RPC-over-HTTP standard for agents to discover, communicate, and collaborate. It uses plain HTTP/JSON so integrating A2A is similar to implementing a REST or gRPC API. Many AI agent frameworks also use Anthropic’s Model Context Protocol (MCP) to connect agents with external tools or data. We compare the agent SDKs on their support for A2A and common integration methods (REST APIs, MCP tools, gRPC, etc.), noting which capabilities are out-of-the-box and which require custom work.

OpenAI Agent SDK

OpenAI’s Agents SDK natively supports the MCP for tool integration. This means out-of-the-box OpenAI Agents can use any MCP-based tool (HTTP APIs, databases, AWS/Stripe services, etc.) by registering them. However, the OpenAI Agents SDK has no built-in A2A support. To connect an OpenAI-based agent to an A2A ecosystem, developers must write custom integration. See A2A — (Agent-to-Agent) Protocol Support for further details.

Google ADK

By default, ADK agents use the MCP to attach external tools, and ADK provides easy MCP integration (e.g. MCPToolset classes). Crucially, ADK has native A2A support. For example, calling to_a2a(root_agent) on an ADK agent spins up an HTTP server (uvicorn/FastAPI) that implements the A2A server interfaces. See A2A Quickstart (Exposing) — Agent Development Kit for more details. In short, A2A protocol support is built-in (here is the sample A2A client/server code), and MCP-based tools are first-class.

AWS Strands Agents SDK

Strands integrates MCP by default: it provides an MCPClient and comes with many pre-built MCP servers and tools (e.g. for AWS, HTTP, file ops), see Introducing Strands Agents, an Open Source AI Agents SDK for further details. As of Strands 1.0 (July 2025), A2A is fully supported. Strands supplies an A2AServer class: for example, one can write a2a_server = A2AServer(agent=my_agent) and a2a_server.serve() to publish the agent over SSE (Server-Sent Events), see Agent2Agent (A2A) — Strands Agents for more information.

LangGraph (LangChain)

LangGraph is designed to orchestrate complex agent workflows, but it does not include A2A connectivity by default. Out-of-box it supports persistent, multi-tenant workflows via its server, but linking LangGraph agents to other systems (A2A networks, message buses, etc.) typically requires custom connectors. See Building an A2A Currency Agent with LangGraph for further details.

LangGraph also supports significant integrations with the Model Context Protocol (MCP) in two ways

LangGraph Platform Now Supports MCP: LangGraph Platform agents now automatically expose an MCP endpoint. This lets developers use those agents as tools from any MCP-compatible client over streamable HTTP without extra code or infrastructure.
MCP Adapters for LangChain and LangGraph: The new langchain-mcp-adapters package (Python & JavaScript) converts MCP tools into a format compatible with LangChain and LangGraph. This lets developers easily plug hundreds of existing MCP tool servers into their LangGraph agents.

Microsoft 365 Agent SDK

Microsoft’s 365 Agent SDK is aimed at enterprise chatbot/agent scenarios. It provides frameworks to build agents that integrate with Microsoft 365, Teams, Copilot Studio, Web Chat, and even third-party channels (Slack, Twilio, Facebook Messenger). However, it has no built-in A2A or MCP support. However, the SDK can integrate with Microsoft Semantic Kernel to achieve A2A and MCP support. See Leveraging Microsoft 365 Agents SDK with Semantic Kernel for Enhanced Multichannel AI and Guest Blog: Building Multi-Agent Solutions with Semantic Kernel and A2A Protocol for more information.

Agent SDK Interoperability Matrix: A2A and MCP

This table summaries A2A and MCP interoperability across agent SDKs.

6. LLM Provider Support

Here, we examine the default supported LLM Providers of each SDK and whether it can be connected to LiteLLM as a unified proxy model provider.

OOTB Model Service Provider Support

# = via OpenAI API-compatible models servers that aren’t LiteLLM

^ = via LiteLLM, meaning it leverages the LiteLLM library as a translator to standardise all to OpenAI API formats

✅ indicates an OOTB wrapper class that supports direct authentication with the service (e.g. a tick on Vertex AI means the SDK supports usage of Google ADC for access to Vertex AI directly)

LiteLLM Integration with All Five SDKs

LiteLLM can be integrated with all 5 SDKs. The sample code and the screenshot are provided in the public GitHub repo here.

LiteLLM compatibility matrix across the five SDKs.

7. Agent Conversation Tracing and Debugging

Here we compare the developer experience for agent conversation tracing and debugging. Our evaluation focuses on: trace granularity (messages, tool calls, and state transitions), built-in viewers vs. CLI/log workflows.