Agentic Engineering: From Loops to Graphs

For much of the recent agent boom, the unit of progress was the individual agent: give one model better instructions, better tools, more context, and a tighter execution loop.

That work still matters. But once an agent can reliably plan, call tools, inspect results, and recover from ordinary errors, a new bottleneck appears. The hard question is no longer only how capable is each agent? It becomes how should work move between agents?

That is the core of graph engineering: designing the topology, state, routing, synchronization, and evaluation logic that coordinate multiple model-driven workers.

The shift requires one important correction, however. Multi-agent graphs are not replacing single-agent loops everywhere. They are an additional architecture for tasks that benefit from decomposition, independent context windows, parallel exploration, or specialist roles. For many jobs, one well-designed agent or even one model call remains the better system.

The mental model: nodes do work, edges move work

Graph theory gives us a useful abstraction. In 1736, Leonhard Euler represented Königsberg’s landmasses as vertices and its bridges as edges. By discarding irrelevant physical detail, he turned a local puzzle into a general problem about connectivity.

Agent architectures benefit from the same move:

• Nodes perform work. A node might be a deterministic function, a model call, a tool, or a complete agent with its own instructions, tools, memory, and execution loop.
• Edges move control and state. They determine what runs next, what data crosses the boundary, and under which condition execution follows a particular path.
• Shared state is the graph’s working memory. It can contain the task, intermediate artifacts, citations, scores, errors, and the final answer.
• The orchestrator or runtime schedules nodes, enforces limits, handles failures, and records what happened.

This distinction matters because not every box in an agent diagram is itself an autonomous agent. Calling every model invocation an “agent” hides the design decisions that make the system reliable.

A DAG is useful, but not every agent graph is a DAG

A directed acyclic graph, or DAG, has directed edges and no directed cycles. Execution does not have to move literally from left to right. That is only a drawing convention. The defining property is that no route can eventually return to the same node.

DAGs are a natural fit for workflows with clear dependencies:

Scope
  ├── Explore topic A ──┐
  ├── Explore topic B ──┼── Verify evidence ── Synthesize
  └── Explore topic C ──┘

Each exploration branch can run after scoping. Verification waits for the relevant branches. Synthesis waits for verified evidence. The graph makes those dependencies explicit.

But agents often need iteration. A critic may reject a draft and return it to a generator. A researcher may follow a new lead. A coding agent may run tests, inspect failures, and revise the implementation. These are cycles, so the complete system is not a DAG.

In practice, mature systems often combine both ideas:

• an outer graph expresses stages, branches, and dependencies;
• an agent loop inside a node handles local reasoning and tool use;
• a bounded feedback edge supports revision, with a retry limit or stopping criterion.

The better contrast is therefore not “loops versus DAGs.” It is one undifferentiated loop versus explicit orchestration.

Workflows and agents are not the same thing

Anthropic draws a useful boundary between two forms of agentic system:

• A workflow follows code-defined paths. The developer controls the sequence and branching rules.
• An agent lets the model dynamically choose its process and tools.

A graph can contain both. Deterministic nodes can validate schemas, enforce budgets, or merge results. Agentic nodes can explore open-ended questions. This hybrid is often more dependable than asking a model to control every transition.

Think of it as a railway network. The model can decide which destination is worth visiting, but the tracks, signals, junction rules, and maximum journey time should not be improvised on every trip.

A realistic research graph

It is tempting to describe research as a fixed assembly line with a predetermined number of workers. Real systems are more adaptive. Anthropic publicly describes a lead research agent that creates parallel subagents dynamically, allowing decomposition to follow the question rather than a universal worker count.

One recorded Claude Code demonstration offers a useful, but unverified, case study. In that run, the tool reportedly translated a research plan into a fresh JavaScript workflow of 427 lines. The generated program acted as the runtime for that request and launched more than 100 workers, each with its own instructions and context window. A later request could generate a different program and a different worker count.

The demonstrated run was described as a five-phase graph:

1. Scope, 1 worker. Interpret the request and define the research requirements.
2. Gather, 5 workers. Find credible sources for separate subtopics.
3. Fetch, 25 workers. Retrieve and extract information from those sources.
4. Verify, 75 workers. Check claims and compare judgments about source credibility.
5. Report, 1 worker. Synthesize the resulting evidence into a final answer.

Those figures should be treated as an observed example from the supplied demonstration, not as documented Claude Code defaults or the universal architecture of Anthropic Research. They also sum to 107 workers, despite the demonstration later referring to 108 agents. The discrepancy is a useful reminder that generated traces and narrated explanations need the same verification as any other technical artifact.

The broader architecture is more important than the exact count:

1. Scope the question. Define the deliverable, freshness requirements, source standards, and subquestions.
2. Create a research plan. The orchestrator decides whether the task needs one worker, several parallel workers, or no multi-agent decomposition at all.
3. Explore in parallel. Workers investigate independent subtopics using isolated context windows.
4. Return compressed evidence. Each worker sends the lead agent findings, source metadata, uncertainty, and unresolved conflicts, not its entire transcript.
5. Verify important claims. Deterministic checks and model-based reviewers test source quality, entailment, dates, and contradictions. Model voting can flag disagreement, but votes do not establish truth without credible evidence.
6. Synthesize the answer. The lead agent writes from the evidence set and preserves citations.

The number of workers should follow the task. A question with three independent dimensions might justify three workers. Spawning dozens of agents for a narrow lookup usually creates more duplication, latency, and failure modes than value.

Anthropic reports that its multi-agent research system performed especially well on breadth-first questions that can be split into independent directions. In an internal research evaluation, a system using Claude Opus 4 as the lead and Claude Sonnet 4 as subagents outperformed a single Claude Opus 4 agent by 90.2 percent. That is a significant result, but it is an internal evaluation of a particular system and workload, not proof that multi-agent designs universally double quality.

Why graphs can outperform one large loop

1. Parallelism reduces the critical path

If five independent searches each take 20 seconds, one worker doing them sequentially needs roughly 100 seconds, excluding overhead. Five concurrent workers could approach 20 seconds, plus orchestration and synthesis time.

The important metric is not the sum of all work. It is the critical path, the longest chain of dependent operations. Graph design improves latency when independent work leaves that path and runs concurrently.

Parallelism does not make every stage faster. Rate limits, tool contention, slow branches, and final aggregation still matter. The slowest required branch can become a straggler that delays the entire fan-in.

2. Context isolation protects attention

A long-running agent accumulates instructions, tool results, failed attempts, and intermediate summaries. More context is not automatically better context. Anthropic describes context as a finite resource and notes that agents need ongoing curation of the tokens available at each step.

Subagents create separate workspaces. One worker can analyze technical architecture while another checks chronology, without forcing both histories into one context window. Each then returns a compressed result to the parent.

This is not the same as escaping context limits altogether. The lead agent still needs a controlled representation of the combined evidence. Multi-agent systems move the compression boundary; they do not abolish it.

3. Specialization sharpens instructions and tools

A source discovery worker, a data extraction worker, and a citation verifier have different success criteria. Separate nodes allow each role to receive narrower instructions, fewer tools, and a purpose-built output schema.

Specialization also improves evaluation. You can measure source recall for discovery, field accuracy for extraction, and citation entailment for verification instead of grading the whole system with one vague quality score.

4. Redundancy can improve confidence

Independent workers can investigate the same high-risk claim and compare results. This can expose ambiguity or source conflict.

However, agreement between models is not proof. Agents can share the same blind spots, training biases, or weak source. Verification should inspect evidence provenance, not merely count votes.

Five composable orchestration patterns

These patterns are more useful than treating “multi-agent” as one architecture.

Prompt chaining

One stage transforms the output of the previous stage: extract facts, draft a summary, then check it against the facts.

Use it when the task decomposes into a stable sequence and each intermediate output can be validated.

Routing

A classifier or rule sends the request to the right specialist.

Use it when inputs fall into recognizable categories. Keep the fallback path explicit because uncertain routing is inevitable.

Parallelization

The system fans work out to independent branches and then merges their outputs.

Use it for independent subquestions, multiple data sources, or deliberate redundancy. Define merge rules before spawning workers.

Orchestrator-workers

A lead agent decomposes the task dynamically, delegates subtasks, and synthesizes the results.

Use it when the required subtasks cannot be predicted reliably in advance, as in open-ended research or repository-wide code changes.

Evaluator-optimizer

One component produces an artifact and another grades it against explicit criteria. The artifact is revised until it passes or reaches a limit.

Use it when quality can be stated clearly and iteration demonstrably improves the result. Without a rubric and stopping rule, this pattern can become an expensive conversation with no convergence.

Frameworks such as LangGraph provide primitives for stateful, single-agent, multi-agent, and hierarchical control flows. Microsoft AutoGen helped popularize multi-agent conversation patterns after its September 2023 release. These frameworks are useful, but the architecture is the design. The framework is only its implementation surface.

The hidden price: tokens, latency, and coordination

Multi-agent systems buy breadth with more inference and more moving parts. The cost is not only the number of workers.

A useful planning model is:

Total cost =
  lead-agent tokens
  + sum of worker tokens
  + verification tokens
  + synthesis tokens
  - eligible cache savings

Then add non-token costs such as search APIs, code sandboxes, storage, tracing, and retries.

Beware of estimates built by multiplying an assumed worker count by a typical context size and then applying a headline cache discount. Such calculations omit output tokens, cache-write charges, cache eligibility, retries, and the split between repeated and unique content.

The direction of the trade-off is clear: multi-agent systems generally consume more tokens than ordinary chat or a single-agent run. Anthropic’s engineering account reports that agents used roughly four times the tokens of chat interactions in its measurements, while multi-agent systems used about 15 times as many. These are empirical ratios from Anthropic’s workloads, not constants that can be applied to every architecture. Model selection, tool results, worker count, context design, and stopping conditions can move the number dramatically.

The demonstration behind this article also described workers starting with roughly 20,000 tokens of context and then multiplied that assumption across 108 purported Opus 5 workers to estimate nearly $10 of input cost before caching and roughly $1 after caching. That arithmetic is useful as intuition about fan-out, but not as a reproducible estimate. The narrated phase counts do not reconcile with 108, the exact token use was not independently measured here, and the estimate omits output tokens, cache writes, unique worker context, retries, and non-model services.

What prompt caching actually changes

Prompt caching can reduce the cost and latency of repeatedly processing an identical prompt prefix, such as shared system instructions, tool definitions, or stable background material. It does not make unique worker context free, and it does not automatically turn any $10 graph into a $1 graph.

As of July 30, 2026, Anthropic advertises up to 90 percent savings from prompt caching for Claude Sonnet 5. “Up to” is the critical phrase. Real savings depend on how much of each request is cacheable, whether the prefix is reused within the cache lifetime, and the provider’s cache-write and cache-read prices.

For planning, separate each request into:

• shared prefix: stable instructions and tool definitions that may be cached;
• worker-specific input: the unique subtask and evidence;
• generated output: new tokens that are not eliminated by input caching;
• retries and failed branches: work that still incurs cost even if it produces no useful artifact.

A graph with a small common prefix and large unique source documents may save little. A graph with a large, repeated prefix across many concurrent workers may save much more.

Reliability is an edge problem

Capable nodes do not guarantee a capable system. Failures often occur at the boundaries:

• the orchestrator decomposes the task poorly;
• two workers duplicate the same work;
• a worker returns prose when the merge node expects structured data;
• citations are lost during summarization;
• the verifier checks fluency instead of factual support;
• one branch hangs and blocks the final join;
• retries multiply cost without improving quality.

Treat every edge as an API contract. Define the required schema, provenance, timeout, retry behavior, and acceptance criteria.

A practical worker response might contain:

{
  "subtask": "Verify the framework release timeline",
  "findings": [],
  "sources": [],
  "confidence": "medium",
  "conflicts": [],
  "open_questions": []
}

Structured handoffs make fan-in safer. They also make traces easier to inspect and evaluations easier to automate.

Design from the evaluation backward

Before adding agents, define what improvement means.

Measure at least four dimensions:

1. Task quality: correctness, completeness, groundedness, and citation accuracy.
2. Efficiency: input tokens, output tokens, tool calls, and external-service cost.
3. Latency: median, tail latency, and critical-path duration.
4. Reliability: failure rate, timeout rate, retry count, and variance across repeated runs.

Then compare architectures on the same evaluation set:

• one model call;
• one agent with tools;
• a deterministic workflow;
• a multi-agent graph.

Anthropic’s practical recommendation is refreshingly conservative: start with the simplest solution and add complexity only when it produces measurable value. Workflows offer predictability for well-defined tasks. Agents offer flexibility where the path is genuinely open-ended.

When to use a graph

A graph is a strong candidate when:

• the task contains independent branches that can run in parallel;
• different subtasks need different tools, instructions, or models;
• context isolation reduces interference;
• intermediate artifacts can be checked;
• the quality gain justifies extra tokens and operational complexity.

Prefer one agent or a simpler workflow when:

• the task is narrow or mostly sequential;
• decomposition would create tightly coupled subtasks;
• a single context window comfortably holds the relevant state;
• latency or cost matters more than marginal breadth;
• you cannot evaluate intermediate or final quality reliably.

The real frontier is explicit orchestration

The early wave of agent frameworks proved that models could exchange messages, call tools, and collaborate. Microsoft AutoGen demonstrated multi-agent conversation patterns in 2023. LangChain’s exploration of cyclic, stateful execution led to LangGraph, while Anthropic documented composable patterns such as chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer workflows.

What changed was not graph theory. It was the amount of useful work a node could perform. An early node might have been little more than one LLM call. Modern coding agents such as Claude Code, Codex CLI, GitHub Copilot CLI, Cursor, Cline, Roo Code, and Windsurf wrap models in tool access, execution environments, repository context, and control loops. The engineering emphasis consequently expanded from prompt wording to context engineering and agent harness design.

Where GitHub Copilot CLI fits

GitHub Copilot CLI is not merely another single-agent terminal interface. Its main session can delegate work to temporary subagents that run with isolated context. Built-in agents specialize in activities such as repository exploration, planning, command execution, and code review. Developers can also define custom agents with their own instructions, tool restrictions, model selection, and MCP servers. Copilot can select a relevant specialist automatically, while Fleet mode can coordinate multiple subagents in parallel.

In graph terms, these custom and built-in agents are candidate nodes, the parent session acts as an orchestrator, and delegation plus result return form the edges. The architecture supports several patterns discussed earlier: routing, orchestrator-workers, parallel fan-out, context isolation, and evaluator-optimizer behavior. The built-in rubber-duck agent is a concrete evaluator example: it can critique a plan, design, implementation, or test set and return actionable feedback to the main agent.

The boundary is equally important. GitHub documents subagent delegation and parallel execution, but that does not establish that Copilot CLI reproduces the specific Claude Code demonstration described earlier. There is no documented Copilot CLI default that generates a fresh 427-line JavaScript runtime, launches more than 100 agents, or applies the same 1-5-25-75-1 research topology. For applications that require an explicit graph with developer-controlled state, transitions, retry policies, and lifecycle events, the Copilot SDK or an external orchestration layer is the more appropriate construction surface.

That does not mean modern nodes execute flawlessly. It means they are capable enough for decomposition and coordination to become a productive engineering problem. More capable nodes have made the edges more important, but they have not removed the need to evaluate the nodes themselves.

The next step is not to spawn the largest possible swarm. It is to design the smallest graph that creates a measurable advantage.

That means choosing where autonomy belongs, making dependencies visible, isolating context deliberately, validating every handoff, bounding every loop, and evaluating the complete system rather than admiring individual agents.

Euler’s abstraction remains useful nearly three centuries later: once the nodes are capable enough, the shape of the edges determines what the system can accomplish.

Sources

• Anthropic, How we built our multi-agent research system, June 13, 2025.
• Anthropic, Building effective agents, December 19, 2024.
• Anthropic, Effective context engineering for AI agents, September 29, 2025.
• Anthropic, Prompt caching documentation.
• Anthropic, Claude Sonnet, accessed July 30, 2026.
• LangChain, LangGraph.
• Microsoft Research, AutoGen.
• GitHub Docs, Creating and using custom agents for GitHub Copilot CLI.
• GitHub Docs, Invoking custom agents in GitHub Copilot CLI.
• GitHub, GitHub Copilot CLI.
• GitHub Changelog, GitHub Copilot CLI is now generally available, February 25, 2026.
• GitHub Changelog, Copilot CLI: Improved UI, rubber duck, prompt scheduling, and voice input, June 2, 2026.