Skip to content

Subunits

Subunits define the ability to combine multiple complex or customized agents as specialized sub-agents that handle specific, individualized work inside a larger runtime system. Where a single Unitt expresses one objective through one runtime pattern, a Subunit composition stacks many Unitts together; each with its own Core, Objectives, Patterns, Skills, Tools, Connectors, Memory, and System pattern; into a coordinated multi-agent runtime that operates as a single enterprise-scale operational system. Subunits are the primary mechanism by which Emergence scales beyond a single agentic loop into composable, governable, and specialized teams.

Subunit architectures inside Emergence are drawn from the active multi-agent research lineage, including the Anthropic multi-agent research system, Claude Code subagents, the Anthropic building-effective-agents guidance, OpenAI Agents SDK handoffs, LangGraph hierarchical agent teams, CrewAI role-based crews, AutoGen / AG2 group chats, MetaGPT SOP-encoded role pipelines, and the MAST taxonomy of multi-agent failure modes. Selection criteria for picking a subunit composition for a given workload are documented in Research › Subagents.

Why Subunits

A single Unitt is bounded by one context window, one tool allowlist, one identity, one policy scope, one runtime pattern, and one validation surface. Real enterprise workloads frequently exceed any single one of those boundaries. Subunits exist to address four practical pressures that show up in production agentic systems:

  • Context isolation. A search-and-scrape side-task can absorb 50,000 tokens of raw output and return a 500-token summary. The parent context never sees the noise.
  • Specialization. Different stages of a workflow want different identities, different rule sets, different tool allowlists, different memory scopes, and frequently different runtime patterns.
  • Cost shaping. A heavyweight reasoning model can supervise; cheaper executor models can run the bounded sub-tasks. Industry consensus puts ~80% of the cost variance on the supervisor / worker model split.
  • Parallelism. Independent sub-tasks fan out concurrently, cutting wall-clock time by up to an order of magnitude on research-style workloads.
flowchart LR
    P[Parent Unitt: Supervisor] --> S1[Subunit A: Research]
    P --> S2[Subunit B: Build]
    P --> S3[Subunit C: Validate]

    S1 -. summary .-> P
    S2 -. summary .-> P
    S3 -. summary .-> P

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class P,S1,S2,S3 stage

Anatomy Of A Subunit

A Subunit is a full Unitt operating inside a parent runtime as a delegated sub-agent. Each Subunit has its own complete Assembly configuration; Core, Objectives, Patterns, Skills, Tools, Connectors; and its own Emergence configuration; Memory tiers, System pattern, State strategy. The Subunit is invoked through a structured task brief, runs in an isolated context window with its own governance scope, and returns a structured summary to the parent.

flowchart TD
    PB[Parent: Task Brief] --> SUI[Subunit Invocation]
    SUI --> CORE[Subunit Core]
    SUI --> OBJ[Subunit Objective]
    SUI --> PAT[Subunit Pattern]
    SUI --> TOOL[Subunit Tools]
    SUI --> MEM[Subunit Memory Scope]

    CORE --> SR[Subunit Runtime]
    OBJ --> SR
    PAT --> SR
    TOOL --> SR
    MEM --> SR

    SR --> OUT[Structured Summary]
    OUT --> PR[Parent: Result]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class PB,SUI,CORE,OBJ,PAT,TOOL,MEM,SR,OUT,PR stage

The structured task brief is the parent / child contract. It includes the objective, the success condition, the tool allowlist, the memory scope, the time and token budget, the expected output schema, and any policy overrides authorized by the parent. The structured summary is the child / parent contract. It includes the outcome, the evidence trail, any escalations or governance findings, the consumed budget, and a structured payload that conforms to the schema declared in the brief.

Coordination Patterns

Subunit compositions in Emergence map onto three well-studied coordination patterns. Each pattern has a distinct cost profile, observability profile, and failure-mode profile. Pattern selection is documented in Research › Subagents and is one of the primary variables explored by the WorldSim evolutionary loop.

Supervisor / Orchestrator-Worker

A central supervisor decomposes the objective, dispatches work to specialized subunits, and synthesizes their summaries. This is the pattern behind the Anthropic multi-agent research system and the LangGraph supervisor pattern.

flowchart TD
    U[User Objective] --> SUP[Supervisor]
    SUP --> A[Specialist A]
    SUP --> B[Specialist B]
    SUP --> C[Specialist C]
    A --> SUP
    B --> SUP
    C --> SUP
    SUP --> OUT[Final Outcome]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class U,SUP,A,B,C,OUT stage

Supervisor is the default Emergence composition. It produces clean, debuggable execution traces; it is the easiest pattern to govern because every cross-agent message passes through one inspectable node; it parallelizes naturally because the supervisor can fan out independent sub-tasks. Its failure mode is supervisor bottleneck when the supervisor itself becomes a token sink or a single point of decision failure.

Hierarchical Decomposition

A top-level supervisor coordinates team leads, which in turn coordinate workers. Hierarchies emerge when a workload has natural sub-domains; e.g., a research team, a build team, and a validation team; each of which itself fans out to specialists.

flowchart TD
    TOP[Top Supervisor]
    TOP --> T1[Team Lead: Research]
    TOP --> T2[Team Lead: Build]
    TOP --> T3[Team Lead: Validate]

    T1 --> W1[Researcher A]
    T1 --> W2[Researcher B]

    T2 --> W3[Engineer A]
    T2 --> W4[Engineer B]

    T3 --> W5[Validator A]
    T3 --> W6[Validator B]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class TOP,T1,T2,T3,W1,W2,W3,W4,W5,W6 stage

Hierarchy scales to many specialists but multiplies token cost and latency at every layer. The recommended threshold for adding a hierarchical layer is roughly six concurrent workers under one supervisor; below that, a flat supervisor pattern remains cheaper and more debuggable.

Peer Handoffs And Debate

Peer compositions exchange control directly between subunits, either through handoff-as-tool (OpenAI Agents SDK style) or through structured debate with a final aggregator. Peer patterns are useful for customer-service-style triage flows and for tasks that benefit from independent critique.

flowchart LR
    A[Peer A] <-->|critique| B[Peer B]
    B <-->|critique| C[Peer C]
    C <-->|critique| A
    A --> J[Judge / Aggregator]
    B --> J
    C --> J
    J --> F[Outcome]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class A,B,C,J,F stage

Peer debate improves reasoning on tasks with verifiable answers, but recent research has shown agents tend to conform to the majority rather than reason independently. Emergence mitigates this by giving each peer subunit a distinct identity profile, distinct tool set, and an explicit dissent budget, and by requiring the aggregator to log minority positions in the audit trail.

Specialist Versus Generalist

Spinning a specialized subunit is justified when at least one of the following holds: the parent keeps re-issuing the same instructions for a recurring sub-task; the sub-task requires a different tool allowlist than the parent; the sub-task output volume would pollute the parent context; a cheaper model can handle the sub-task without quality loss; or the sub-task has policies, memory scopes, or governance constraints that should not bleed into the parent.

A generalist subunit; typically a Plan-and-Execute or ReAct Unitt with broad tool access; is the right choice when sub-tasks are one-shot, when they require the full conversation context, or when the coordination overhead would exceed the task complexity. Industry consensus from 2025-2026 is that specialists win on accuracy where workflows span distinct domains, while generalists win on short, well-defined tasks where coordination cost dominates.

Context And Memory Across Boundaries

The single most common failure in multi-agent systems is context loss across the parent / child boundary. The parent assumes the child knows something; the child only ever sees the prompt brief. Emergence enforces three patterns that mitigate this class of failure:

flowchart LR
    P[Parent Runtime] --> BR[Brief: Explicit + Schema]
    BR --> CH[Child Runtime]
    CH --> SUM[Summary: Schema + Evidence + Escalations]
    SUM --> P
    P -. shared scope .-> SM[Shared Episodic Memory]
    CH -. read .-> SM
    CH -. write .-> SM

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class P,BR,CH,SUM,SM stage
  • Explicit briefs and schemas. Anything the child needs must appear in the brief verbatim; file paths, error messages, prior decisions, constraints. The brief schema is enforced before invocation.
  • Schema-typed summaries. Free-text summaries lose edge cases; structured payloads conforming to a child-declared schema preserve the information the parent will later need.
  • Shared episodic scope (optional). When parent and child should share runtime history, they share an episodic memory namespace gated by governance. Semantic and procedural memory remain isolated by default.

Subunit Memory Scoping

Subunit memory is by default scoped to the subunit. The subunit reads its own working memory, its own episodic memory, and the procedural skills declared in its Assembly. Sharing across the subunit boundary is explicit and governed.

Scope Default Sharing Path
Working Subunit-private Never shared.
Episodic Subunit-private Shared by explicit namespace, governance-gated.
Semantic Subunit-private Shared via parent / fabric semantic namespace, read-only by default.
Procedural Subunit-private Shared via the platform Skills library, version-pinned.

This default keeps subunits cleanly isolated for debugging and replay, while still allowing the Fabric layer to coordinate shared semantic and procedural knowledge across an entire multi-agent system.

Composition With Runtime Patterns

Subunits are orthogonal to runtime patterns. A supervisor running Plan-and-Execute may dispatch a research subunit running ReWOO, a build subunit running CodeAct, and a validation subunit running LATS. The runtime pattern of each subunit is selected independently against its sub-objective profile.

flowchart TD
    SUP[Supervisor: Plan-and-Execute] --> R[Research Subunit: ReWOO]
    SUP --> B[Build Subunit: CodeAct]
    SUP --> V[Validation Subunit: LATS]

    R -. summary .-> SUP
    B -. summary .-> SUP
    V -. summary .-> SUP

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class SUP,R,B,V stage

This compositionality is the key property that makes Emergence subunits practical at enterprise scale: the platform validates the supervisor pattern, the subunit pattern, and the combined system separately under WorldSim, and any pattern may be mutated, replaced, or upgraded without rewriting the surrounding architecture.

Failure Modes

The MAST taxonomy from arXiv:2503.13657 categorizes multi-agent failures into three clusters: Specification Problems (~42%), Coordination Failures (~37%), and Verification Gaps (~21%). Emergence addresses each cluster with explicit controls:

  • Specification Problems; brief schemas, success-condition contracts, and identity-scoped policies prevent the parent from under-specifying or the child from over-interpreting.
  • Coordination Failures; hop limits on peer handoffs, supervisor budget caps, and audit-trail enforcement prevent loops, oscillation, and runaway transcripts.
  • Verification Gaps; every subunit invocation produces a structured summary that is validated against the brief schema, and validation failures are governance events, not silent retries.

Subunit Governance Requirements

  • Every invocation records brief, child Unitt ID, scope, budget, and tool allowlist.
  • Every summary records outcome, evidence trail, governance findings, and consumed budget.
  • Cross-subunit memory sharing is explicit and governance-gated.
  • Peer handoffs have configurable hop limits and are logged in a single trace.
  • Supervisor decisions are auditable as first-class runtime events.

Selection Heuristic

Composition When To Select
Single Unitt Short, single-domain workload that fits one context window.
Supervisor / Worker Most enterprise workloads; default Emergence composition.
Hierarchical Workloads with natural sub-domains and >6 concurrent workers.
Peer Handoffs Triage flows, customer-service routing, role-based dispatch.
Peer Debate Verifiable-answer tasks benefiting from independent critique.
MetaGPT-style SOP Greenfield software generation, rigid pipelines with structured artifacts.
ChatDev-style chat-chain Phased dialogue pipelines with phase-parallel work.

Cross-References

  • Memory defines scoped and shared memory tiers across subunits.
  • State defines context isolation between parent and child.
  • System defines the runtime patterns each subunit may run.
  • WorldSim validates and evolves subunit compositions against measured outcomes.
  • Fabric extends subunits into a coordinated multi-agent runtime fabric.
  • Research › Subagents documents selection criteria, citations, and source research.