Skip to main content

Orchestrating agents: Hunter, its sub-agents, and the roles they play

An always-on agent on its own server takes anything I send, hands it to the one skill that owns that kind of thing, passes long work to sub-agents so it stays reachable, and only interrupts me for real decisions.

I treat the agent like a new chief of staff, not a tool. It gets a clear job, a map of who owns what, written rules for what it may do alone, and a way to ask me that respects my time. Most of my work on it is the writing, and almost every rule carries the date and my own words from the moment it was needed.

I don't try to get the model to be careful. I give it a world where the careful thing is the obvious thing: one door per action, exit codes it can branch on, and a record of every time a rule was wrong.

I design the org chart and the handoffs, not just the prompts.

  • Route first. Anything I send, the agent works out what kind of thing it is and hands it to the skill that owns it. Going around the owner is how things land half-saved.
  • Hand off long work and stay reachable. Anything bigger than a quick look goes to a sub-agent with a brief, and the main agent ends its turn, because while its turn is open my messages wait.
  • The brief is the contract. A build starts from a brief I approved, bound by its hash. Edit the brief and it's a new approval. The builder can't widen its own job.
  • Nobody grades their own work. Builder, tester and reviewer are separate sessions. The tester sees only the ticket and the live system, never the builder's transcript. A failed check goes back to the builder for a bounded retry loop, and only the orchestrator marks a ticket done.
  • Can, but may not. The agent's login could merge and deploy. The rule says it may not without my yes, and a tool enforces the rule, not the token.
  • Isolation matches blast radius. Everyday changes get fast throwaway worktrees. Builds of the app that holds my memory get a locked folder, no network but the package registry, and hard caps on runtime and spend.
  • Every kind of request has one skill that owns it from start to finish.
  • Sub-agents run the long work in separate sessions since Oct 2026 so the main agent stays reachable.
  • Pull requests merge across my active repos through the same review and approval flow since Oct 2026.
  • Most commits on main across those repos are written by the agent and reviewed before they land.
  • Locked builds of my own app run in an isolated sandbox, and the pipeline refuses any go-live attempt that fails its checks.
  • The background sweep runs in plain code and spends no model tokens when the queue is quiet.