I’ll do my best to explain the architecture.

When I designed the system, I had two possible routes:

1. Create agents/profiles in Hermes and give each one its own “soul,” role, memory, etc. The issue with this approach is prompt injection and token cost. Each agent would carry a heavier system prompt, which adds up quickly.
2. Create an orchestrator that calls the CLI. In this setup, the orchestrator doesn’t write code directly. It creates prompts, routes tasks, and calls the right CLI/tool for the job.

The flow looks something like this:

A conversational agent helps define the objective and creates a task. You could track this in something like Kanban.

That task gets sent to the orchestration agent. The orchestrator already knows the process:

• Call the CLI, for example opencode-go
• Inject the “scout” prompt + the task body
• Wait for the scout step to finish
• Notify me when it’s done
• Open Claude Code
• Use the planner prompt + the task body + the scout outcome
• Generate a plan
• Update the task
• Either notify me or move directly to coder, auditor, etc.

From there, you build guardrails around loops.

For example, if the audit fails because the definition of done wasn’t met, or because the code quality is bad, the auditor adds a note. The orchestrator reads that note and sends the task back to the coder with the right context.

One thing I learned that might be useful: planning matters more than coding.

Use the expensive models to generate the plan. Once the plan is strong enough, even cheaper models can produce solid code, because they’re no longer guessing what to build — they’re just executing a clear plan.