I saw the HN launch note frame the failure mode as process drift + context management. That seems right.
One adjacent edge case: the FSM can enforce the workflow path, but the run still depends on a mutable instruction/capability surface outside the FSM:
AGENTS.md / repo instructions- installed skills
- MCP server config/tool catalogs
- permission settings / approval policy
- maybe the selected workflow package version itself
If those change between planning and execution, or between two runs of the same FSM, the state history can say the right gates were followed while the agent was effectively operating under a different instruction surface.
A small v1 could be a context preflight receipt recorded at run start, without storing raw prompt text:
{
"context_preflight": {
"captured_at": "...",
"repo": { "branch": "main", "commit": "abc123", "dirty": true },
"instructions": [
{ "path": "AGENTS.md", "sha256": "...", "bytes": 1234, "status": "captured" },
{ "path": "CLAUDE.md", "status": "missing" }
],
"skills": [
{ "name": "aharness-fsm-authoring", "source": "Alfredvc/aharness", "sha256": "..." }
],
"mcp": [
{ "server": "github", "configured": true, "tool_catalog_fingerprint": "..." }
],
"privacy": {
"raw_instruction_text_included": false,
"raw_prompts_included": false
}
}
}Why this might fit aharness specifically:
- it gives run history enough evidence to answer "did the process fail, or did the instructions/capabilities change?"
- it makes reusable FSM packages easier to debug across repos
- it keeps the runtime boundary distinct from prompts/skills: prompts describe behavior, FSM enforces transitions, preflight records which instruction/capability surface was present
- it avoids becoming a prompt recorder
The smallest useful version may just hash a known-file list plus workflow package identity, then add MCP/catalog fingerprints later.
I saw the HN launch note frame the failure mode as process drift + context management. That seems right.
One adjacent edge case: the FSM can enforce the workflow path, but the run still depends on a mutable instruction/capability surface outside the FSM:
AGENTS.md/ repo instructionsIf those change between planning and execution, or between two runs of the same FSM, the state history can say the right gates were followed while the agent was effectively operating under a different instruction surface.
A small v1 could be a context preflight receipt recorded at run start, without storing raw prompt text:
{ "context_preflight": { "captured_at": "...", "repo": { "branch": "main", "commit": "abc123", "dirty": true }, "instructions": [ { "path": "AGENTS.md", "sha256": "...", "bytes": 1234, "status": "captured" }, { "path": "CLAUDE.md", "status": "missing" } ], "skills": [ { "name": "aharness-fsm-authoring", "source": "Alfredvc/aharness", "sha256": "..." } ], "mcp": [ { "server": "github", "configured": true, "tool_catalog_fingerprint": "..." } ], "privacy": { "raw_instruction_text_included": false, "raw_prompts_included": false } } }Why this might fit aharness specifically:
The smallest useful version may just hash a known-file list plus workflow package identity, then add MCP/catalog fingerprints later.