Feature Request: Customizable work item types or containers assigned to specific workflows via the vector DB
Love archon!
I was trying to make something like it on my own, but this is so much better.
One thing that could be useful is to give the user customizable Containers (Module / System / Epic / Feature / etc...) with rules for what work item types can be inside them. Then custom work item types (Build, Test, Integrate, Bug, etc...). Also with assignable workflows. The requirement for knowledge, RAG, all archon features could be assigned at either the work item, container, or
A big issue I'm noticing is that no matter the tool / OS / MCP server, nearly every coding assistant fails badly at relating the tasks to one another, or a wider set of tasks, or stop paying attention to the order of those tasks after starting. They will race down the rabbit hole on a single task to show the user how completeness-oriented they can be. Short of retraining our own models, it's something that 90% of people have to build around at the tool or MCP level, like what Archon offers.
Hooks could work for claude code based on an MCP pre-tool or postooluse matcher on something like advance_workitem_step, (if there were work item types that had steps or subtasks, or if those work item types had specific workflows assigned to them, configurable by the user in the UI). It could then force claude to have all fields filled, or to go through certain workflows. The vector DB could be used to track or enhance these relationships by container or temporally, or by code dependency.
That was the system I was building, but it's nowhere near the capabilities and functionality of Archon. I do still notice though that claude will get confused and forget the right workflow, even with an archon task that comes from a very well designed / decomposed PRP.
Love this new Archon though, a truly masterful creation
Thanks for sharing the detailed request — it highlights a real gap. From your description, the failure mode sounds closest to Problem #6: Logic Collapse & Recovery — tasks and workflows drift into dead-ends or lose ordering, and without auto-reset / continuity logic the assistant can’t recover the intended flow.
Over the past 60 days, we’ve had 600+ stars on the Problem Map cataloging real-world LLM/RAG failure patterns, and this kind of workflow/logic drift is one of the most recurrent. One effective mitigation we’ve seen is a Semantic Firewall pattern — a lightweight guard that intercepts or reshapes state transitions, so that even if the model “forgets” workflow order, the system prevents collapse into the wrong branch.
If you’d like, I can share a checklist of failure points (used to systematically debug and patch similar continuity problems). It might help evaluate whether your request should focus on container design, workflow assignment, or enforcing stronger guardrails at runtime.
Yes I would love to know how to solve that. Just to be clear, do you mean that Archon has that mitigation strategy already? I can't seem to get 100% (or even 50%) compliance with Claude code to use Archon or any other MCP tool. Even with the archon-provided claude.md, claude will veer off course. In my own tools, I have been experimenting with a series of pretool and post-tool hooks that will call the MCP tool via a python script and then return context injection about the task at hand while also blocking claude from using any other tool. I haven't got the tool ordering and scope right for that to work perfectly. Another solution is that I've used a treesitter implementation and a discovery service that runs in the background to stuff the entire codebase into a neo4j knowledge graph. I'm trying to get semantic context to auto-return to claude whenever it uses a tool or enters the workflow tool. This may need a longer conversation :) The primary problem may be that claude code's system prompt pre-defines too many behaviours that we don't want in enterprise grade agentic development. I might have to swap out claude code and build my own base coding agent without the unintended behaviours of claude code. Something like archon makes that possible now.
Exactly! What my "solution" was is very similar..even with hooks in.place, the agent is so he'll bent on ticking the "look I did this for you" box, they ignore everything including actually implementing the task in some cases. My approach was to break apart the "user story" (the thing we want it to do, but apply several steps to it). If you are just feeding it a prompt, the pieces are:
- Analyze the task
- Document the implementation plan
- Write the tests (Red phase)
- Write the code
- Document what you wrote
- Test (Green phase)
- Loops through 4-6 until green passes
- Mark ready for UAT in the implementation plan
The agents routinely would:
- Write 2 to the console and not write it to a file, or sometimes.not even use TodoWrite
- Skips straight to 4 then would Skips everything else and got straight to "done" or strhggt to "UAT"
- When they did write tests, the would write green tests that returned false, and the red tests would just check if the api or fiction in code existed, returning 400 or 500 was treated as "passing"
- Documention was always created in some random file with a random name, and not linked to anything. "Updating" documentation was frequently a new file, again incomplete and not linked to anything. Even when I gave the agent direct naming conventions on the blocking hook feedback, it would get blocked once or twice more for not following specific instructions and mark the task completed anyway, without creating any persistent docs!
Actually - I solved about 80% of the problem with a simple hook in claude code. It's a pretooluse hook matched to the todowrite that blocks the action and tells claude "use X system or Y tool only". With the frequency claude tries to use todowrite, this really helps.
@coleam00 perhaps this would be useful to examine for Archon. I added it to my local suite of tools, which call archon now, and I'm getting near 95% compliance with getting claude to use my coordinated set of tools. Also works for any other MCP tool for PM services to swap out the todowrite. code looks like this (replace with whatever tool you actually need - I'm routing through another tool selection intermediation tool I call "clauderails" that then makes it use Archon and a few other things.
#!/usr/bin/env python3 """ PreToolUse hook to block TodoWrite and enforce ClaudeRails usage. Exit code 2 blocks the tool call, 0 allows it. """ import sys import json
def main(): try: # Read tool call data from stdin data = json.load(sys.stdin) tool_name = data.get("tool_name", "")
if tool_name == "TodoWrite":
# Block TodoWrite and provide guidance
print(
"❌ BLOCKED: TodoWrite is not permitted!\n"
"You MUST use ClaudeRails for task management:\n"
"• List tasks: mcp__clauderails__workitem action=list filters={\"status\":\"in_progress\"}\n"
"• Create task: mcp__clauderails__workitem action=create type=<plan|implement|issue>\n"
"• Update task: mcp__clauderails__workitem action=update id=<task_id> updates={...}\n",
file=sys.stderr
)
sys.exit(2) # Block the tool call
# Allow all other tools
sys.exit(0)
except Exception as e:
print(f"Hook error: {e}", file=sys.stderr)
sys.exit(0) # Don't block on errors
if name == "main": main()
@ALeslie743
Great follow-up — yes, the mitigation strategy I mentioned is not natively built into Archon or most agent frameworks. What actually works in practice is adding a “semantic firewall” layer, which sits between task transitions and the LLM/agent core, reshaping or intercepting the state flow so the assistant can’t lose track of context or fall into logic drift.
This exact solution (and 15 other high-frequency failure modes) is documented in the Problem Map here: https://github.com/onestardao/WFGY/blob/main/ProblemMap/README.md
If you skim the entries for No.6 (Logic Collapse & Recovery) and No.12 (Philosophical Recursion) you’ll see patterns very similar to your Claude/MC integration challenge. The semantic firewall approach is modular, MIT licensed, and works alongside container-based or Python agent orchestration. If you’d like, I can send example implementation snippets for your workflow. Just let me know!
@ALeslie743 I love this setup a lot, I would be down to include setup instructions for this in Claude Code in the Archon repo somehow! Honestly if you want to make a PR for this (including documentation around this where you think it fits) I would love to bring this in!
Moving this to discussions section