Systems Around Models

Architecture study · implementation pinned

DeepSeek Harness and Cordis

A source-pinned study of a concrete coding loop, an event-derived session model, and a plugin runtime designed to make ownership and teardown explicit.

Inspected 47f943859bef60e4160492346772ded9b24f765a · IP · refresh needed · Last reviewed 2026-08-22

Evidence boundary. Mechanism claims below are implementation-pinned to DeepSeek Harness 47f943859bef and Cordis 8cc9e33fab69. They are not a production-readiness claim. The newer upstream head remains a named refresh target.

Upstream refresh target is DeepSeek Harness b150a551b8d465e31e418e1b2eaf5e79bbb7d28e at package 0.1.1-rc.2.

Responsibility map

System boundary

DeepSeek Harness owns one coding agent's turn and step lifecycle, context assembly, capability dispatch, session facts, and runtime projections.

Cordis owns in-process composition through contexts, services, dependencies, lifecycle fibers, and registered inverse effects.

The developer and surrounding product still own outcome acceptance, production policy, and consequences outside the local runtime.

Common comparison grammar

Normalized topology

Normalized responsibility topology
  1. AdmitownedThe concrete loop admits session input into a turn and preserves even rejected zero-step attempts.
  2. AssembleownedPlugins assemble prompt sections
  3. BindownedCordis services compose tools
  4. RunownedA concrete turn and step loop streams the model and dispatches bounded
  5. RecoverownedSession facts
  6. Verify and closeexternalRepository checks cover runtime contracts while the developer or product owner accepts the outcome.

Lifecycle trace

One complete run

The trace names the owner and observable outcome of each established transition. An unknown path stays unknown rather than being filled from an adjacent product.

  1. 01

    Compose runtime

    Owner · Cordis host

    Profiles and plugins create one effective capability and policy tree.

  2. 02

    Admit turn

    Owner · Agent loop

    Input enters a durable turn with scoped session and provider context.

  3. 03

    Run step

    Owner · Agent loop

    Model output and tool calls become normalized

  4. 04

    Persist and project

    Owner · Session services

    Durable facts feed request

  5. 05

    Drain or unload

    Owner · Lifecycle fibers

    Owned work settles and reversible registrations unwind in reverse order.

Where responsibility lives

State, authority, recovery, and proof

Context
Prompt sections, tool schemas, session events, and provider preparation compose a model-visible request per step.
Canonical state
Normalized session events are durable facts from which requests, trajectories, persistence views, and interfaces can be reconstructed.
Tools and authority
Host policy, approvals, guards, sandbox providers, and credentials bound execution within a declared single-operator developer-preview trust model.
Interruption and recovery
Durable steps close on cancellation or request error, persistence repairs interrupted turns, and plugin lifecycles drain owned work before teardown.
Verification and closure
Extensive repository checks verify implementation contracts; project outcome acceptance and production readiness remain external.

Deliberately remains outside

  • The runtime does not supply a whole-product acceptance authority, prove plugin cleanup semantics, or establish production multi-tenant security.

Mechanisms worth retaining

How the system carries responsibility

01

One reconstructable session record

Normalized session events feed provider requests, trajectories, queries, persistence, and interface views. The useful invariant is not merely that events are logged, but that model-visible history can be derived from them.

02

Overlap execution, preserve causal commit

Concurrency-safe tool bodies may overlap within bounds. Exclusive calls form barriers, while results and deferred context commit in model order so wall-clock timing does not rewrite durable meaning.

03

Reversible ownership

Cordis associates registrations and cleanup with lifecycle owners. Unload can unwind those effects in reverse order, making residue testable without pretending that arbitrary external effects are reversible.

Transfer, with boundaries

Adopt, adapt, or reject

Adopt
Adopt reconstructable session facts, frozen attempt inputs, and explicit lifecycle ownership for long-lived registrations.
Adapt
Adapt reversible plugin effects behind a stronger authority model and separate external-effect reconciliation contract.
Reject
Reject the assumption that in-process cleanup proves semantic rollback, production security, or whole-product acceptance.

Limits, not footnotes

Failure boundary

  • A correct inverse is an author obligation; the runtime cannot prove that cleanup restores the intended semantics.
  • The documented trust model is a developer preview and does not establish multi-tenant or public-network security.
  • The inspected mechanism pin trails upstream head b150a551b8d465e31e418e1b2eaf5e79bbb7d28e.

Test your model

Retrieval check

Why can the runtime overlap two tool bodies but still commit their durable results in the model's original order? Name the property this preserves, then explain why reversible plugin cleanup does not imply rollback of an external payment.