Back to List

Moving Orchestration Logic from AI's Brain into Code

ai-insights2026-07-017 min read
Moving Orchestration Logic from AI's Brain into Code

Author: Lincoln Wang | Founder of MindsLeap | Global Partner at Founders Space | Founder of Founders AI Club

"When a task becomes sufficiently large or highly repetitive, AI agents start losing their way. They skip steps, they declare themselves done prematurely, and sometimes they go down a completely wrong path."

The person who said this is Colin, an engineer at LangChain. In a product demo in late June 2026, he showcased a seemingly small but potentially transformative new feature for how enterprises deploy AI agents — dynamic subagents.

The demo was simple: have a coding agent dispatch fifteen subagents simultaneously, each writing a taco recipe themed around breakfast, then select the best one for you.

Fifteen agents worked in parallel on screen, with a panel tracking each subagent's progress and time spent in real-time. Throughout the process, the main agent didn't call tools round by round, wait for results, then decide the next step. Instead, it wrote a few lines of code, handing off distribution and coordination to the program itself.

Colin said something that every business leader deploying AI should carefully consider:

"The orchestration logic was actually moved from the agent's brain into code."

A Task That Shouldn't Have Failed

To understand why this statement carries weight, you need to see what problem it solves.

Before this, AI agent systems already supported "subagents." Each subagent runs in its own context window, completes a portion of work, and returns results to the main agent. This keeps the main agent's context clean. The mechanism itself works fine.

The problem emerges when task scale increases.

Colin gave a vivid example: suppose you need to summarize every page of a book, with each page assigned to a subagent. Using traditional tool-calling, you're asking the main agent to invoke the subagent tool hundreds of times consecutively without losing any step along the way.

This isn't realistic. Not because the technology can't do it, but because putting hundreds of decisions into the agent's "reasoning process" is inherently unreliable design.

With dynamic subagents, this becomes what? The agent just writes a loop. A few lines of code, one subagent per page, collect results.

"A loop will iterate over every single item. So the agent can process all five hundred files, not just the seventy-five it felt like processing."

Completion no longer depends on the agent's "subjective willingness," nor is it a prompt-engineering problem requiring constant tuning.

Six Orchestration Patterns, Six Business Scenarios

The LangChain team distilled six most common orchestration patterns from real usage. These aren't technical show-offs — they correspond to real business shapes inside enterprises.

The first is "classify then act." Two hundred customer support tickets mixed together — the agent reads them first, determines whether each is a bug, feature request, or general inquiry, then dispatches to different subagent types for handling.

The second is "fan out then synthesize." Security review every file in a codebase, covering every file without skipping anything, then merge into a risk report sorted by severity.

The third is "adversarial verification." When the cost of wrong answers is high — security audits, compliance checks — you need a two-round mechanism. First round broadly scans to produce candidate findings, second round hands these to independent verification subagents, and only results confirmed by majority vote appear in the final report.

The fourth is "generate then filter." Multiple subagents produce different solutions in parallel, main agent scores them against clear criteria and selects the best.

The fifth is "tournament." When the optimal solution is subjective and hard to score directly, let solutions compete head-to-head, winners advance, until one remains.

The sixth is "loop until done." Each scan only finds issues missed in previous rounds, deduplicates, then runs another round until nothing new is discovered.

Using the Word "Workflow" as a Signal

There's a clever interaction design detail here.

Dynamic subagent capability isn't automatically triggered on every request. You need to explicitly use the keyword "workflow" in your request.

"Review every file in this PR" — the agent might parallelize or might not. But "run a workflow to review every file in this PR" explicitly tells the agent: you need to write orchestration code.

This is a signaling mechanism. Not more complex prompts, not more parameters — just a simple keyword to switch the agent's working mode.

The insight for enterprise managers: when designing AI-driven business processes, you need explicit signals to switch between different working modes, rather than expecting agents to "understand" your intent on their own.

Context Isolation Is the Real Prerequisite for Scale

During the "generate then filter" demo, Colin highlighted an easily overlooked detail.

Each subagent generated a rate limiter redesign — token bucket, sliding window, leaky bucket, GC. You can see how many tool calls each subagent made, how long each took, and all this activity is completely isolated from the main agent's context window.

This is the value of context isolation. Not to make the system look cleaner, but to enable the main agent to handle larger-scale tasks without being overwhelmed by details.

"The main agent's context stays clean partly because only final data is returned from runs."

In enterprise management, this maps to a classic organizational design challenge: management attention is the scarcest resource. If your executive team needs to personally track every detail of every frontline task, the organization can never scale. AI agent systems are replicating the same logic — context is attention, isolation is delegation.

Risks and Boundaries

There's an easily misread aspect of this story: it's not saying AI agents no longer need reasoning, but rather when orchestration logic is better expressed in code, it should be expressed in code.

Some tasks — classification, parallel scanning, loop verification — their core challenge isn't understanding but coverage and consistency. For these tasks, handing coordination to code is more reliable.

But other tasks — requiring judgment, tradeoffs, decisions under ambiguous information — these still need the agent's reasoning capability.

Colin demonstrated this too: in the "tournament" pattern, the agent can choose to generate candidate solutions in code, then use regular tool calls to hand solutions to an evaluation subagent for final selection. It isn't forced into one approach.

This is more of a signal: AI toolchains are moving from "agent does everything alone" to "agent knows when to write code, when to reason, when to delegate."

For enterprises, this means you need both capabilities when deploying AI — the ability to design code flows and the judgment to determine which tasks suit code versus which must retain human intervention.

A Map Unfolding

LangChain's feature release had only a couple thousand viewers — far from viral. But the core point Colin repeated throughout the demo — moving orchestration from agent context reasoning to code execution — deserves serious consideration by traditional enterprise technology leaders.

Over the past two years, Chinese enterprise AI deployment has focused mostly on "can it work" and "how well does it work." Dynamic subagents raise the next-stage question: "Can it scale reliably?"

When your volume goes from dozens of daily tickets to tens of thousands, from reviewing a few code files to the entire codebase, from one security audit to continuous monitoring — coverage, consistency, and traceability become more important than single-task quality.

This isn't purely a technology upgrade. It requires enterprises to rethink: which processes should let AI agents reason autonomously, which should be codified into code logic, and which checkpoints must retain human confirmation. This classification capability is becoming part of organizational capability in the AI era.

The map is just unfolding, but the direction is clear.


About MindsLeap

MindsLeap is an AI-native organization transformation accelerator.

In deep partnership with Silicon Valley innovation incubator Founders Space, we continuously connect cutting-edge global AI insights, the Silicon Valley tech entrepreneurship ecosystem, and real transformation scenarios for Chinese entrepreneurs.

Around the theme of AI-native organization building, MindsLeap is constructing an ecosystem for entrepreneurs, startup founders, AI engineers, industry experts, and investors — helping enterprises move AI from cognition, strategy, and tools into real organizational capabilities, business processes, product innovation, and growth systems.


This article was translated and adapted from the Chinese original with AI assistance.

Back to List
Lincoln Wang · 2026-07-01