The akiflow Activation Gate: When to Open an AI Agent Council
The three-condition activation gate in akiflow decides whether a task deserves an agent council, along with the three modes (discuss, audit, execute) and the two shapes (council, dispatch).
One of the costliest mistakes in a multi-agent system is convening a whole council for work that is too simple or not yet decomposed. Opening a room with many agents around a vague question wastes tokens and adds context noise that lowers the quality of the final decision.
The akiflow skill says so itself: if none of the structural failures of a single thread is present (context flooding, role collapse, self-approval), the skill costs more than it returns.
What are the three conditions of the activation gate?
A council may open only when the problem passes all three conditions:
Condition 1, decomposable: the request splits into at least two work items with real boundaries that can be verified independently. An uncuttable problem gains only noise from extra agents.
Condition 2, multiple standards of "correct": at least two items are judged by different standards (schema-correct differs from UX-correct differs from price-correct). If one standard covers everything, one good head suffices, and extra heads only manufacture agreement.
Condition 3, cost of error exceeds cost of coordination: the consequence of getting it wrong (a broken DB, a damaged user experience, a security hole) is well above the tokens and time spent coordinating.
When in doubt, the decision goes toward not opening a council. The gate is also auditable: the lead must declare the mode and the trigger reason in its opening output, and never asks the user which "tier" they want.
Before the gate: is there anything to arbitrate?
The first question is the shape of the work. If two equally competent seats could reach two different defensible answers, it is a council, and the three-condition gate above applies. If the answer is knowable and the work is merely large (a repo-wide sweep, a bulk migration), it is a dispatch.
A dispatch splits the work into lanes, each with an exclusive set of files it may write, instead of items with an adversary. The dispatch gate: partitionable into at least two independent lanes, each lane's paths and question nameable up front, and a result that must outlive the session. Fail the last one and a bare spawn suffices. council_open.py --convene also checks something a council never needed to: that no path appears in two lanes' writes:, because two workers editing one file is a failure no amount of judgment prevents.
Three modes replace the Tier levels
akiflow used to assign Tier 0, 1, or 2. That was replaced: the tier number only counted kinds of "correct", which is condition 2 restated, and it also produced rosters derived from a classification instead of from a requirement. The current mode answers a question with a mechanical answer: what changes outside the room?
discuss: nothing changes, and the output is a decision and its record, with no aki-maker needed. audit: nothing changes, read-only under agent.B5, producing findings with severity plus a plan that schedules the fixes; fixing is a separate run. execute: files change, the output is a verified diff, and aki-maker is the only seat allowed to write.
Step 0: anchor the owner's words and cut the work before opening a room
Even after passing the gate, the lead may not spawn agents right away. The first step is council_open.py <slug> "<the owner's message verbatim>", which pins the message verbatim as an immutable ## anchor block in chat.md and refuses to open a room without it. The request is then split into REQ-1…n lines, each quoting a fragment of the anchor, and cut into work items:
ITEM <id> · <what must be decided or built>
covers: <REQ-n, REQ-m>
owner: <specialist seat>
challenger: <a different seat>
closes when: <a criterion someone else can check>
rationale: <filled in at closure, <=3 lines>Every REQ must be covered by at least one item, because an orphan REQ is a decomposition bug. council_open.py --convene refuses to convene until at least one item has an owner, a challenger, and a closing criterion. The checklist is a precondition for opening the room, never a product of it.
Summary: controlling token cost in a multi-agent system
The strength of an agent system is not how many agents it calls but the discipline of its coordination and the boundaries of its authority. The three-condition gate, the choice of shape and mode, and the pinning and cutting done before a room opens keep every seat justified and every requirement from the owner covered.