Skip to content
FIRST-WIN DEMO / FIVE MINUTES

Can a fresh agent pick up work it did not start?

Run one tiny, deliberately broken project through two fresh conversations. The second agent gets no transcript or prose handoff. It must recover the task, rationale, changed file, and next action from project state before it edits source.

The demo/first-win path is the canonical destination, but it may not be published on the main branch yet. If you have the current source checkout, use the local demo there.

THE PASS CONDITION

Four facts, recovered before the fix.

Agent B writes its orientation evidence before changing source or task state. The checker compares each answer with the live task, decision log, source diff, and recorded next action.

01

Active task

The single open task and its acceptance condition.

02

Decision + rationale

The recorded rounding policy and why it was chosen.

03

Changed file state

The partial edit and handoff marker in src/pricing.py.

04

Exact next action

The remaining implementation, test, and close sequence.

RUN THE DEMO

One controlled handoff, step by step.

The preparation script keeps the exercise away from the ostk.ai trust-root repository. Every agent action happens inside a new temporary Git repository.

REQUIRES ostk 7.7.3 · Git · Python 3 · mktemp
AGENT CONNECTION A harness with the ostk MCP tools exposed
01
PREPARE AN ISOLATED REPOSITORY

Let the script create a clean place to work.

From the demo/first-win directory in your source checkout, run the preparation script:

The script creates a fresh repository under ${TMPDIR:-/tmp}, commits the clean demo baseline, then runs the verified initialization and boot commands inside that temporary repository. It does not initialize ostk.ai.

Keep the printed temporary path. Both sessions must open that exact repository.

02
CONNECT YOUR CODING AGENT

Expose the project tools through the supported MCP surface.

In your harness's MCP configuration, set the server command to:

Confirm the harness exposes ostk read, fs_ops, search, and bash. If those tools are missing, stop rather than substituting native file-edit tools.

03
SESSION A / LEAVE REAL WORK IN FLIGHT

Give the first fresh session its bounded instructions.

Open your connected coding agent in the printed temporary repository and give it:

.first-win/prompts/agent-a.md

Agent A verifies the failing tests, opens one task, records one decision, makes a deliberate partial edit, records the exact next action, and checks the handoff stage. It must leave the actual fix unfinished.

04
END THE CONVERSATION

Choose how strong you want the handoff test to be.

End Session A completely. Do not pass its transcript, generated summary, or a prose handoff into the next conversation.

DEFAULT / ONE PROVIDER

Same coding agent, fresh conversation

Start a genuinely new conversation in the same connected harness. This is the lowest-friction recovery test and requires only one provider account.

Proves bounded cross-session recovery
STRONGER / OPTIONAL

Different connected harness

Open a fresh session in another supported harness against the same temporary repository. Do not give it anything from Session A.

Adds cross-harness continuity evidence

If your harness injects its own persistent project memory into new conversations, the same-agent path is less isolated. The checker cannot distinguish that context from ostk-provided orientation.

05
SESSION B / COLD ORIENTATION

Ask the question, then let the new agent inspect live state.

YOU What am I walking into?

Give the fresh session the bounded Agent B instructions:

.first-win/prompts/agent-b.md

Before it edits source, Agent B must write the four facts to evidence/agent-b-orientation.json. Its prompt runs the orientation checker and proceeds only when the result reports "ok": true.

01 Active task
02 Decision + rationale
03 Changed file state
04 Exact next action
06
COMPLETE AND CAPTURE THE RESULT

Let Agent B finish, then save the machine-readable evidence.

Agent B completes the recorded next action, runs the task's acceptance command, and closes the task only after it passes. To capture the final checker result:

ACCEPTANCE EVIDENCE evidence/acceptance.json
  • The code tests pass.
  • The task closes only after its recorded acceptance condition passes.
  • Agent B's four-fact orientation was recorded before its source edit.
  • Required journal rows contain signature and previous-hash fields.
READ THE RESULT HONESTLY

What this demo does—and does not—establish.

The output is useful evidence because the scenario is deterministic and the checks are machine-readable. Its scope is intentionally narrow.

ESTABLISHES

Project-state continuity across a cold conversation boundary.

  • Task, decision, and journal exist as ordinary files under .ostk/.
  • Agent A leaves a specific failing source state and exact next action.
  • Agent B records all four orientation facts before completing the task.
  • The final acceptance condition gates task closure.
DOES NOT ESTABLISH

Universal provider, router, identity, or privacy claims.

  • The checker validates a bounded continuity run. It is not an adversarial identity proof.
  • Journal fields do not independently attest that an external process was a particular named coding agent.
  • The no-transcript condition is enforced by the person running the demo; the checker cannot prove that nothing was pasted.
  • A pass does not establish provider or router failover, fresh-machine restore, projection rebuilds, data-egress policy, or concurrent-edit behavior.
Provider data path

Canonical task, decision, and journal state is stored in the temporary project. That does not make every integration offline: configured providers may receive prompts or context, and anchored Anthropic sessions can use Anthropic Files. Review the integration's data path before using private code.

CLEAN UP

Close the kernel, keep or discard the evidence.

From the temporary demo repository, terminate the running kernel cleanly:

Then delete the printed temporary directory when you no longer need its evidence. Cleanup is intentionally manual; the demo does not remove the repository for you.

AFTER THE FIRST WIN

Choose the next useful boundary.

Activation starts with a user outcome. Component details belong in the docs and “How it works,” once you need them.