Research / Context track

How agents are born, promoted and retired

Six stages, from a platform where developers assemble versioned blocks to an engine that grows each user’s agents from their usage and retires them on evidence. Scroll, or press play: watch who authors the agent, what gets versioned, and what decides a promotion.

  1. Part 1theory

    Context as a Service

    A second question: maintaining one agent is feasible, maintaining a hundred is not. The answer is to stop writing agents as monoliths.

    • The Context Block: declarative and immutably versioned, holding a model, tools, a memory scope, logic, and its own evals.
    • Application, environments, blocks, with consistency tests between the blocks of an environment.
    • Two levels of versions, block semver and an application snapshot. Promotion from dev to stage to prod, with atomic rollback.
    • Definition on the platform, invocation in code: a new prompt ships without a redeploy.
    • Point the code at a floating latest, or pin an immutable version.
    • Any model provider: the block holds a pointer, not a dependency.
  2. Parts 2–5from the memory track

    Borrowed from the memory track

    Part 7 lists what each earlier article contributed. Three pieces cross over from memory to lifecycle.

    • From User-Centric Context Engineering, the trust model: write optimistically, let a human correct afterwards.
    • From UX-Driven Agent Memory, a law: typed blocks earn permanence through use, from temp to project to fundamental.
    • From Agent OS, the Force Override: a human can always interrupt.
    • From the APU, a measured baseline: 78% of queries served by L1.
  3. Part 6forthcomingdraft

    Context Switch Engine

    The link between switching contexts and creating them. The article is still being written, but parts 7 and 8 already build on it.

    • A Merkle DAG context store: every context state is a commit of content-addressed blocks, and a switch loads only the diff.
    • A rupture detector that cuts a conversation into episodes, later reused by the CLE.

    Described from parts 7 and 8 until it is published.

  4. Part 7theory

    Context Lifecycle Engine

    Every multi-agent system fixes its topology at design time, for every user, forever. The CLE lets it grow from each user’s usage instead.

    • The developer assembling blocks. A synthesiser composes candidates from a library of hashed, already-evaluated components.
    • Environments as the promotion path. Seven states replace them, from pattern to pinned, then deprecated, archived, and resurrected.
    • A signal that needs no prediction: iterations before a result. Reformulation triggers a repair, recurrence an automation.
    • Evidence required on every upward transition, and an abandonment guard: a user who gives up is not a success.
    • The Force Override becomes a maternity ward: a human approves every birth.
    • Auto-approving candidates built only from pinned components: possible later, out of scope for v1.
  5. Part 8theory + code

    Build, Ship, Run

    Reread the next day, part 7’s YAML was a Dockerfile. Docker is not the model: it shares the same ancestors, and gives a vocabulary everyone already holds.

    • A build step: resolve every reference, run the components’ evals, assemble and hash. Definition errors fail before any user sees them.
    • The YAML and the image become two objects with two hashes. Lifecycle tags attach to images.
    • Image and containers: metrics per container, decisions per image. Volumes hold the state, and the agent cannot read its own scores.
    • topology.yaml, written by the CLE and audited by humans. Governance is git log topology.yaml.
    • A trigger adjustable at runtime. Rejected: the trigger is the agent’s identity.
    • Namespaces, cgroups, Docker networking. Not taken: the analogy is structural, not a security claim.

    Architectures are mines, not templates.

  6. Measurementmeasurement

    The cost of trusting AUC

    The measurements part 8 promised, on pairs humans had already judged: Stack Overflow questions closed as duplicates by moderators.

    • at 10.1% false positives, gemini-embedding-001 leads (73.9%) and free word overlap is last (62.2%)
    • at 1%, the order inverts: word overlap first (27.0%), Gemini fourth (23.1%)
    • intents grouped like the moderators: 32 of 48, against ~2% at random
    • local MiniLM within 6.7 points of the best hosted model
    • gemini-embedding-001 against -2 on the same texts: cosine 0.04
    • A norm guard at the boundary that refuses a vector from a foreign embedding space instead of normalising it.
    • A dedicated vector database. Not justified: exhaustive search stays under 3 s at a million vectors.
    • BigQuery for measurement only. The engine and its tests never touch it.

    Benchmark your operating point, not your model.

The other half of the series

What an agent is allowed to know

From Context Cascade Architecture to Urithi.