Agentic AI & Multi-Agent Orchestration Workflows

Most agent stacks fail at the loop, not the model

The expensive mistake is wiring five specialist agents into a graph before you have decided how a single agent is allowed to think, call tools, and remember what happened. ReAct, plan-and-execute, and multi-agent “orchestration” are not progressive maturity levels. They are different control surfaces for the same problem: an LLM cannot observe the world except through tools, and every extra hop multiplies tokens, latency, and failure modes.

By the end of this piece you should be able to choose a reasoning loop for a given task shape, pick a tool protocol without confusing agent-to-tool with agent-to-agent, design state that survives a crash mid-run, and refuse multi-agent topologies that only look sophisticated.

ReAct is the default because observations are real

ReAct (Yao et al., 2022/2023) is still the right mental model for most production agents. The model emits a reasoning trace, requests an action, the runtime executes that action against a real tool or environment, and the observation is appended to context before the next thought. Reasoning without action hallucinates outcomes; action without reasoning fails to track goals or recover from exceptions. The paper’s contribution was showing that interleaving both beats either alone on QA, fact verification, and interactive decision tasks. arxiv

In modern APIs the Thought/Action/Observation text format is often hidden behind native tool calling. OpenAI-style function calling still implements the same loop: you declare tools with JSON schemas, the model returns a tool call instead of a final answer, your code runs it, you send the result back, and you repeat until the model stops requesting tools. Termination is no longer a pseudo-tool named finish(); it is an assistant turn with no tool_calls. docs.deno

I treat three harness rules as non-negotiable for ReAct:

• Cap steps hard (MAX_STEPS / recursion_limit). Without a ceiling, a stuck agent burns money forever.
• Never let the model write its own observations. In raw-text ReAct, stop generation before a fake Observation:; in native tool calling, only your runtime may emit tool-result messages.
• Deduplicate identical (tool, args) sequences. Looping on the same search query is the most common production pathology, and it is a harness bug more often than a model bug.

ReAct wins when the environment is uncertain, each observation can invalidate the next step, and you need mid-flight recovery. It loses when the task is long-horizon, mostly deterministic, and you are paying for a full reasoning pass on every tool hop while the transcript grows.

Plan-and-execute when the roadmap is the product

Plan-and-execute splits what ReAct interleaves. A planner produces an explicit multi-step decomposition first; executors then march through that plan, often with a cheaper model and sometimes with a small ReAct loop inside each step. The plan is inspectable before side effects start. That single property is why I prefer this pattern for anything compliance, ops, or finance-adjacent: a human can read the step list, reject it, or insert a gate before step three deletes a resource. prakashkagitha.github

The trade-off is structural, not aesthetic:

I would not run pure plan-and-execute on live customer chat where the user’s next sentence rewrites the goal. I would not run pure ReAct on a twenty-step migration checklist where early thrashing is more expensive than a planning call. Hybrid designs are normal: plan the phases, ReAct inside each phase, re-plan only when an executor returns a typed failure.

Reflexion (Shinn et al.) is the outer loop you add when outcomes are verifiable. After a failed trial, the agent writes a verbal critique into an episodic buffer and retries with that critique in context. The paper reports 91% pass@1 on HumanEval versus 80% for the prior GPT-4 baseline—real gains, paid for with full retries. Use Reflexion when failure is cheap to detect (tests, compilers, schema validators) and expensive to ship. Do not use it as a substitute for better tools. arxiv

Tool protocols are not interchangeable layers

Practitioners still collapse three different problems into “tool calling.” Separate them or your architecture will fight you.

Native function calling is the inner loop

Provider tool APIs (OpenAI tools, Anthropic tool use, Google function declarations) are how a single model turn requests work from your process. Schemas go in; structured calls come out; you execute; results return as protocol-level messages. This is mandatory plumbing. It is not a multi-agent standard and it does not discover remote capabilities. developers.openai

MCP is agent-to-tool, not agent-to-agent

Anthropic open-sourced the Model Context Protocol in November 2024 as a universal way to connect assistants to data and tools instead of writing a custom integration per system. The specification defines JSON-RPC messaging among hosts (LLM apps), clients (connectors inside the host), and servers (context providers). anthropic

Servers expose three primitives that matter in production:

• Tools — functions the model may execute (tools/list, tools/call)
• Resources — readable context (files, records, schemas)
• Prompts — reusable templates

Transports are stdio for local processes and Streamable HTTP for remote servers, with OAuth recommended for auth on the HTTP path. The architecture docs are explicit that MCP standardizes context exchange; it does not dictate how your application orchestrates the LLM loop. modelcontextprotocol

Security is not optional flavor text. The spec’s trust section requires user consent for data access and tool invocation, treats tool descriptions from untrusted servers as untrusted, and expects hosts to keep humans in control of sampling and side effects. If your MCP host auto-runs every tool the model requests, you are out of compliance with the spirit of the protocol even if the JSON-RPC is perfect. modelcontextprotocol

A2A is peer agents across trust boundaries

The Agent2Agent (A2A) Protocol is the complementary standard: opaque agents discovering and collaborating without sharing internal memory, tools, or proprietary logic. Google originated it; it now sits under the Linux Foundation. The official line is clean: MCP equips one agent with tools; A2A lets that agent collaborate with other agents. a2a-protocol

Core A2A objects from the specification:

• Agent Card — JSON capability document (identity, skills, endpoint, auth)
• Task — stateful unit of work with a lifecycle (submitted → working → terminal or interrupted states such as input-required / auth-required)
• Message / Part / Artifact — turns and outputs exchanged without exposing internals

Operations include Send Message, streaming variants, Get/List/Cancel Task, subscriptions, and push-notification configs for long-running work. Bindings cover JSON-RPC, gRPC, and HTTP/REST. Use A2A at organizational or vendor boundaries. Do not use it to call your own retrieval function inside one process—that is MCP or native tools. a2a-protocol

A2T is the enterprise REST take on tools

The IETF Internet-Draft AI Agent to Tool (A2T) (Rosenberg & White, Nov 2025) attacks a different pain: enterprises integrating dozens of third-party APIs into designer-authored operating procedures. It standardizes two REST surfaces—tool enumeration and tool invocation (POST …/tools/{toolID}:invoke)—with versioned signatures and an explicit designer-time curation model. datatracker.ietf

A2T’s own comparison to MCP is useful: MCP leans run-time discovery and session-oriented progressive disclosure on the server; A2T assumes a human designer selects tools into operating procedures at design time and prefers stateless REST. Treat A2T as emerging enterprise tooling, not as a settled peer to MCP/A2A yet—it is still an Internet-Draft with an open issues list. datatracker.ietf

My rule: native tool calling inside the loop; MCP (or A2T-style REST tools) at the system boundary for capabilities; A2A only when another autonomous agent owns a task you should not implement as a function.

State is a product surface, not a chat log

If the only “memory” you have is the growing message array, you do not have an agent system. You have a demo that cannot resume after a deploy.

LangGraph’s documentation states the split cleanly. Checkpointers persist thread-scoped graph state for continuity, human-in-the-loop, time travel, and fault tolerance. Stores hold cross-thread long-term data such as preferences and shared facts. You compile a graph with a checkpointer, pass a thread_id, and each node completion can become a recoverable snapshot. InMemorySaver dies with the process; production needs Postgres or another durable backend, and thread_id values should stay short enough for the column constraints (LangGraph calls out a 255-character practical limit for Postgres). docs.langchain

Regardless of framework, I want state shaped like this:

• Goal and constraints — small, always re-injected so the model does not drift after twenty tool dumps
• Plan steps with statuses — pending / running / done / failed, not prose paragraphs
• Append-only decisions and assumptions — never overwrite why a branch was taken
• Artifact references, not blobs — tool outputs live in object storage; the state holds URIs and hashes
• Event log — every attempt recorded; patches applied centrally (JSON Patch is a sane default)

Shared-workspace multi-agent systems need write mediation. Concurrent agents editing the same artifact without conflict detection will corrupt the only source of truth you have. Rank causes of “the agent forgot” in this order: context overflow and missing goal re-injection, missing checkpoints, reducer bugs on concurrent writes, then model quality.

Human-in-the-loop is a state transition, not a UI flourish. Interrupt before irreversible tools (payments, emails, production deploys), persist the paused checkpoint, and resume with the same thread_id after approval. If you cannot pause safely, you are not ready for those tools.

Multi-agent coordination is a routing problem

Adding agents does not add intelligence. It adds interfaces. Start from task structure.

Supervisor / worker (default)

One supervisor decomposes the goal, dispatches specialists, and synthesizes the answer. Workers do not talk to each other. Debugging is tractable because every handoff is visible at one node. This is the right default for production support, research synthesis, and most internal ops bots. atlan

OpenAI’s Agents SDK encodes two variants of the same idea. Agents-as-tools keeps a manager in control of the user-facing reply while specialists run as callable tools. Handoffs transfer ownership so the specialist becomes the active agent for the rest of the turn—closer to a phone transfer than a subroutine. Use handoffs when the specialist should own tone and policy for that branch. Use agents-as-tools when you need one voice and merged evidence. developers.openai

Hierarchical

Nested supervisors when a single router cannot keep ten-plus specialists straight—strategy at the top, tactics in the middle, execution at the leaves. Context windows stay local to each level. Cost and latency climb; only pay that tax when the domain tree is real. atlan

Sequential pipeline with checkpoints

Fixed stages (retrieve → draft → verify → publish) with durable state between nodes. Prefer this over free-form multi-agent debate when the order is known. Conditional edges handle retries; they do not require a second LLM persona arguing with the first.

Peer / swarm / mesh

Agents hand off laterally or publish to a shared bus. Flexible, hard to audit, easy to infinite-loop. I would not ship a mesh for regulated workflows. If you need cross-org collaboration, A2A tasks with explicit lifecycles beat ad-hoc peer prompts. a2a-protocol

Blackboard

Agents read and write a shared structured workspace. Powerful for design exploration; dangerous without locks, schemas, and an authority that merges patches.

Anti-pattern I see constantly: five agents that are really one prompt split for blog diagrams. If they share tools, instructions, and success criteria, merge them. Multi-agent pays rent only when specialization reduces context, policy, or permission scope.

Progressive tool disclosure belongs here too. The A2T draft’s enterprise framing is right even if you never implement A2T: show the model only the tools for the active sub-agent and task phase. Dumping eighty MCP tools into one supervisor context is how you get confident calls to the wrong API. datatracker.ietf

Where multi-step runs actually die

Failures cluster. Design for these before you tune temperature.

Context rot. Raw tool JSON accumulates until the original goal is a minority of tokens. Fix with artifact offloading, periodic summaries, and mandatory goal re-injection every k steps.

Plan fragility. Pure plan-and-execute meets a dead API and keeps executing step 7. Fix with typed executor errors and an explicit re-plan edge—not a hope that the executor “will figure it out.”

Hallucinated success. The model claims the email sent because it drafted text. Fix by making side-effect tools return receipts the verifier checks, and by forbidding free-text claims about external state without a tool result in scope.

Orchestrator bottlenecks. Every worker result re-enters a huge supervisor prompt. Fix with structured worker reports (status, artifacts, open questions) instead of full transcripts.

Protocol confusion. Teams expose internal Python functions over A2A and remote vendor agents over ad-hoc HTTP. Fix the layering: functions and MCP locally, A2A at the boundary. a2a-protocol

Missing budgets. No step cap, no wall-clock timeout, no spend ceiling. An agentic loop without budgets is an unbounded cloud bill with a natural-language API.

Build the smallest loop that can finish the job

If I were green-fielding a complex multi-step product task tomorrow, the sequence would be mechanical. Implement one ReAct agent with native tools and a hard step limit. Persist state with a real checkpointer and artifact store on day one. Promote to plan-and-execute only when traces show thrashing on known phases. Introduce a supervisor plus two specialists only when a single context cannot hold the tools and policies without error. Reach for MCP when tool integration count exceeds what custom adapters can maintain; reach for A2A when another team’s agent must complete a task you do not own.

The decision that matters in the next forty-eight hours is not which multi-agent framework is trending. It is whether your runtime—not the model—owns observations, termination, budgets, and durable state. Everything durable in agentic systems is harness design. The model only proposes the next move.