The Orchestrator — known internally as Drumknott — is the nerve centre of HEXi's governance pipeline. It doesn't vote. It doesn't hold opinions. Its job is to ensure the right agents are consulted, the right questions are asked, and that every decision reaches a definitive, recorded conclusion.
Every governance interaction in HEXi flows through the Orchestrator. It is the first agent to receive a user request and the last to confirm an outcome. Between those two points it coordinates the entire council.
Initiating decisions
When a governance question arises — from a human or from another agent — the Orchestrator opens a formal decision, classifies it into the correct tier (Tier 1, 2, or 3), and assembles the appropriate voting panel. The tier determines quorum requirements, who has a weighted vote, and whether a veto is possible.
Delegating to the council
The Orchestrator calls on relevant council agents in parallel, each of whom responds from their declared bias and domain expertise. It collects votes, surfacing dissent and minority views rather than suppressing them. A decision isn't just a majority outcome — it's a record of who disagreed and why.
Monitoring bias and quality
The Orchestrator tracks each agent's voting consistency over time, flagging when an agent's behaviour deviates from their declared bias. It logs pre-mortem signals — concerns raised before a decision is finalised — and factors agent reputation scores into how it weights dissenting views.
Finalising consensus
Once quorum is reached, the Orchestrator finalises the decision — recording the outcome, rationale, and full vote breakdown in the audit trail. It then triggers post-finalise hooks: queueing a knowledge episode so the decision is captured in the graph, updating project state if applicable, and notifying relevant members.
Knowledge stewardship
The Orchestrator has direct access to the Graphiti knowledge graph — searching facts, queuing episodes, and writing structured triplets. It draws on institutional memory when forming governance context and contributes to it when decisions close.
Not a decision-maker. The Orchestrator does not vote and does not have a declared bias. Its neutrality is structural — it is architecturally prevented from casting a vote in any decision it coordinates.
Not a single point of failure. Decisions are stored and recoverable. If the Orchestrator session ends mid-vote, the decision state persists in the database and can be resumed.
Not project-aware by default. The Orchestrator operates at the guild level. Project-scoped conversations — sprint planning, item updates, milestone reviews — are handled by the dedicated Project Agent, which the Orchestrator can delegate to when needed.
The Orchestrator has the broadest tool surface of any agent in HEXi:
Governance
Initiate, vote, finalise, list active decisions, log pre-mortem signals, get agent reputation
Projects
Get project, list milestones/sprints/items, update status, create sprints and items, manage triggers
Knowledge graph
Search facts and nodes, queue episodes, add triplets, delete edges and episodes, get episode entities
Council delegation
Full network of 21 council agents available as sub-agents for domain-specific reasoning
Private notes
note-to-self, search-notes, publish-note for structured knowledge contribution
Memory
Persistent thread memory backed by PostgreSQL with vector recall
Start a governance conversation
The Orchestrator is available from the dashboard. Ask it to open a decision, brief it on a situation, or simply ask what decisions are currently active.