Skip to content

[Epic] I0 P4: Mechanical Execution: A Program Walks What an Agent Reads Today #532

Description

@m2ux

Summary

A workflow definition describes a structure: an ordered list of steps, tests deciding whether each one runs, loops repeating a body, and named outcomes deciding where control goes next. Today a language model reads that structure and carries it out, guided by prose the server ships alongside the definitions, and the server grades what the model reports back afterwards.

This epic moves that work to a program. It walks the steps, decides each test from the session, drives iteration, resolves what each step consumes, and calls out to an agent only to execute a set of instructions — whose body is prose and stays prose. The agent's job narrows to what only an agent can do: read a protocol, exercise judgement, write content, and answer a question put to a person.

It is the stage of #527 that changes what a run is, and it is built so that it changes nothing for anyone not using it. The program is a client, not a mode of the server. Sessions driven the current way and sessions driven the new way run side by side against one server, and a workflow crosses when it is ready.

What happens today

The structural work is already half mechanical, and the halves are in the wrong places. When the server delivers an activity it runs the shared evaluator over the live session variables for every step, and uses the verdict to decide which step contents to send eagerly. That verdict decides delivery. The same verdict applied to execution is what an agent is currently asked to reach by reading prose.

The surface is entirely tractable. An independent walk of the 122 activity definitions counts 231 inline tests, 97 nested conditions and 54 outcome tests, plus 11 more and one early-exit condition — and every one parses and evaluates, none breaks an authoring rule, and none names anything outside the session variables. The five expressions that ask the environment a question are not tests at all.

A second walker already exists, in the test suite. 895 lines that walk the step tree, evaluate tests, select options, choose outcomes and record what a run covered. It is the reference for what mechanical execution means, and it sits on the far side of the test boundary from the runtime.

Nothing drives iteration and position cannot be recovered. The test walker walks a loop body exactly once, and no code reads the iteration type, the collection, the item variable or the bound. Position is not merely underived but underivable: delivery marks every bundled step as started at the same instant, so no ordering can be recovered from the record.

A cycle bounded by a count is bounded by an agent's arithmetic. The requirements-refinement validation path routes another correction pass while a count stays below three; the update activity declares that count among its writes; and the only thing that advances it is a protocol sentence asking an agent to emit the number for the pass just written. A pass that reports the preceding value leaves the loop with nothing to end it. The contract says so plainly, which is the most the definition layer can offer, because the alternative it would reach for is a set action — also agent-executed, and slated for removal at the next schema major. This is the general condition showing up as an unbounded loop: the count is a session variable, every session variable is agent-reported, and a predicate over one is only as sound as the arithmetic behind it.

Roughly 33,000 characters of every dispatch teach an agent to drive. Protocol rules and worker mechanics that exist for one reason. Alongside them, of the 47 rule entries on the two surfaces that reach every dispatch in every workflow, 23 read as instructions to perform work rather than constraints on it — and the work they describe is the driving loop.

Six rules constrain only the orchestrating role and are delivered to workers, who cannot act on them, on every dispatch.

The work

W1 — The program that walks the definition. A package invoked as an ordinary client, holding the step walk, the test decision, the iteration driver and the resolution of what each step consumes. It reads the structure named in the preceding epic rather than the server's internals, so the two cannot drift and the eventual authoring language plugs in without touching it. A position is durable — the current step, with a frame per enclosing loop carrying the iteration index and the bound item — so a replacement worker resumes at the step after the last completed one rather than re-entering the whole activity.

The unit handed to an agent is the run of steps from the current position to the first test the session cannot yet answer. One agent round trip costs about what 18,800 characters of fresh content cost while the average composed step body is 5,275 characters, so a unit smaller than roughly four steps loses money. A call-out is a turn inside a living agent context, never a fresh one: there are 611 such steps across 117 activities, and paying a 23,000-to-42,000-token establishment for each would multiply the largest cost in the system by five.

A call-out is atomic. 436 of the corpus's 2,459 protocol bullets open with a conditional or a repetition, so control flow lives inside instruction bodies as well as above them, and the program cannot resume one part-way.

W2 — The server derives, and warns before it refuses. The server recomputes each transition from the definitions and the session it already holds. Authority rests on reproducing the result, not on the caller's identity: a client producing correct transitions is acceptable whatever it is, and one producing incorrect transitions is refused whatever it claims. Where an agent reports stopping at a test, the server recomputes that test from the values returned and accepts the stop only if it agrees — the same rule applied one level down.

Refusing outright is staged. The equivalent check only warns today, so derivation ships first as a second opinion recorded beside the reported outcome, the disagreement rate is reported over real sessions, and refusal follows — for new-path sessions first.

W3 — The old path keeps its safety net; the new path stops paying for it. Five checks exist to grade an agent's self-report: the step manifest, the reported outcome, the accounting for a truncated sequence, the activity manifest and the delivery check. While any workflow still runs the current way, those are that path's only fidelity mechanism, so they are withheld from the new path rather than removed. The same for the driving prose: it is not delivered to a new-path dispatch, which banks the saving immediately, and it leaves the corpus when no path needs it.

W4 — The rules that survive the driver's deletion move to where they belong. Of the 23 procedure-shaped rule entries on the two most-delivered surfaces, most describe the loop this epic deletes and go with it. Identify which survive as genuine constraints and give each a destination — a protocol phase, a branch note under one, an activity step, or a policy resource — naming the destination in the change so nothing is deleted without one. Two clauses must survive: the cross-group invariant about a resumed worker's identity, and the one clause found nowhere else in the corpus, that the server restores session state on attach and it is not to be reconstructed.

W5 — Orchestrator-only rules leave the worker bundle. Six rules constraining only the orchestrating role stop being delivered to workers. A delivery-scope change with an immediate per-dispatch saving, correct under both the current and the eventual shape, and needing no new home for them.

Why now is cheap

Every input exists and is already shared. The two evaluators, the outcome-to-destination bindings and the loaders are server code the guards and the test walker already consume. The transition procedure is written down twice — once as prose in the orchestrating instructions, once as code in the test walker — and the two agree.

The walker is 895 lines and passes today. This epic moves it across the test boundary rather than writing it.

The seam was paid for on other grounds. Deriving rather than trusting was chosen to avoid needing a signature. Used here, it is what lets both paths run against one server, which is the whole reason this can be attempted on a system in production use.

Acceptance criteria

  • A program walks an activity's steps, decides each test from the session, drives iteration, and calls out per run of steps ending at the first test the session cannot answer.
  • The session carries a durable position with a frame per enclosing loop, and a resumed run continues at the next step rather than re-entering the activity.
  • A cycle bounded by a count advances that count mechanically, so it cannot run past its bound on a value an agent computed — including a cycle that runs between two activities on an exit predicate rather than inside one activity's loop step.
  • The server derives every transition independently, and a stop an agent reports at a test is accepted only when the server recomputes the same verdict from the values returned.
  • The disagreement rate between the server's derivation and the reported outcome is reported over real sessions before any transition is refused.
  • A call-out returns values keyed by declared identifier, and a return whose shape disagrees with the declared signature is rejected while its content is trusted absolutely.
  • Resolved input values travel separately from the instruction body, so the body stays a pure function of the corpus and delivery still deduplicates it by content.
  • No grading check and no driving instruction is removed while any workflow still runs the current way; each is withheld from the new path first.
  • At least one workflow completes a real production run under each path, against the same server build, with both runs' transitions accepted by the same check.
  • Every rule body on the two most-delivered surfaces states a constraint, an invariant or a prohibition, and each procedure removed is present at a named destination.
  • The two clauses named above survive the deletion.
  • Orchestrator-only rules no longer appear in a worker's bundle, and the per-dispatch saving is reported.

Non-goals

  • Attesting the client. The server accepts a transition because it derives the same one, so nothing depends on knowing which client called.
  • An activity declaring which role executes it. The schema field, its two delivery injection points and its three hand-written rule exceptions are not built: the one activity that needed them runs in the program, so the dispatch it was fighting for does not happen, and its measured 165-second saving arrives free.
  • Batching activities into one dispatch. Batching spreads the cost of establishing a fresh context across several activities; this epic keeps one context alive, so the cost it spreads is gone.
  • Finer dispatch. The gain is that the server decides where a coarse boundary falls, not that boundaries multiply.
  • Parallel execution. One decision at a time, one position per session, parallelism at session granularity through child workflows.
  • Parsing instruction bodies. They are the agent's to interpret and nothing here reads them.
  • A new home for orchestrator-only rules. W5 removes them from the wrong bundle; a home for rules addressed to a role that is being deleted is not built.

Tracking

Each work item is delivered as its own pull request when picked up.

Work item Agent time Gate
[ ] W1 — the program that walks the definition 20–35 h Definition-shape W1 and W2
[ ] W2 — the server derives, warns, then refuses 6–10 h W1; refusal gated on the reported disagreement rate
[ ] W3 — the old path keeps its net, the new path stops paying 3–5 h Safe-ground W3
[ ] W4 — the surviving rules move to where they belong 4–6 h W1
[ ] W5 — orchestrator-only rules leave the worker bundle 1–2 h
Epic total 6–10 days

Item hours and epic effort-days are defined in #527.

W1 is the largest single item in the transition by a wide margin, and it is not divisible: a walker that handles steps but not loops, or gates but not positions, cannot run a workflow. Its range is wide because the call-out protocol has been designed three ways and the choice between them is made during the work.

W2's day count carries a caveat the hours cannot express. Its refusal half is gated on a disagreement rate measured over real sessions, so the elapsed time is set by how quickly real runs accumulate rather than by the implementation, which is small. Plan the effort here and the calendar separately.

Carries #523 in full and #436 W2. Both are closed and their bodies are captured verbatim in the planning folder. #518 W5.1 arrives here as W5, in its reduced form; #436 W1, #404 W3 and W8, and #513 stage 6 are not carried anywhere — see Non-goals.

Investigation detail

The gate census, the mechanism ledger, three independently reviewed designs of the call-out protocol, the cost model, and the record of why the client carries no signature:
2026-08-28-runner-execution-protocol

Two figures there are single-source and unreviewed — the round-trip exchange rate and the per-context establishment cost, which are the two numbers the delivery grain rests on. Both want re-measuring before W1's protocol is fixed.

The rule register produced entry by entry during the canon audit, and the 165-second dispatch: 2026-08-06-engine-surfaces-consolidation. The running order and item-by-item disposition: 2026-08-31-typed-execution-redesign.

Activity

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

    enhancementNew feature or requestpriority: highDo first: high impact, lays groundwork for other worktech-debt

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions