Daniel Arcé

The problem

I was leaning on coding agents more, and the same failure kept showing up. The code could move forward while the state around it stayed fragile.

One session knew the current plan; the next one didn't. Claude Code might hold the right context for a branch, and then I'd want Codex or Cursor for a different pass and have to rebuild the thread by hand. Summaries helped, but a summary is still a summary. It rarely carried the thing I needed later — the review finding I hadn't fixed yet, or the reason behind a decision I'd half-forgotten.

That's a lock-in problem as much as a memory problem. When the useful history lives inside one agent's transcript, the project starts depending on that tool. So I moved the state into the repository.

What it does

Workstate keeps a local SQLite database alongside the project, and agents read and write to it over MCP. It records the work: the active task and branch, the files being touched, decisions and blockers, review findings, and test runs with their commands and exit codes.

The next agent doesn't need a long prompt explaining what happened. It can ask the project instead.

A task can start in Claude Code and continue in Codex, Cursor, Grok, or Copilot against the same record. Claude reaches it through the local plugin surfaces; the other clients pick it up through generated skills, commands, and MCP tools. The workflow belongs to the repo, so it survives whichever chat window you close.

That helps when the tools shift under you, which they do. One agent turns out better at planning, another at implementation. Pricing changes. You hit a context limit at a bad moment. A team might want to keep its Claude installs local instead of routing coordination through a hosted service. Through all of it, the handoff state stays put and stays visible to whatever agent you reach for next.

Enforcement

Saving the notes was easy. The point was making them hard to ignore.

Workstate wraps the workflow in Git hooks. Edits to main are refused outside a small allowlist of files. Branch names have to match a fixed grammar tied to a task reference. A branch can't go review-ready while a finding is still open, and a task can't close until every slice has a recorded decision.

Findings and decisions are anchored to commit SHAs. When an agent claims a finding is fixed, there's a commit to inspect. When a task closes, there's a record of what changed, what passed, and what got accepted as a tradeoff anyway. I wanted less talk about confidence and more evidence I could check later — "this was fixed" should be something you verify against git history.

Building it

This was backend-heavy work, well outside my usual front-end-and-accessibility base: Python packaging, MCP servers, Git hooks, SQLite migrations, installers, release automation. I handled it the way I handle a UI that has to survive an audit: write the spec, split the work, review each slice, keep the evidence.

Agents wrote a large share of the implementation, and I treated that as supervised production rather than delegation. I owned the spec and the architecture, set the acceptance criteria, ran the reviews, and decided when it was done. In the end, Workstate enforces the same process I used to build it.

Where it stands

Workstate shipped in June 2026. A CLI installs it into a Git repository, provisions the local database, registers the MCP servers, and generates the surfaces for each supported agent. It's open source at github.com/darce/workstate.

The line back to my accessibility work is short. A remediation claim has to survive inspection — the keyboard path, the screen reader behavior, the fix, the regression test that proves it stayed fixed. Workstate brings that habit to AI-assisted engineering. The agent moves fast; the project keeps the record.