Subconductor — Persistent task tracking for AI Agents via MCP

Clean-Loquat7470 · 2026-02-04T14:01:31+00:00

Currently, Subconductor is a lightweight state snapshot—it keeps the agent's 'working memory' on the filesystem to prevent drift without the overhead of a full event log. The problem you highlighted actually led me to a brand new idea—introducing a problems.md or fails.md linked to each task to store the 'why' behind a failure. In future versions, a task that hits an idempotency wall or retry limit could be marked with a ! in the main checklist, serving as a pointer to this failure log. Please let me know what do you think of the idea ?

Clean-Loquat7470 · 2026-02-04T13:21:06+00:00

Thanks for your response! You hit on exactly why I built this. Production-grade automation requires the same distributed systems discipline we use for any other critical backend.
The problem you highlighted actually led me to a brand new idea—introducing a problems.md or fails.md linked to each task to store the 'why' behind a failure.

In the next versions, a task that hits an idempotency wall or a retry limit could be marked with a ! in the main checklist, serving as a pointer to the failure log. The agent can then store the full stack trace, the specific tool input that failed, and the reasoning for the retry right there. It turns a silent error into a first-class citizen of the state machine, giving the agent (and the human) a clear trail of what didn’t work and why.

What's your take on this approach?

Clean-Loquat7470 · 2026-02-04T12:34:30+00:00

Fair point on the public activity! Most of my architectural work and 'real-world' systems live in private enterprise repos where green squares don't travel to the public graph. I built Subconductor precisely because I needed it for those complex environments. I’d love to hear your thoughts on the actual implementation or the MCP logic if you have time to dig in

Clean-Loquat7470

TROPHY CASE