Agent engineering · know-how
🛠️ Solution·active·21 entries·21 sources·updated 2026-10-06
Orchestration is the control plane of a multi-agent system: how the work is decomposed, which agent does what, how they hand off, and who — if anyone — is in charge. The pattern you pick (central orchestrator vs. decentralized, a fixed graph vs. one generated per task) sets the cost, latency, and reliability ceiling of the whole system.
Orchestration is converging on coordination written as code. Instead of a model emitting one tool call per worker, harnesses drive fan-out from a program (Deep Agents' dynamic subagents), generate a harness per task (Claude Code Dynamic Workflows), or let a plain JavaScript or Python script spawn Claude Code, Codex, and other agents side by side. Control flow becomes deterministic, testable code around non-deterministic agents, and mixing providers becomes a lever for decorrelated errors.
Topology is a cost decision. A central orchestrator is easy to trace but is a throughput bottleneck and a single point of failure; removing it cut task cost about 50% in one study. The value sits in the interface contracts between agents (structured handoffs, explicit roles, what context each sub-agent sees), not in how many agents run.
The runtime substrate is load-bearing. Where each sub-agent runs, what files and state it sees, and how work survives a crash decide reliability. Options span a Postgres recipe (SKIP LOCKED dispatch, primary-key checkpoints, leases), purpose-built queues with leases and dead-letter states, and Google's Kubernetes-style AX.
Harnesses are becoming managed platforms. Microsoft's Agent Framework and Foundry Hosted Agents are GA, LangChain's Managed Deep Agents is in beta, and OpenAI's Agents API sells the Codex harness as a service. Enterprises already run Strands, LangGraph, and Deep Agents in production (see multi-agent). The counterweight is portability: AWS argues for patterns that survive a multi-framework, multi-model estate, and a practitioner guide reserves graph frameworks for long-running stateful workflows.
The open question is which layer to own. Managed runtimes remove the plumbing but tie durable state, memory, and evals to one vendor. Code-driven, provider-agnostic orchestration keeps you portable at the cost of running the substrate yourself.
A central orchestrator is easy to trace and debug but caps throughput and adds a bottleneck; decentralized topologies scale and cut cost but are harder to observe and can deadlock or diverge. Generated orchestration adapts per task but is less predictable and harder to test than a fixed graph. More agents and more coordination nearly always cost more tokens and latency, so the pattern only pays off when the task genuinely decomposes and the handoffs are cheap and well-typed — otherwise the orchestration overhead is pure loss.
A managed runtime removes the queue, checkpoint, and sandbox plumbing but couples durable state and evals to one vendor's platform.
This is distributed-systems design wearing an LLM hat: topology choice, backpressure, handoff schemas, and failure isolation. The actionable stance is to default to a single agent, reach for orchestration only when a task decomposes cleanly, prefer decentralized or contract-based handoffs over a fat central coordinator where you can trace them, and measure (see agent benchmarks) that the multi-agent version actually beats the single-agent baseline on cost and reliability before you ship it.
Harnesses now drive sub-agent fan-out from programs, generated per task or written in plain JavaScript or Python, so coverage comes from control flow and one script can mix agents from different providers.
h5i-python, the SDK for the h5i orchestra engine, defines and executes multi-agent coding workflows across Claude Code, Codex, and other runtimes as ordinary Python programs.
It is Omegacode's thesis in a second language: coordination is portable code, not a per-provider integration.
Also relevant to Coordinating multiple agents adds more failure than capability
Bytechef, an open-source workflow automation platform, embeds a full agent loop (model call, tool invocation, observation, next-step decision) as a drag-and-drop workflow step that can trigger or be triggered by ordinary steps. Agent decisions, tool calls, and human approvals share one audit trail.
Agents and workflows stop being separate layers. It is the "put coordination in ordinary code" pattern, expressed as a visual builder.
Also relevant to Coordinating multiple agents adds more failure than capability
Omegacode composes agent(), parallel(), pipeline(), and phase() calls in plain JavaScript, and any agent() call can spawn a Codex, Claude Code, OpenCode, or pi agent from the same script.
Its built-in patterns, adversarial code review and model bake-offs, use the provider mix as the design lever: decorrelated errors across models rather than one "best" agent. Code-driven orchestration stops being tied to one framework.
Also relevant to Coordinating multiple agents adds more failure than capability
LangChain's dynamic subagents in Deep Agents orchestrate sub-agents from a program instead of having the model emit one tool call per worker. Coverage is guaranteed by control flow: every item in a fan-out gets a worker because the code says so, not because the model remembered to call one.
The coordination layer becomes ordinary, deterministic, testable code wrapped around non-deterministic agents.
Also relevant to Coordinating multiple agents adds more failure than capability
Anthropic described the orchestration behind Claude Code's Dynamic Workflows: instead of committing to one fixed shape, the system generates a custom execution harness for each task to coordinate a team of sub-agents.
Control flow becomes something the model writes for the job at hand. It adapts per task, but a generated harness is harder to predict and test than a fixed graph, so you need the run traced to debug it.
Also relevant to Coordinating multiple agents adds more failure than capability
A wave of open-source and vendor orchestrators routes steps across models and makes sub-agent wiring visible; most are early, but they put the value in the routing and handoff layer, not the agents.
GitHub's Project HydraFusion routes each step of a coding workflow to the model that step needs. In controlled offline evaluations, its selective workflows matched or exceeded an Opus 5 baseline while reducing estimated workflow cost. It ships as a research preview in GitHub Copilot.
Heterogeneous-model collaboration lands inside a tool engineers already use daily. The numbers are vendor-reported and offline; see agent cost for the cost side.
Also relevant to Coordinating multiple agents adds more failure than capability
Intent, a coding-agent orchestrator built to run hundreds of agents in parallel across isolated workspaces, went open source. A Coordinator agent turns a stated intention into a spec, specialist agents execute against it while sharing context, and git integration handles commits and review.
It targets the high-agent-count end of the problem, where the spec and workspace isolation carry the coordination rather than a small fixed topology.
Also relevant to Coordinating multiple agents adds more failure than capability
Open Session is a self-hosted, cloud-based agent orchestrator that works with any model, or several at once. It began as an internal app at Tella, where the whole team uses it for product development, customer support, operations, and data analysis.
Unlike most launches in this wave, it was dogfooded in production before release. Its stated motivation was that existing tools lacked adaptability.
Also relevant to Coordinating multiple agents adds more failure than capability
rondoflow is a visual orchestration UI for wiring Claude Code sub-agents by hand.
It makes the handoff graph something you can see and edit instead of something implied by prompts. Early Show HN project.
Also relevant to Coordinating multiple agents adds more failure than capability
OpenOrb is a transparency-first multi-agent tool that exposes each agent's actions instead of returning only the final answer.
Visibility into handoffs is the first thing you need when a multi-agent run goes wrong. Early Show HN project.
Also relevant to Coordinating multiple agents adds more failure than capability
Kimchi is a terminal coding agent with multi-model orchestration built in, sending different kinds of work, such as refactors and code generation, to different models.
Heterogeneous-model collaboration moves from a manual habit into the agent itself. It is an early open-source project with no adoption data yet.
Also relevant to Coordinating multiple agents adds more failure than capability
An Ask HN thread asks for multi-LLM frameworks where models genuinely collaborate. The poster's split: Gemini for high-level refactoring and architecture, GPT/Claude for implementation, a handoff they report already doing by hand.
The request is a routing-and-handoff problem, not a model problem. The tools that followed on this page (Kimchi, Omegacode, GitHub's HydraFusion) are answers to it.
Also relevant to Coordinating multiple agents adds more failure than capability
Workspace layout, durable queues, leases, and checkpoints are the load-bearing parts; options range from a Postgres recipe to purpose-built kernels and Google's Kubernetes-style AX.
Google's AX runs autonomous agent workloads on a runtime, Agent Substrate, that treats each agent as a stateful actor rather than a stateless request handler. It suspends and resumes tasks to save resources and cut latency during idle phases, under a control plane with Kubernetes-style primitives for tasks and resources.
Scheduling and lifecycle management for agents arrives as a platform a team could adopt wholesale, instead of assembling it from queues and leases.
Also relevant to Coordinating multiple agents adds more failure than capability
An InfoQ article builds durable workflows on Postgres without an external orchestrator:
SELECT ... FOR UPDATE SKIP LOCKED lets many workers poll one queue while each row is claimed by exactly one worker.(execution_id, step_id) checkpoint table with ON CONFLICT DO NOTHING makes a rerun after a crash a no-op.lease_expires timestamp; a sweeper re-enqueues timed-out executions.It reportedly handles tens of thousands of steps per second on one instance for I/O-bound pipelines, on infrastructure most teams already run.
Also relevant to Coordinating multiple agents adds more failure than capability
Enjambre is a SQLite-backed "kernel" for agent swarms: a durable task queue with DAG dependencies, atomic claims with idempotency keys, auto-expiring leases (liveness derived from heartbeat age), and dead-letter states that record why a task failed. On top sit a permission gate that enforces rules before an agent runs and a router that picks agents by success rate, latency, and cost. MCP tools (enqueue_task, claim_task, complete_task) let any MCP client drive the queue.
It is very early (about ten commits, no adoption signal), but it ships the Postgres recipe's guarantees as one deployable unit.
Also relevant to Coordinating multiple agents adds more failure than capability
A write-up on designing an agent orchestration library reports that the load-bearing decisions are where each sub-agent runs, what filesystem and state it sees, and how its outputs are isolated and collected, not clever agent roles.
Orchestration is as much an execution-environment problem as a control-flow one. Budget for the plumbing.
Also relevant to Coordinating multiple agents adds more failure than capability
Microsoft, LangChain, and OpenAI now sell harnesses as managed runtimes, while practitioner guides and AWS argue for matching the framework to the workflow and keeping a multi-vendor estate portable.
OpenAI's Agents API is a managed service, powered by the Codex harness, for building and launching cloud agents, with orchestration, long-running sessions, and tool use handled by the platform.
The lab that trains the model now also sells the harness as a runtime, joining Microsoft and LangChain. It is one more managed option to weigh against the portability argument AWS makes.
The second post in AWS's multi-agent series starts from the fact that an organization running many agentic systems already lives in a "multi-everything" environment of several frameworks, models, and providers at once. It argues for patterns that keep those systems composable as that mix changes.
This is the counterweight to the managed-runtime launches on this page: harness choices that teams make independently become expensive to unwind once the systems have to scale together.
Also relevant to Coordinating multiple agents adds more failure than capability
Managed Deep Agents entered public beta: the Deep Agents harness deployed to a managed LangSmith runtime with durable execution, memory, sandboxes, channels, and evals.
The framework vendor now ships the production infrastructure around its own harness instead of leaving deployment to whichever platform (Bedrock, Foundry) an adopter picks. Weigh the convenience against how much of your estate then depends on one vendor's runtime.
Microsoft's Agent Framework (the Agent Harness, GitHub Copilot and Claude Agent SDK connectors, and orchestration patterns, all stable since Build 2026) now ships the harness and Foundry Hosted Agents at general availability.
The shift is from an SDK you assemble to a governed, supported runtime for running agents.
Also relevant to Coordinating multiple agents adds more failure than capability
A practitioner guide positions LangGraph by workflow fit, not as a universal default. Three executable recipes, SQL analytics with repair loops, RAG with evidence gating, and human-in-the-loop policy review with interrupt and checkpoint recovery, show where typed state, conditional routing, retries, interrupts, checkpoints, and traces pay off.
For simpler jobs it recommends ReAct-style loops, schema-first tools, or DSPy. Pick the framework by how stateful and long-running the process is.
Also relevant to Coordinating multiple agents adds more failure than capability