Skip to content

Typed handoff primitive — formalizing Swarm's core pattern #84

Open

Description

@greatmengqi

Swarm's entire orchestration model is one idea: a tool function returns an Agent, and handle_function_result (core.py:71) reassigns active_agent. Elegant and minimal.

I formalized this as a handoff primitive with output type Never — meaning any step chained after a handoff is statically unreachable. This gives you a compile-time guarantee that Swarm currently enforces only at runtime (by silently dropping whatever comes after the agent switch).

Papers:

292 lines of Python, one algebraic primitive. Swarm's design instinct was right — this formalizes why.

Activity

  1. 0xbrainkid commented on Apr 15, 2026

    @0xbrainkid

    The Never output type formalization is elegant — making the "anything after a handoff is unreachable" invariant a compile-time guarantee rather than a runtime convention is exactly the kind of rigor that makes production multi-agent systems debuggable.

    One dimension the typed handoff primitive opens up: trust metadata as part of the handoff type signature. If a handoff carries a type parameter representing the receiving agent, it could also carry a trust constraint:

    @dataclass
    class Handoff(Generic[AgentT]):
        agent: AgentT
        context_variables: dict
        # Optional trust contract:
        min_trust_score: float = 0.0      # refuse handoff if receiver below threshold
        trust_evidence: str | None = None  # URL to behavioral attestation

    With Never as the return type, the type system already guarantees the handoff is terminal. Adding min_trust_score to the signature makes the trust requirement part of the contract rather than an ad-hoc runtime check — the caller declares "I will only hand off to an agent with score >= X" and the framework enforces it.

    This composes cleanly with the DAG completeness proofs in v2 — a DAG where every edge carries a trust constraint is a policy graph, not just a control flow graph. Every path through the DAG becomes an auditable sequence of trust decisions.

    The Zenodo preprints are a useful anchor for this — "trust-typed handoffs" could be a natural extension paper building on the formal foundations you have already established.

  2. greatmengqi commented on Apr 15, 2026

    @greatmengqi
    Author

    Thanks for the thoughtful comment! The trust-typed handoff direction is interesting, but my current research hasn't gone deep into the trust/security domain yet. Noted as a potential future exploration.

  3. ferhimedamine commented on Jun 12, 2026

    @ferhimedamine

    The Never return type nails the control-flow side, but the context_variables: dict in the handoff signature is doing too much untyped work. In practice the real problem with agent handoffs isn't routing — it's that transferring the full context dict is token-expensive and noisy, while transferring nothing forces the receiving agent to reconstruct state from scratch.

    What I've found building a memory layer for multi-agent systems is that handoffs need a MemoryScope type parameter — something that declares which subset of the originating agent's memory the receiving agent actually needs, filtered by relevance to the handoff's task description. Think Handoff[AgentT, MemoryScope.task_relevant] vs MemoryScope.full vs MemoryScope.none. The receiving agent gets a relevance-filtered recall, not a raw dict dump. This turns your typed handoff from a control-flow primitive into a data-flow contract too.

    We hit this exact problem at scale and ended up implementing decay-weighted recall with vector+BM25 hybrid search scoped per agent — the agent isolation model is visible in the deploy config if anyone wants to see one concrete approach. The key insight was that memory scoping at handoff time is where you prevent context pollution between agents without paying the "start cold" penalty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions