Feature Lists as a Gate, Not a Memo
Explore how feature lists function as gates to control AI agent state changes, preventing invalid transitions and ensuring task dependencies and evidence are properly managed. Learn to design a transition policy that governs feature progress, supports audit logging, and maintains reliability across sessions in AI harnesses.
We'll cover the following...
- Why didn’t the feature list prevent the subpar handoff?
- What should one feature row contain?
- Which transitions should the harness allow?
- Who is allowed to change each field?
- What stops the agent from deleting a difficult row?
- How does the gate choose the next feature?
- Can the agent mark a feature blocked to escape it?
- What does the transition policy look like while it is running?
- What can you add to your harness?
- How do you test the gate itself?
- What’s next?
Wrenfold’s agent ended its CLIN-511 session with a cheerful progress update: “Atomic rebooking complete. Next: provider time off.”
The route existed, the transaction helper existed, and all 14 unit tests passed. The end-to-end rebook test still failed because a rejected replacement released the original appointment. In feature_list.json, the agent had changed "state": "active" to "state": "passing" anyway.
The next session trusted the file and activated CLIN-530. Wrenfold now had one feature labeled complete, one feature under construction, and no session assigned to the booking defect both depended on.
The list remembered what the agent wrote. It did not control what the agent could claim.
Why didn’t the feature list prevent the subpar handoff?
A memo records state. A gate determines whether a state transition is allowed.
Wrenfold used a structured memo. Each row recorded a ticket, expected behavior, verification command, and state, but every field remained editable by the agent. As a result, the memo could not prevent the agent from:
Activating a second feature while another was still in progress.
Marking a feature as passing without running the required check.
Changing the criteria it was supposed to satisfy.
That difference belongs on the reliability side of the course’s line. The model can understand a workflow and still take an invalid shortcut. The harness must own the transition that matters. feature_list.json is a Carry artifact; this lesson wraps it in Power, so the agent may propose a state without being able to write one.
Anthropic used a JSON feature list in its long-running agent harness. Features began as failing; later sessions chose one unfinished feature, and agents were told to mark a feature passing only after testing it.
That gives us a useful artifact. A production harness needs one more step: encode those instructions as a ...