Companies Selling You AI Product Managers Don't Give Their Own Agents Job Titles: Multi-Agent Roles, Isolation, and Code

If you track products across multiple AI companies simultaneously, you’ve likely encountered three contradictory narratives. Cursor and Codex champion the planner-plus-executor pattern—one breaks down tasks while the other does the actual work. Grok Bot strikes a different tone, claiming your account is home to a team of badge-wearing AI colleagues: dedicated personas handling outbound sales calls, expense reconciliation, and product performance, with one named Piper managing weekly reports who keeps working after you close your laptop. Then comes Claude Code taking yet another route, where the model writes orchestration directly as JavaScript scripts, running dozens or hundreds of subagents according to a dependency graph. All three sides claim theirs is the true solution.

A natural question arises: Is assigning professional job titles to agents mere marketing fluff, or does it genuinely boost model performance? Putting names aside for a moment—whether it’s called Piper or Lao Wang is pure decoration—the “hats” referred to here mean job definitions: you are a product manager, you are finance, you are QA. This debate often assumes that job titles and underlying mechanisms compete on the same stage. However, execution logs I obtained while testing the Grok Build CLI in mid-August point to a different reading: these design choices operate at different layers and answer fundamentally different questions. The mechanism layer governs an agent’s actual performance, the orchestration layer determines who holds control, and the interface layer translates the system for human use. Job hats sit squarely in the interface layer—they serve a real purpose, but they do nothing to improve the quality of the model’s output.

Three Simultaneously True Realities

First, consider how these three products actually function. Cursor and Codex take the functional division-of-labor route. Codex introduced the Multi-Agent V2 architecture starting in version 0.145.0, while Cursor builds multi-agent collaboration on top of Composer and Agent Mode. Agents on both sides have explicit functions, with names that are strictly functional: planner, executor, reviewer, explore. No one in a code editor gives a subagent a name like Lao Wang.

Grok Bot opted for the named-colleague approach. On August 11 2026, it launched an early preview, provisioning each account with a 24/7 cloud computer populated by AI colleagues wearing name tags and job titles. The official documentation explicitly lists eight roles: outbound sales, candidate sourcing, paid advertising, expense reconciliation, product performance, bug reproduction, customer health, and chief of staff. Each role is tied to a standardized deliverable—for instance, while you sleep, the outbound sales colleague conducts prospect research, ranks contacts, drafts emails in your voice, and leaves an approval queue for your morning review.

Claude Code and Grok Build chose script-based orchestration. In late May, Claude Code released dynamic workflows, where the model generates a JavaScript script on the fly for the current task, which is then executed by an independent background runtime. The script strictly manages flow control without performing the work itself, dedicated entirely to spawning subagents. Grok Build shares a similar approach: behind its /deep-research command lies a Rhai script—a scripting language from the Rust ecosystem that does exactly what the JavaScript version does.

This might look like an ideological divergence. In reality, the three products simply pull what they need from different layers, while operating on the exact same underlying mechanism foundation.

Foundation: Window Isolation Never Changes

At the mechanism layer, only one thing matters: context window isolation. A routine scenario illustrates this easily. Suppose you need to produce a weekly business review comparing Black Friday marketing across ten competitors. The easiest approach is stuffing all ten sets of materials into a single prompt. The model will indeed hand back a neatly formatted report with clear headings and organized sections. But a closer read reveals the flaw: several sections rehash the same platitudes in slightly different words, with wildly inconsistent depth. This type of failure is often insidious—the surface formatting is flawless, but the analytical quality is utterly banal. Crammed into a single window, materials from ten companies dilute one another, stretching the model’s attention budget far too thin to yield deep insight on any single competitor.

What actually works is opening a clean window for each competitor. A single subagent focuses on just one company, consumes only its material, and outputs an independent summary, leaving the main thread to simply aggregate those ten deliverables. The real driver of performance gains is having multiple non-interfering context windows; how many roles were assigned is mere detail. Role-playing alone cannot save the day: incanting to the model in a single window that it is now a “senior sales analyst” might slightly adjust its perspective or scoring criteria, but the window remains unchanged. Materials from ten companies remain crammed together, achieving neither parallelism nor physical isolation.

This was also the most intriguing detail I discovered when examining Grok’s execution logs. The very company hyping named colleagues most aggressively doesn’t use a single persona inside its own engineering core. Grok Build’s deep-research workflow splits an investigation into four phases: planning, retrieval, verification, and synthesis. The agent manifest I extracted at the time was strikingly blunt: one research-planner, four researchers from researcher-0 through researcher-3, two evidence-verifiers, and one report-synthesizer, making eight child agents in total. They are exclusively functionally named and zero-indexed, with nobody bothering to invent friendly aliases. The hardcoded engineering parameters in the script are equally unvarnished: a default retrieval width of four research lanes, a total 128 agent budget, a 32 concurrency cap, and checkpoint recovery via a journal file. There isn’t a trace of Piper anywhere inside. At its core, it is nothing more than the clean windows described earlier, augmented by dual-sampling during verification: when 24 claims are proposed, two independent verifiers check each one separately, and all 24 claims must pass before being committed to the final report.

In other words, the team selling hats never wears them when doing heavy lifting themselves. This isn’t hypocrisy; it’s simply a natural reflection of a layered architecture: the mechanism layer recognizes only window isolation, and professional hats exert no leverage here.

The Orchestration Seat: One Chair, Three Seating Arrangements

While the mechanism layer addresses agent output quality, it leaves another question untouched: during task execution, who decides where to go next? I refer to this control position as the orchestration seat. The three product categories mentioned earlier correspond to three distinctly different seating arrangements.

The first seating arrangement puts the teammate persona in charge. In Grok Bot, users toss a request to a named colleague, and subsequent steps advance strictly according to that role’s built-in logic, looping back for human approval only at key milestones. The user’s mental model is delegation—no different from instructing a human subordinate in the office: “You own this client account now.”

The second seating arrangement puts the main agent in control. Codex, Cursor, and OpenHands all belong to this category. OpenHands serves as a prime example: when the general-purpose CodeActAgent encounters web browsing it cannot handle on its own, it triggers an AgentDelegateAction, delegating the subtask to a specialized BrowsingAgent. Who decides the next step? The current main agent does, leaving developers with only prompt tuning to steer its judgment.

The third seating arrangement puts code in charge. Claude Code’s dynamic workflows and Grok’s Rhai scripts strip control flow entirely out of the model’s context memory, encoding it as plain, executable code. What runs first, when concurrency happens, and where branches fork are dictated entirely by the script; individual subagents stay tucked in their isolated windows, focusing solely on executing their assigned subtasks; and during verification, independent child agents conduct cross-checks. We previously published an analysis of this architecture, concluding that it combines two forms of determinism across three layers: locking down process flow control with procedural determinism while reserving outcome determinism for subtask execution and reasoning. The trade-off is that scripts cannot improvise mid-flight, making them best suited for heavy-duty tasks with predictable execution plans—such as code audits, large-scale repository migrations, and deep research requiring multi-angle cross-verification.

Each seating arrangement stakes its bet on a different asset. Teammate personas bet on the user’s intuitive delegation; main agents bet on the developer’s prompt-engineering finesse; code bets on determinism itself. Intriguingly, Grok sells both the first and third arrangements side by side: consumer-facing Piper wears a title and a name, while the Rhai script in its engineering foundation doesn’t bother defining a single persona. A single vendor with two distinct products perfectly demonstrates this layered logic in commercial practice.

Hats Live at the Interface Layer to Solve Human Problems

Since hats offer zero benefit to the quality of model outputs, why are commercial products so obsessed with doubling down on job roles? The answer lies in the interface layer. The three real problems hats solve revolve entirely around humans, directly tapping into human collaboration instincts rather than the model’s reasoning capabilities.

First, hats translate human intent to delegate into system configurations. Non-technical users rarely say “parameterize the outbound sales workflow” or “attach an asynchronous pipeline for CRM sync,” but anyone knows how to say “assign an assistant to sales.” The only multi-agent orchestration skill humans intuitively possess without training is delegating tasks to people. Job hats graft this real-world experience directly onto software interaction, lowering the barrier of learning new command sets. The quality of interface design hinges on the ubiquity of its metaphor. A “colleague” is far more intuitive to the general public than a “planner”—which explains why named colleagues proliferate in subscription consumer products while remaining scarce in hard-core developer tools.

Second, hats provide natural anchor points for triggers and approval gates. Scheduled cron jobs, automation pipelines triggered by Slack messages or GitHub notifications, and human approval checkpoints before sending external emails all require a named entity to attach to. You need to know who runs expense reconciliation every morning, just as you need to know which colleague drafted the outreach email you just approved. Without a name, relying solely on cold agent numbers leaves consumer-facing products unable to clarify the chain of accountability for users.

Third, hats create dedicated lanes for persistent memory. A named role’s conversation history, local files, and browser sessions accumulate over time, ready for retrieval in future runs. Without role-based context segregation under the same account, a month of activity turns into an unsearchable sludge. Names serve as the most intuitive index keys here.

An early example of this pattern was MetaGPT. In 2023, it hardcoded a software company’s SOP into various agent roles—product managers writing PRDs, architects crafting system designs, and engineers writing code—touting “one prompt in, full repo out.” With base model capabilities limited at the time, role assignments did serve to anchor behavior, attempting to keep off-track outputs bounded through rigid workflows. Looking back three years later, the value of that role division remained largely confined to demo presentations, making system interactions feel intuitive, while its lasting engineering legacy was structured artifacts like documentation, API specifications, and flowcharts. The hats sprinted ahead before underlying window isolation and verification mechanisms caught up, leaving the framework’s popularity frozen in that specific era of nascent model capabilities.

Recent hybrid cases illustrate this layering even more clearly. Claude Code’s agent teams feature fully borrows the team concept at the interface layer: once enabled, spawned sessions are renamed teammates rather than subagents, complete with point-to-point messaging. Yet turn to the mechanism layer, and the core is nothing more than a shared tasks.md ledger file. Task statuses, claim logs, and output dependencies are all written inside, with agents parsing the file to dynamically claim and hand off tasks. The outer shell adopts team rhetoric, while the engine inside remains ordinary file reads, writes, and a message loop. Even teams originating from the functional camp adopt a humanized wrapper at the interface layer when pushing products to a broader audience, while their underlying mechanism foundation remains unmoved.

There is one final card beneath the hat that must be laid on the table: hats cannot provide security boundaries. Grok Bot’s official documentation states explicitly that all colleagues under the same account share a single cloud computer—cookies, local files, and terminal credentials are fully shared, with each colleague assigned nothing more than an isolated virtual display screen. No real system permission isolation exists between the sales colleague and the expense colleague; the sole safeguard is the human approval gate. When evaluating such products, grasping this reality matters far more than reading flashy feature lists.

Judgment and Construction

Consolidating these three layers into a reference table makes architectural evaluation straightforward. The boundaries across different approaches are sharply drawn regarding decision-making ownership, sources of determinism, and target scenarios.

If you are building your own system, resource allocation priorities run opposite to commercial software buying instincts. First, anchor window isolation—it is the physical foundation for all output quality. Next, choose your orchestration seating arrangement based on task reliability requirements: if you need auditable, repeatable pipelines, strictly lock control flow with code; leave exploratory heavy lifting to autonomous agents. Persona packaging comes last, worth investing in only when delivering systems to non-technical business users. Forcing a name like Piper onto an internal orchestration system adds flavor to logs, but yields zero measurable engineering gain.

This layered perspective also yields several testable industry predictions: open-source frameworks will continue leaning into functional division of labor because core developers remain focused on the mechanism layer; subscription consumer tools will continue inflating job role packaging because purchasing decisions happen at the interface layer; and code generation tools will solidify scripted orchestration into a standard baseline because the engineering world puts real money on determinism. Feel free to benchmark next year’s new releases against these points. If the Pipers out there start voluntarily publishing their window isolation parameters, or if Cursor announces renaming planner to Lao Zhang, you are welcome to come back and refute my conclusions.

Related reading: For a detailed analysis of determinism boundaries at the scripted orchestration layer, see Claude Code Dynamic Workflow: Where the Boundary of Determinism Is Drawn. For a comparison of multi-agent architectural genes across coding tools, see Comparing Multi-Agent Architectural Genes.