An agent council

A question one agent answers badly. How a council works — and when you do not need one.

The situation

A question where a single agent gives a plausible but one-sided answer: choosing an architectural approach, weighing the risks of a decision, dissecting an incident. The problem is not that the model is weak but that one pass does not generate objections to itself.

When a council is NOT needed

Starting here, because it is the most common answer.

An ordinary task. If it is clear what to do, a council only adds time and cost.

A question with a known answer. A council does not find facts — it makes positions collide. If the answer is in the documentation, searching is cheaper.

A hurry. A run means several roles, a discussion and a vote. It is noticeably slower than one agent.

No spec. The roles lean on recorded decisions. On an empty project they argue in a vacuum.

A council earns its cost where the price of being wrong exceeds the price of the discussion, and where there is more than one option.

What you do

State the question and the criterion. By what measure one answer is better — otherwise the council converges on a polite compromise.

Approve the decision. The council's output is a proposal, not an order. Dangerous actions pass through your confirmation by construction.

What the agent does

Building happens once; running, as often as you like.

in the agent session, once per project

/harness-blueprint

The skill walks you through a questionnaire and assembles a harness for your project: harness_create, one harness_add_role per role, harness_add_workflow_node and harness_connect_workflow_nodes for the step graph, harness_set_policy for the limits, then harness_validate and harness_publish for a version you can run again and again.

in the agent session, per question

Start harness <name> with this question: what should hold the task queue —
a Postgres table or a dedicated queue. Criterion: time-to-failure when a worker
is lost, and cost of operation.

From there harness_start_run, and the roles work their cycle: work_claim to take a step, council_submit_proposal to propose, council_submit_critique to pull apart someone else's, council_respond_to_critique, council_cast_vote. The moderator folds it into council_submit_judgement — a decision with its grounds.

Each role is a separate agent session running the flownix-harness-participant skill (the moderator runs flownix-harness-moderator). The whole run is visible in the web app.

What comes out

A decision whose origin is visible: which options were considered, what was objected to, why this one was chosen. Plus a draft of tasks, if the decision needs work done.

The run is preserved in full: roles, steps, arguments, votes. A month later you can open it and see what was agreed and on what basis.

Limits

A council does not produce truth. It produces a decision with recorded grounds. Several roles of one model are not several independent experts, and a council will not correct a belief the model holds throughout.

It costs more. Several roles mean several model runs.

It needs tailoring. Default roles do not suit everything; that is exactly why harness-blueprint walks you through an interview.