Typed artifacts for agentic product development

Agentic runtimes read whatever they find and treat much of it as instruction — a capability in one session, a liability across many. This paper proposes a small type system for a product team's artifacts: nine classes under one rule — authority comes from an artifact's class, never its content. A few of those classes define the actual work: what the team promises, what it's currently doing, and each concrete step along the way. Typed this way, intent stays coherent across many sessions and agents — and the completion-drive that was a liability becomes something you can safely turn loose.

The problem: ambiguity, agents, and authority

Agents grant standing to whatever they find — which works well enough in a single session, but grows corrosive across many of them.

Product development is the work of converting ambiguity into value. Picture it on two axes: how clear an idea is, and how committed the team is to it. Ideas tend to hatch vague and uncommitted; shaping raises their clarity, commitment gives them standing, and execution ships them. Work has to clear both thresholds to be worth building — and work that is committed but still unclear tends to burn time in a danger zone.

Figure 1. The clarity–commitment plane. Shaping moves work up; commitment moves it right; execution picks up only what clears both thresholds. The danger zone is commitment without clarity.

Agent runtimes raise the stakes here, because tools like Claude Code are completionists: given an ask, they drive toward something that satisfies it. They fill gaps in the spec, explore the workspace for anything that resolves ambiguity, and invent when nothing turns up.

Exploration is a capability, but a downstream one. The agent reads the README and greps the code because whatever it finds reduces its uncertainty about what "correct" and "done" mean, so it ends up granting standing to whatever it finds. Discovery-as-authority isn't really a designed architecture; it's just what a completion drive does when you set it loose in a workspace. In a single session that mostly works, but across many it starts to degrade in familiar ways:

Stale instruction files silently steer agents against current intent — a completionist prefers a stale answer to no answer.
One agent's generated prose mints rules for the next agent's run.
Any writable file in the workspace becomes a channel for injecting behavior.
Where the workspace answers nothing, the gap is filled by confabulation.

At high agent volume, where agents write most of what agents later read, the loop compounds.

The failure has a shape: these systems conflate the information channel with the authority channel, because the completion drive treats anything that fills a gap as if it belongs there. What we want is three separate things:

Freedom — to roam across everything the team knows;
Obedience — owed only to what the team has deliberately decided;
Grounding — enough evidence within reach that gaps are filled by citation rather than invention.

The design below has all three: evidence stays open to roam, ratification alone decides what commands obedience, and typed context assembly supplies the grounding.

The bottleneck moves

Session tooling scales execution, but the real constraint lives at the ends of the pipeline.

Even a solo project keeps a TODO file. Intent always exceeds capacity, so every project runs a buffer between wanting and doing. A TODO file, a backlog, and a roadmap are the same buffer at different scales. At human scale its structure barely matters: the reader re-supplies the missing distinctions from memory — committed or wished, fresh or stale, what "done" means. The buffer works because a head sits at both ends of it.

Product work has the same shape: observe, shape, commit, execute, verify, learn. Today's agent tooling scales just one of those stages — execute. Concurrency tools spread a person's attention across more sessions, and duration tools make one session run longer. Both are useful, and both leave the other five stages informal and human-paced.

Making execution cheap moves the constraint to the ends. Wishes are abundant; committed intentions with acceptance criteria are scarce, and humans produce them at human speed. Fifty concurrent sessions do not make fifty units of progress. They make fifty pull requests arriving at one person, who must reconstruct the intent behind each to judge it. Widening the middle of a pipeline piles inventory at its ends.

The safety version matters more, because autonomy runs on an oversight budget, and watching every session grows linearly with session count. Oversight scales only by moving up the stack — from supervising actions to owning intent and outcomes. A session can safely go unwatched when three things hold: what it may do is bounded mechanically, what counts as done is fixed outside it, and what it learned cannot silently rewire future runs. Those are the constraint, spec, and ratification structures of this paper. The idea is to decide more up front so you can watch less live.

The front of the pipeline is fed by the back: desires worth committing come from measured drift, and drift comes from verification, so a better backlog on its own would just fill with imagined work rather than needed work. The two kinds of tooling also spend attention differently: a session approval is consumed once, whereas a ratified policy or a done-when is decided once and then applied to every run that follows. None of this is a new pattern: cheap compilation got type systems, and cheap provisioning got desired state and reconciliation, not better terminal multiplexers.

Models may soon infer intent well. But commitment is accountability, not information: a guess, however good, cannot settle whose want counts or who answers for the outcome. Inference can propose; only standing can commit. And a team of one inherits all of this too — the person who resumes a project after three weeks is, in effect, an agent reading the workspace cold.

The baseline: a repo, issues, markdown, and an agent

Issues and markdown are a typed system whose labels live in your head.

The most popular alternative to this design is lighter, not heavier, and many teams already run it: a repository, an issue tracker, freeform markdown, and Claude Code — the informal version of the buffer above. And it works, because a human supplies the type system at read time. Reading a README, you classify without effort: this paragraph is aspirational, this one is stale, this is a rule the team means, this is a note nobody ratified. Freeform tools aren't untyped so much as typed systems whose labels happen to be stored in wetware.

Seen that way, the baseline is already a knowledge system with one authority rule: whatever is in the repo binds. A CLAUDE.md is a policy set with no ratification act, the backlog is a desire pool with no commitment gate, and TODO comments are moves with no verification. Every class in this paper is already present, just stored in two unlabeled containers. So this paper doesn't propose a different kind of thing — it proposes the same thing with gates on the authority channel: moving labels out of heads, where agents cannot read them, into artifacts, where they can.

An issue makes excellent capture: permalinked, timestamped, threaded. What strains it is being asked to be a desire, a commitment, a plan, and a discussion all in one noun, so keep the issues and just stop asking them to be promises. Adoption follows the same line: a team's tracker and documents already contain every class described here, so adopting means ratifying labels rather than migrating data. The trade runs both ways, too — the design also drops sprints, story points, burndown, and epic hierarchies. Nearly everything stays freeform, because nearly everything is evidence; structure sits only at the authority and commitment joints, and everywhere else there is freedom.

This design grew out of small-team practice, in that same baseline setup, as agents took on more of the reading and writing. It is a working hypothesis with one team's experience influencing it, not a proven method. Nothing here claims freeform practice fails. It describes what one team reached for when the labels in its heads stopped being readable by the agents doing the work.

Foundations: three attributes

Every artifact gets three labels: what kind of utterance it is, how processed it is, and what it may do to an agent.

Type of utterance

Artifacts differ in what kind of utterance they are. The classification comes from speech-act theory: Austin's observation that saying something is often doing something (How to Do Things with Words, 1962), and Searle's taxonomy of the kinds of doing (1975). Three of the four types here are Searle's; records are an addition the append-only layer needs.

Assertive — a truth-apt claim about the world: metrics, as-built descriptions, reproduced bugs. Assertives can be wrong, and they can go stale.
Directive — an action-guiding rule: a standing conditional of the form "when X, do Y." Followed or violated, never true or false.
Commissive — a commitment: fulfilled, broken, or withdrawn.
Record — a claim about what happened: append-only, never stale, because the past does not change.

Derivation level

Artifacts also differ in how processed they are, in a pipeline familiar from data engineering. Derivation level largely sets volume and loading behavior.

Raw — high-volume and uninterpreted: threads, tickets, transcripts, exports. Retrieved on demand, never loaded wholesale.
Derived — extracted and shaped; every derived artifact cites the raw material it came from, so a reader can descend and verify. Loaded filtered.
Canonical — the small, curated, authoritative surface: the current policy set, active promises, open threads, verified facts. Always loadable, because it is kept small.

Authority

The third attribute is what an artifact is entitled to do to an agent's behavior, and the harness enforces it, not the runtime. The runtime is the completionist inside the loop; it weighs whatever enters its context roughly equally and cannot police what binds it. The harness is the system wrapped around the runtime — it assembles context, dispatches runs, and verifies outcomes — and it is the only place authority can be enforced. Here too, four levels are enough.

Constraint — binds. The agent cannot proceed past it, and the harness enforces it mechanically.
Guidance — biases judgment without blocking.
Spec — defines an outcome and what counts as reaching it — never the steps to take. Three classes carry it, at three nested scales.
Evidence — informs. Consulted and cited, never obeyed.

Authority is the attribute that is directly a security property:

Content never carries authority; only classification does. A document that says "always do X" is evidence that someone wrote that — nothing more — until someone with standing ratifies it into a class that binds.

This rule is also the prompt-injection boundary: raw material is full of imperative-sounding text, and the system makes it structurally impossible for that text to bind an agent, wherever it appears — a Slack message, a README, a comment in generated code.

Once text is inside a context window, though, no harness controls how the model weighs it. A hostile instruction in a capture can still influence the session that reads it, so the separation of channels relies partly on prompt discipline and the runtime honoring it. What is structural is the boundary around a session, not the model's behavior within one: unratified text never enters the compiled authority preamble, hard guards ignore what the model believes, verification rejects a deceived agent's claims, and nothing a session was talked into can ratify itself into the knowledge layer. Injection can bend a single run, but it cannot mint durable authority or compound across sessions.

The artifact classes

Nine classes: one binds, one guides, three task, and everything else informs.

The full cross-product of the three attributes yields dozens of cells, most of them incoherent. The nine combinations below are the ones that have recurred enough to highlight.

Class	Utterance	Derivation	Authority	In one line
Capture	record	raw	evidence	Immutable observation: threads, tickets, transcripts, exports, run exhaust
Fact	assertive	derived / canonical	evidence	Cited, dated claim about the world; its strength follows what it cites
Desire	commissive embryo	derived	evidence	A shaped want with explicitly no standing
Promise	commissive	canonical	spec	Durable commitment — "X is true for Y"; honored or broken, never "done"
Thread	commissive	canonical	spec	Episodic execution arc opened against a drift; done-when defines closure
Move	commissive	derived	spec	Agent-owned plan atom: one verifiable assertion; lands when its check passes
Policy	directive	canonical	constraint	Enforced rule; one current answer per question
Principle	directive	canonical	guidance	Advisory value; violation is a conversation, not a blocked merge
Decision	record	derived	evidence	Append-only entry logging a promotion, ratification, or ruling

The authority column collapses to something legible: one class binds, one guides, three task at nested scales, and everything else — most artifact volume — is evidence, structurally incapable of directing an agent's behavior. It can inform a run, never steer one.

Figure 2. Zones and authority. The gray evidence classes inform; the coral pair governs; the plum triad defines work. Entities sit outside the system, reachable by name only. Border treatment encodes authority.

Three rows get one more line each. A desire's lack of standing is what keeps the backlog from lying: most ideas never get built, and the pool says so instead of pretending. A policy holds one active answer per question it covers, so "what applies now" never means parsing timestamps across a history. A decision points at what it created rather than containing it — the classic ADR is one species, and the live rule it produced stands separately in the policy set. Commitment itself — turning a desire into a promise, or opening a thread — belongs to humans, or to roles explicitly delegated it, because commitment is where accountability lives.

The spec triad

The three spec classes fix an old failure — call it the single-noun problem. Teams need a middle layer durable enough to commit against, yet also episodic enough to have a start and an end, and those are different things. Every noun asked to be both — the Epic, the Initiative, the Workstream — ends up state-shaped in some sentences ("the search capability") and motion-shaped in others ("the search overhaul"): a commitment and an arc at once, neither clearly.

The fix is to split the noun, and this system splits it twice:

Promise — state-shaped and durable: "X is true for Y." Honored or broken on a continuing basis; never completed.
Thread — motion-shaped and episodic: an execution arc opened against a specific drift. It carries done-when criteria — observable conditions that mean the drift is gone — and closes when they verify.
Move — the plan atom inside a thread: one declarative assertion ("an index exists on the column," "the regression test passes") with a check that verifies it landed.

Collapse promise into thread and you get the Epic. Collapse move into thread and you get a subtler failure: acceptance criteria and plan steps interleaved in one list, so revising the plan means touching the definition of done.

Kept apart, the three give three completion predicates — honored-when, done-when, landed-when — and a clean ownership split. Done-when is human-ratified, because it is the edge of the commitment. The move plan is agent-owned: the agent may propose, reorder, and abandon moves freely, because closure rests only on done-when verifying in the environment. This is why autonomy and safety stop trading off. An agent with no plan authority pushes its planning into throwaway session files; an agent with done-when authority defines its own success. The triad gives it the middle.

Evidence and the world: captures and entities

Cite what cannot change, name what can, and let strength stay visible.

The word "source" collapses three different things (the provenance of information, source code, and data-emitting systems), and the collapse causes design confusion. The system separates two categories with opposite semantics:

Capture — something that happened, frozen at the moment of observation: a Slack thread as ingested Tuesday, a bug report as filed, a session transcript, a metrics export, a Git commit. Immutable by nature; never stale, because the past does not change; cited by content.
Entity — something that persists and changes: a running service, a repository at HEAD, a customer, a third-party API. Outside the system's custody; named rather than cited; any description of one starts decaying the moment it is written.

Entities emit; the system captures. If it can change after you look at it, it is an entity; if it cannot, it is a capture.

Figure 3. Entities emit; the system captures. Facts connect the two: they name entities, cite captures, and carry the verification dates that track decay. If it can change after you look, it is an entity; if not, a capture.

It is worth asking why the system holds captures at all. The answer isn't caching: a cache treats the original as authoritative and the copy as disposable, whereas captures invert that. Slack retention expires, logs rotate, tickets get edited — so the copy inside the system is often the only durable record. This is custody, closer to a court exhibit than a CDN object, and not every capture even has an external original: transcripts and harness events are born inside the system.

A strict version of this layer makes custody an admission rule: a fact may cite only what the system holds, and a bare URL does not qualify. Clean in theory, an adoption cliff in practice — teams live in tools whose contents cannot all be ingested, and a system that refuses to record "the dashboard says X" records nothing. The rule here is a gradient instead:

The evidence strength rule: a fact's evidentiary strength follows the citability of what it cites — held bytes are strong, delegated immutability (a commit hash) is strong, a name (a URL, a ticket id) is weak. Citation is never forbidden; strength and staleness are derived from it, visibly.

The gradient keeps the incentive without the cliff. A fact citing a capture is trustworthy in a way a URL-citing fact is not, and the system says so — in quality scoring, staleness tracking, and context assembly — instead of refusing the weaker fact. The gradient also gives a delegation test: Git commits are citable in place, because content-addressing supplies custody for free; a SaaS ticket ID is a name, because tickets get edited. Ingest the ticket and the name becomes a capture — the move the gradient rewards.

Strictness stays where it is free: exhaust born inside the system is always captured. Run transcripts, verifier output, drift reports, compiled bundles — none has an external original, and none is costly to hold. The run transcript is the system's richest evidence about itself.

Source code is where the split shows its work. The repository at HEAD — the living thing agents modify — is an entity, described by facts that decay, while every commit is already an immutable, content-addressed capture. So facts about code cite commits, while threads and promises target the repo, and telemetry, dashboards, and the rest of the emitting world divide the same way. The staleness asymmetry follows: a fact grounded in captures ("the July 3 export showed 340ms") never becomes false, while a fact about an entity ("p99 is 340ms") starts decaying at birth. Only the second kind needs a verification date.

Cite the strongest evidence available, name what you must, and keep the difference visible.

Promotion and the decision log

Four verbs move artifacts between classes, and every use of one is logged.

Artifacts change class through a small set of promotion paths, each logged:

Extraction turns captures into facts.
Shaping turns captures and facts into desires.
Commitment turns a desire into a promise, or opens a thread against a drift — the crossing of the commitment threshold from Figure 1, made concrete as a gate.
Ratification turns a desire, or an incident's lessons, into a policy or principle.

The readiness criteria a thread must meet before opening (clear intent, verifiable done-when, a judgment gate where intent is subjective) are themselves a policy about threads. That turns the danger zone of Figure 1 into something a harness can lint: nothing enters committed state unclear, the same way no code merges without passing tests. One path stays deliberately ungated: agents propose and revise moves freely inside an open thread. The plan carries no authority over what counts as done — a move is ratified by landing, not by review.

Figure 4. Promotion paths. Gates sit on the crossings that mint authority; each promotion drops an entry into the decision log automatically. Move proposal, below the commitment gate, is deliberately ungated — moves are ratified by landing.

Urgency enters through policies that tie artifact attributes to promotion speed: "sev-1 facts auto-shape to threads within 24 hours" is a ratified rule rather than an exception. And because every promotion logs a decision, the log becomes the system's telemetry about itself — how long desires sit, what fraction of threads get abandoned, which policies keep getting proposed. Reflection consumes that stream.

The process layer: the plan is an artifact, execution is not

Moves sit above the durability boundary, while runs, sessions, and plan files sit below it.

Runs, sessions, and turns appear nowhere in the class table, and that is on purpose. Artifacts are durable and slow-changing, whereas a run is fast and ephemeral, holding transient state (context windows, tool calls, intermediate files) that would poison the knowledge layer if kept. The type system defines execution's interface without containing it:

a thread defines what a run is for;
the dispatched moves define what this run should land;
policies define what the run may do;
facts and captures are what it consults.

Execution is what happens between artifact states, not an artifact state. The analogy is a legal system: statutes, contracts, and case records are artifacts; a trial is a process. Nobody files the trial — they file its transcript and its verdict.

The boundary could plausibly sit one rung higher, keeping the plan out of the table too. But the plan is a legitimate artifact: durable across sessions, needed for resumption, owned by an identifiable authority. What must stay out is liveness — which run is executing, how far along — and that belongs to the harness. So: moves above the line, runs below it.

Figure 5. The reduction ladder. Three completion predicates at three scales above the durability boundary; below it, everything is process whose exhaust is captured at run end. The authority boundary sits between Thread and Move: done-when is human-owned, the plan is agent-owned, verification is always the harness's.

One rung below the boundary sits the session plan: the plan.md or todo list an agent writes for itself. It is the right tool at its timescale — an agent decomposing its dispatched moves into turns. The failure mode of bare runtimes is that this file is the only plan layer, and it evaporates with the session: the fragmentation the knowledge layer exists to fix. With moves above the line, the session plan becomes cheap by design — regenerated at each dispatch, its residue flowing back as move status and captured exhaust, never as authority for the next session.

The distinction also untangles a term teams chronically overload. Acceptance criteria are a thread's done-when: outcome-level, fixed at open. The scrum-style "Definition of Done" (tests written, docs updated, review passed) is not any thread's criterion — it applies to every move in every thread, which makes it a policy: ratified once, compiled into every run, appended to every move's verification. Per-thread edges and every-thread floors live in different classes. Most arguments about "DoD versus acceptance criteria" dissolve once they do.

Run exhaust maps onto existing classes completely:

The transcript enters as a capture the moment the run ends.
Completion or failure is a decision.
Anything worth keeping is proposed as a fact or a desire.
What remains is in-flight state, and that belongs to the harness — much as Kubernetes owns pod state while Git owns manifests.

The three loops

Three loops run underneath all of this, and they are easy to conflate. They are where the pipeline from Section 02 becomes operational: reduction is the middle, measurement and decision are the ends. Each is level-triggered — it derives its work from current state, never from remembered continuity.

The reconciliation loop — the harness measures. On a cadence or a trigger, it re-derives observed state everywhere: each promise's honored-when, fact staleness, untriaged captures, instruction files with no ratified counterpart. Its output is ranked drift; its dispatches are knowledge work — triage, probes, reflection.
The run loop — agents reduce. Per open thread: pick the ready moves, compile context, dispatch, verify landed-when, re-check done-when, requeue or close. Its dispatches are product work.
The authority loop — humans decide. The harness maintains the queues (attention, proposals, held items); accountable roles work the gates: shape, commit, ratify, release. Nothing in the other two loops can mint authority, so this loop is where all of it enters.

Operational commitments make the first loop concrete. "Every reported bug gets a triage verdict within 24 hours" is a promise like any other: state-shaped, measurable, capable of drifting. Real teams carry such commitments implicitly; the type system forces them to be written down, and once written, an untriaged ticket is drift the harness can see and close. Autonomous triage is safe for a structural reason too: everything a triage run can produce is evidence-class, so no gate is needed.

The repository

The repo holds the product plus compiled projections; the knowledge layer holds the originals.

Where does source code sit? Outside the classes entirely: it is the referent the system exists to produce. The knowledge layer holds artifacts about the codebase — facts describing its architecture, policies constraining how it changes, threads open to modify it — while the code itself lives in the ordinary Git, build, and deploy world. repo:acme/webapp is a name governed by the naming policy; claims about it are facts; and commits are its captures.

More interesting is that a repository is full of documents that look like code but are really knowledge artifacts in disguise, already compiled into executable form. Lint configs, CI pipelines, branch protection, and CODEOWNERS are compiled policy. The discipline that follows: the canonical policy artifact is the source of truth, and repo config is generated from it or verified against it. Otherwise the written policy and the enforced behavior drift apart, and agents obey the linter, because the linter is what actually binds. Enforcement config with no corresponding policy artifact is an unratified constraint operating by fiat — and the promotion path runs backward: extract the rule, ratify it, log the decision.

Prose documents are the messiest case, because a README interleaves facts, policies, principles, and instructions in one file. Under high agent volume they are evidence with no authority, the same rule as a Slack thread. A README saying "never touch the legacy module" does not bind an agent; the ratified policy citing that README does. This matters most in repos agents write to: a generated README must not silently mint constraints for the next run. The injection boundary, applied inside the repo.

Traffic flows the other way as well: the codebase is the best raw material for as-built facts. What the architecture actually looks like should be derived from code by agents, cheaply and repeatedly, rather than hand-maintained — the code is ground truth, the fact layer a cited, staleness-tracked projection of it. Regeneration is cheap enough that as-built facts stay fresher than any hand-written architecture document ever did. The placement rule in one line: the repo holds the product plus compiled projections of knowledge artifacts; the knowledge layer holds the authoritative versions and everything derived.

Context assembly and the runtime contract

Context stops being retrieval over markdown and becomes a typed query.

The payoff of the type system is that assembling an agent's context becomes a typed query with per-class loading rules. Given a thread, the harness loads:

the full current policy set — always; it is small by construction;
the principles;
the thread's frame and move plan, with the dispatched moves foregrounded;
the verified facts its promise carries;
retrieval on demand into the capture layer, when the agent needs to verify a citation. Decisions load only for archaeology.

Scope supplies the boundary of relevance: the thread, its promise, and the workspace, rather than a similarity search over everything. The agent is handed the facts that matter instead of reconstructing them every run.

Figure 6. Context assembly. Typed inputs converge into a compiled bundle; the session retrieves evidence on demand and emits its transcript back into the capture layer. The policy set always loads; captures load on request; the thread's scope picks the facts.

The compile edge is how the design coexists with today's runtimes. Agentic tools keep their native discovery mechanisms; what they discover is generated. The harness compiles CLAUDE.md (or whatever instruction format the runtime respects) from the policy set, principles, and dispatched moves at run start, giving every instruction a provenance trail. Instruction files with no ratified counterpart are surfaced as anomalies — quoted to a human, proposed for promotion — rather than silently obeyed or silently ignored. Today's runtimes weigh everything in context roughly equally, so the harness enforces the channel split from outside: control what enters at assembly, compile authority into the formats the runtime respects.

The runtime contract

Compilation assumes something on the other side. The harness can wrap any runtime, but it asks four things of one:

Selection — work goes to a persona: a named profile bundling model, tool surface, skills, permission posture, and trust level. The harness picks the persona per dispatch, and the persona is the unit trust and delegated authority attach to.
Injection — the compiled bundle and the persona's skills enter through whatever channels the runtime respects: system-prompt append, generated instruction file, tool-server resources. Every injected item traces to a ratified artifact.
Enforcement — each policy compiles to the strongest tier the runtime supports: a hard guard (a hook that denies a tool call), a sandbox boundary, or prompt-plus-audit. Each policy records the tier it received, and prompt-only enforcement reads as weak — the same false-confidence discipline as the evidence layer.
Observation — the runtime owes the harness a session id, a streamable transcript, and an exit status: the raw material for captures, audit, and liveness.

The most important guard is that the knowledge layer has a single writer. Agents propose facts and desires through tools; the harness files their exhaust. Where a runtime lacks hooks, enforcement degrades to sandbox plus transcript audit — nearly free, since every transcript is already a capture — and a violated policy becomes an anomaly, then a reflection finding. A guard config injected into a session is the same class of thing as a lint config in CI: compiled policy, one layer down.

Does the model limit agent capability? The limit lands on the authority channel, where predictability is the goal, and barely touches the information channel, where capability lives. An agent still roams the filesystem, reads every README, and cites anything it finds. On the plan — the channel where agent judgment is the point — it holds authority of its own. What it cannot do is treat discovered text as binding, or redefine what counts as done. The shape of it: explore everything, cite anything, plan freely, and obey only what is ratified.

Multisession operation and reflection

Strictness is what makes the work resumable.

Priced against a single session, this structure looks like friction: an agent's mid-run insight must wait for ratification instead of being written into its own instruction file. Priced against the actual unit of work — an effort spanning months, paused and resumed — the accounting inverts. Most of the friction turns out to be the mechanism multisession work depends on.

Self-modification is the sharpest case. Within one session, an agent editing its own instructions is a tight learning loop; across sessions it is unversioned state accumulating in the authority channel: session twelve inherits instructions mutated by sessions three, seven, and nine — each encoding a lesson from a context that no longer exists, none reviewed, some contradictory. Without ratification, no moment exists at which anyone asks whether the lesson still applies. Persistent shared state needs write discipline, here as everywhere else in software.

Reflection supplies the learning loop that self-modification approximates badly. The insight lands as a proposed desire or draft policy plus a decision entry, and reflection reviews accumulated proposals with cross-thread visibility no single session had: this lesson was proposed four times across three threads; it conflicts with a policy ratified in March; here is the recommendation. Session-local adaptation samples one trajectory; reflection integrates over many. An agent that instantly self-modifies is doing online learning with batch size one and no evaluation set.

Resumption makes the same case from the other side. Picking up an effort after three dormant weeks means knowing what currently binds versus what was contextual to the last session. If authority lived in accreted prose, resumption would be archaeology. With typed artifacts it is a query: open threads and their move plans, current policy set, recent decisions. What survives as a cost is ratification latency — a good lesson waits, and human attention gates the policy-update rate. That is a tunable parameter: ratification can be delegated to agent roles for low-stakes policy classes, with formatting conventions auto-ratifying under logging while safety rules keep a human gate. The structure holds; the throughput scales.

A worked example

One bug, from customer report to closed thread.

Each step gives the actor, the action, and the artifact touched.

A customer files a bug report. The harness ingests the ticket as a capture: a claim, not yet an established problem.
The harness, reconciling, finds drift on an operational promise ("every reported bug gets a triage verdict within 24 hours") and dispatches a triage run.
The triage agent reproduces the failure and proposes a fact — "checkout fails when the cart holds a discounted item and a gift card" — citing the ticket and its own transcript. Duplicate tickets add citations to the same fact.
The harness, on the next pass, flips the checkout promise's Observed face to no. A drift instance (regressed, citing the fact) enters the attention queue. Drift is always the harness's computation, never anyone's assertion.
The product owner, working the queue, shapes the fact into a desire, which waits with no standing — not every verified bug gets fixed, and the pool says so. Later the owner commits: writes the done-when (the reproduction fact becomes false), passes the readiness policy, and opens a thread against that drift. The thread is the commitment; no new promise is minted. The act emits a decision entry, and the harness derives the thread's opening drift from the done-when.
The build agent, dispatched on the next work cycle, proposes moves: add a regression test, fix the interaction, add an alert. Moves are agent authority; no ratification.
The harness runs the ready moves — one per session or several batched, verification per-move either way — checks each landed-when, files each transcript as a capture, and closes the thread when the done-when verifies. If the retro finds the root cause systemic, the team ratifies a policy: the incident-to-rule path.

The original tickets never change; the layers above them flip state. An updated fact records the release that fixed it.

This is the discretionary lane, where a human decides the work is worth doing. Most bugs travel a delegated lane instead: a standing promise plus a policy that delegates commitment for that class, so the harness opens the repair thread itself and logs the decision. The threshold between lanes is delegated-versus-human commitment — itself a policy, so a team tunes its own ceremony level.

Design rules

The whole system, in eleven lines.

Authority derives from class, never content. Imperative text anywhere — Slack, README, generated code — is evidence until ratified.
One class binds, one guides, three task at nested scales; everything else informs. Most artifact volume cannot direct an agent's behavior, by type.
Promises are honored, threads close, moves land. Three completion predicates; conflating any two is the single-noun failure.
Done-when is human-ratified; the move plan is agent-owned; verification is always the harness's. The authority split lets autonomy and safety coexist.
Evidence strength follows citability. Held bytes and delegated immutability are strong; names are weak but admissible. Everything born inside the system is captured.
Every promotion emits a decision. The paper trail is exhaust from the mechanism, and it is the substrate reflection consumes.
Desires have no standing. The uncommitted pool is where sorting happens plainly, instead of through a backlog treated as a promise.
Policies carry current-set semantics. One active answer per question. A team-wide Definition of Done is a policy, not a criterion.
Execution is a process; the plan is an artifact. Moves sit above the durability boundary, runs below it; liveness belongs to the harness.
The repo holds the product plus compiled projections; the knowledge layer holds the authoritative versions. Enforcement config without a ratified policy is an anomaly to surface.
Commitment and ratification are acts of accountable roles. Human by default, delegated explicitly, logged always; delegation breadth is the throughput knob.

None of this replaces the runtimes or the workflow engines; it wraps them. The harness assembles typed context in, enforces policy during, and files typed exhaust out. The knowledge system in between is what lets a team's intent stay coherent across sessions, agents, and months of product-making.