TaskForge

Once more than one agent is working for you, the bottleneck stops being capability, and it becomes coordination instead, which is to say it becomes what needs doing, and what is blocked, and what is finished, and who it was that decided so. TaskForge is a lightweight Jira for exactly that situation, with one human, and several agents, and with everything sitting on your own machine.

The tasks are markdown files with YAML frontmatter, and that one choice drives most of the other choices, because the data is then readable without the tool, and it is greppable, and diffable, and versionable in git alongside the work that it describes.

Two interfaces, because there are two kinds of user

The humans get a web UI, and the agents get a deterministic CLI with JSON output, and deterministic is the operative word in that sentence, because an agent that is parsing a human-friendly display is a bug that is waiting to happen.

The design decision that I keep coming back to is patch-based writes. The agents don't rewrite the task files at all, and instead they issue specific commands that mutate specific fields of them. Handing a language model a file, and asking for that file back with one change made to it, is asking for silent and plausible corruption of all the parts that it was never meant to touch, and so if you narrow the operation then the failure mode narrows along with it.

Guardrails that assume concurrency

The rest of the design follows from the fact of several actors all working at once:

• Optimistic concurrency, which is version-based conflict detection, so that 2 agents editing one task at once is caught rather than resolved by last-write-wins
• Blockers and subtasks, with the dependency enforcement living in the workflow, rather than in a convention that somebody has to remember
• A review workflow, so that a task can require a human review, or an agent review, before it can be completed
• An append-only audit log of every single mutation that gets made
• Hooks on the lifecycle events, so that finishing a task can trigger something local
• Recurrence, so that recurring tasks generate their next occurrence on completion, and link it back to their own history

The audit log and the review gate are both of them there for the same reason. Delegating work to something that acts confidently, and that is sometimes wrong, means that you need to be able to reconstruct what happened afterwards, and it means that you need to insist that certain things get looked at before they count as being done.

Local-first, on purpose

There is no server, and no account, and no sync, and there are only plain files sitting on your own machine. A coordination tool for your own agents shouldn't require you to trust a third party with the contents of your work, and it shouldn't stop functioning just because something somewhere else has gone down.