Agentic Councils: The Missing Governance Layer for High-Stakes AI Decisions

Today we are releasing elder-council-harness, an open-source multi-model deliberation framework for high-stakes AI decisions. This piece explains why we built it and the engineering principles behind it.

In the companion piece to this one, we established the central rule of agentic loop engineering: make the model creative inside the loop, but make the loop's gates deterministic, observable, privilege-bounded, and interruptible.

That rule was framed around a loop that executes actions — tool calls, API requests, state mutations. However, there is a second class of agentic output that the action-governance loop does not adequately address: decisions.

Not tool calls. Decisions. A risk exception approval. A merge gate. An architecture sign-off. A threat assessment that determines whether an IR team gets paged. A supply chain evaluation that decides whether a dependency enters a production codebase.

These are high-stakes outputs from agentic systems, and they share a specific failure mode that action governance does not cure: the absence of independent challenge.

A single model reflection-looping on its own output to assess whether a risk is acceptable is not governance. It is autocracy with extra steps. The same self-preference bias (a model's tendency to favour its own outputs over equivalent alternatives) that makes LLM-as-judge unreliable for verifying action outputs makes it structurally unsuited for making consequential decisions in isolation. Research by Xu et al. (ACL 2024) documents this directly: self-refinement pipelines improve surface fluency whilst amplifying underlying bias. A confident wrong model that critiques its own confidence produces a more confidently wrong result.

Agentic Councils are the architectural answer to this problem. And today, with the first public release of elder-council-harness, there is a working implementation you can inspect, run, and adapt.

What Is an Agentic Council?

An Agentic Council is a structured multi-model deliberation system in which different agent lenses (role-differentiated analytical perspectives) independently analyse the same question, each tasked with challenging rather than agreeing.

This is a specific design choice, and it runs counter to the instinct that better AI decisions require more capable models. A more capable model still reflects one coherent set of priors, one training distribution, one implicit weighting of what matters. The council's value is not superior capability; it is perspective diversity. A strategist and a critic looking at the same architecture proposal will surface different failure modes — not because one is smarter, but because they are looking for different things.

The distinction between a council and a committee is equally important. A committee tends toward consensus; it is socially expensive to dissent, so dissent is suppressed. A council is adversarial by design: the Critic lens exists to find the flaw the Engineer missed, the Strategist exists to ask what the ten-year consequence is before the team is too committed to the six-month win. The council's output is not a unanimous recommendation; it is a weighted deliberation with a confidence score, a dissent record, and an evidence trail.

Research on multi-agent error propagation (From Spark to Fire, 2026) shows that when agents in a network share the same priors, a single false claim can propagate into consensus inertia — widespread agreement on something wrong. The countermeasure is not more agents; it is role-differentiated agents explicitly tasked with disagreement. You do not want five voices saying the same thing. You want five voices trained to notice different failure modes, with a gate that requires a real majority across them.

The Loop Engineering Underneath

Agentic Councils are not a novel concept disconnected from loop engineering. They are a specific application of multi-agent loop architecture to the problem of decision governance.

The council is a loop — one with a specific eight-function structure that maps directly to the canonical loop from Part 1:

• High-Stakes Question Intake — A risk approval, merge gate, architecture decision, or threat assessment enters the system.
• Gate: Scope and Authority — Is this within the council's mandate? Who authorised this question?
• Context Load — Domain knowledge, risk registers, prior decisions, and relevant evidence are assembled.
• Parallel Lens Deliberation — Five lenses analyse independently, blind to each other at this stage.
• Consensus Gate — Weighted position scoring against a numeric threshold. Does a majority agree?
• 11-Gate Policy Layer — Deterministic authority checks before any recommendation issues.
• Signed Recommendation — Confidence score, dissenting views, and evidence links included.
• Hash-Chained Audit — A tamper-evident record of the full deliberation trace.

When consensus is not reached or a gate blocks, the output is human escalation — a dissent summary and evidence forwarded to an authorised reviewer, not a retry loop.

The mapping to the central rule from Part 1 is direct:

• Model creative inside the loop: each lens deliberates freely, generating its own independent analysis without knowledge of what the other lenses have produced.
• Gates deterministic: the consensus gate uses weighted scoring against a numeric threshold; the 11-gate policy layer runs deterministic authority and policy checks — neither step involves a model making a judgement call.
• Observable: every deliberation generates a hash-chained audit record that can be reviewed, challenged, and exported.
• Privilege-bounded: the scope-and-authority gate at intake ensures the council only operates on questions within its mandate.
• Interruptible: when consensus fails or a gate blocks, the output is escalation to a human reviewer, not a retry loop.

The key engineering decision in council design is the same maker-checker principle that governs action loops: the component that generates the analysis (the lens) must not be the component that validates it (the consensus gate and policy layer). Separating these roles is what converts deliberation into governance.

The Five Elder Council Lenses

The Elder Council uses five lens archetypes, each designed to surface a different class of problem. They are intended to be orthogonal — not just different in tone, but structurally focused on different failure modes.

The Strategist

The Strategist looks at long-term consequences, alignment with goals, and opportunity cost. Its signature question is: "What does accepting this decision commit us to that we have not acknowledged?"

The Strategist is not trying to block decisions; it is trying to surface the hidden ten-year trajectory in what looks like a six-month choice. In an architecture review, the Strategist asks what organisational capability gets locked in or lost. In a risk exception, it asks whether the compensating control becomes permanent infrastructure.

The Critic

The Critic is the devil's advocate. Its mandate is to find the flaw, the hidden assumption, the edge case that the team has priced as unlikely and not examined.

The Critic is not contrarian for its own sake; it is structurally tasked with the question the rest of the council would prefer not to ask. In a code review, the Critic reads for race conditions and implicit state assumptions. In a compliance sign-off, it asks whether the control depends on a process that is not yet audited.

The Engineer

The Engineer provides the technical ground truth: feasibility, implementation risk, performance characteristics, and the cost of reversibility. When the Strategist's concern is valid but the Critic's concern requires a different technical framing to be actionable, the Engineer translates.

The Engineer also holds the line on technical debt — a decision that is strategically attractive but technically expensive gets an honest assessment of what that expense actually means.

The Generalist

The Generalist holds the holistic view. Its contribution is cross-domain connection: the policy implication that the specialists missed, the user experience consequence of the technically sound decision, the downstream effect on a team that was not in the room.

The Generalist is the lens most likely to say "this is correct in isolation, but consider the interaction with X."

The Local Oracle

The Local Oracle is the lens of pragmatic simplicity, minimal viable solutions, and privacy-first thinking. It represents the perspective of the practitioner who has to implement and maintain the decision without a team of architects.

If a recommendation requires twelve new dependencies and a custom orchestration layer, the Local Oracle asks whether the same outcome is achievable with three existing tools. It is also the lens most sensitive to surveillance, data residency, and operational overhead.

Running all five lenses against every question is not always appropriate; the Lite profile described below uses three. However, across all five, the council covers the failure modes that any single model — however capable — is unlikely to surface independently: strategic lock-in, hidden assumptions, technical feasibility, systemic effects, and practical overhead.

In Practice: The Seven Councils

The elder-council-harness ships with seven pre-configured councils. Each council selects a subset of the five lenses appropriate to the decision domain, with tuned prompting for the specific question types that domain encounters.

Code Review

This is arguably the most common use case. The Critic reads for the assumption the Engineer normalised because they wrote the surrounding code. The Engineer assesses whether the fix introduces a new surface. The Generalist checks whether the change has documentation and onboarding consequences.

The council's recommendation is not "approve" or "reject" — it is a structured finding with confidence score, specific concerns, and suggested follow-up checks. A senior engineer still makes the merge decision; the council surfaces what they should consider.

Threat Hunting

The council runs before the IR team is assembled. The Local Oracle's first question is always the boring one: is this a VPN user on a new laptop, or is it an attacker? The Critic challenges the attribution before the team commits four hours to an incident that turns out to be a misconfigured monitoring agent. The Engineer checks whether the detection logic could produce false positives at this rate given current infrastructure changes.

The cost of a missed incident is high; the cost of a false-positive IR call is also high. The council's job is to give the analyst a structured second opinion before they decide.

Supply Chain

A dependency evaluation surfaces the acquisition that happened three months ago (Strategist), the licence change in the last major release (Critic), and the transitive dependency that pulls in a package with a known CVE (Engineer). This is information a solo reviewer finds in isolation; the council finds it systematically.

Compliance

The Generalist, Critic, and Strategist combine to catch edge cases in retention and access controls, as well as gaps between documented and operating controls. This council is particularly valuable where regulatory sign-offs depend on evidence that controls function as described, not merely that they exist.

Cyber Risk

Exception approvals and control waivers benefit from the Critic's challenge to compensating controls that may be aspirational, the Strategist's assessment of long-term risk accumulation, and the Engineer's reality check on implementation feasibility.

Platform Architecture

Stack migrations and infrastructure changes are assessed for institutional knowledge loss, migration reversibility, and team capability gaps. The Strategist, Engineer, and Generalist lenses are well-suited to surfacing the organisational consequences that purely technical reviews tend to miss.

Business Decision

The full five-lens council applied to a genuinely ambiguous strategic question. "Should we ship now or harden first?" The Engineer gives the honest cost estimate of hardening. The Strategist asks what a public incident would cost versus the revenue delay. The Critic challenges the assumption that hardening now avoids the incident rather than delaying it. The Local Oracle asks whether the hardening scope is actually the minimum necessary or gold-plating. The Generalist notes the team morale implication of a slip and the customer trust implication of an incident.

None of this produces a decision. All of it informs one.

The Governance Layer: Eleven Gates

What distinguishes a council from an advisory chat is the gate layer. Without deterministic gates, the council is an expensive brainstorming session. With them, it is a governance mechanism.

The elder-council-harness implements eleven gates organised into three deployment profiles:

• Lite (4 gates) — Scope, authority, consensus threshold, and basic audit. Fast latency, suitable for real-time advisory. Designed for teams adopting councils for the first time or lower-stakes advisory use.
• Standard (8 gates) — Adds blast-radius classification, tool-surface check, escalation routing, and tamper-evident audit. Moderate latency, suitable for asynchronous reviews of production security and architecture decisions.
• Regulated (11 gates) — Adds hard-block on policy violations, separation-of-duties (SoD) matrix check, jurisdiction flag, and full audit schema. Slower latency, suitable for async compliance reviews in regulated industries or decisions subject to external audit.

The gate design principle is the same as the action loop: gates must fail closed, not open.

During development, the harness had a real security bug: the gates were failing open on malformed JSON input from a lens — treating a parse failure as a pass rather than a block. This was found in internal testing and fixed before public release. The lesson applies universally: a gate that silently passes on error is not a gate. It is a false sense of control.

Human-in-the-loop in the council context is not a rubber stamp at the end of a deliberation trace. It is a structured escalation path with specific triggers: no consensus reached, a gate blocks, the question is reclassified to a higher blast-radius class during deliberation, or a Critic dissent reaches a severity threshold. The human reviewer receives a compact deliberation summary, the dissent record, the evidence links, and the specific gate or threshold that triggered escalation — not a wall of text from five models.

Introducing elder-council-harness

The elder-council-harness is an open-source multi-model deliberation framework for high-stakes AI decisions. It ships today.

I built it because the elder-mind-harness — which governs actions that agentic systems can take — left a specific gap. It answers "what may this agent do?" It does not answer "what does this decision cost, what does it commit us to, and what did we miss?" Those are different questions. They need a different mechanism.

What Is Inside the Harness

• 7 pre-built council configurations covering code review, threat hunting, supply chain, compliance, cyber risk, platform architecture, and general business decisions
• 5 IDE integrations — Claude Code, OpenCode, Kiro, Cursor, and GitHub Copilot — so the council runs where you already work
• 3 deployment profiles (Lite, Standard, Regulated) matched to governance requirements
• 11 deterministic gates with fail-closed defaults
• 123 tests — unit, integration, honesty checks, and agentic UAT across platforms
• BYO-LLM design — the harness ships no API keys and makes no cloud calls without your configuration. You bring your models; the harness brings the structure
• Hash-chained tamper-evident audit — every deliberation produces a chain-linked record that can be verified for integrity
• Cross-platform CLI — pip install eldercouncil, then eldercouncil convene --council code-review --question "..." to begin

The Companion Relationship

The elder-mind-harness governs actions. The elder-council-harness governs decisions. Used together, they cover both surfaces of agentic governance: the tool-call layer and the deliberation layer. Neither is sufficient alone.

What It Is Honest About

The harness is "aware and aligned" with governance standards — it is not self-certified as "compliant" or "certified." Compliance with specific regulatory frameworks (POPIA, ISO 27001, SOC 2) requires a human compliance process; the harness makes that process evidence-richer and decision traces auditable, but it is not a substitute for a qualified assessor.

Getting Started

The START-HERE.md in the repository walks through a first council run in approximately fifteen minutes. The Lite profile with the business-decision council and three lenses is the recommended entry point. It produces a fast, structured deliberation without the latency of a full five-lens Standard run.

pip install eldercouncil
eldercouncil init
eldercouncil convene --council business-decision --profile lite --question "Should we migrate our auth stack to the new provider before Q3 launch?"

The Governance Question

The governance question that council design introduces is simple enough to use as a filter for any high-stakes decision:

Does this decision benefit from independent challenge before we commit to it?

If the answer is yes — if getting it wrong would be expensive, difficult to reverse, or consequential to people beyond the decision-maker — then a council is a proportionate response. It is not bureaucratic overhead. It is structured, time-bounded, evidence-linked deliberation that takes minutes longer than a solo model call and produces a decision trace you can stand behind.

If the answer is no — if this is a low-stakes, easily reversible choice — then the Lite profile or no council at all is the right call. The harness is not designed to make every decision an event; it is designed to make the decisions that matter harder to get wrong.

As discussed earlier, the loop engineering principles from Part 1 apply here at the deliberation level:

• Know what you know — load relevant context before lenses begin, not during.
• Know what you may decide — the scope-and-authority gate at intake defines the mandate.
• Know how you will verify the output — the consensus gate and policy layer are not optional.
• Know who is accountable — the escalation path ensures a human remains in the loop when the council cannot reach a clean recommendation.

The harness operationalises all four. The architecture is documented, the tests are public, the gate logic is inspectable, and the audit trail is tamper-evident.

Start with a question your team argued about last week. Run it through the Lite council. See what the five lenses surface that the original argument did not. Then decide whether it belongs in your workflow.

Sources

• elder-council-harness on GitHub
• elder-mind-harness on GitHub — action governance companion
• Xu et al., ACL 2024 — Self-preference bias in LLM self-refinement
• From Spark to Fire (2026) — Multi-agent error propagation research