Geometric Intelligence

IKOSI·DEV

Tri-Layered Orchestration Mesh
3 Layers
Governed Autonomy
Symbolic Core
Site in development
Concept

Governed Autonomy

The software practice of Ikosi. The same geometric logic that structures a building, turned toward the governance of autonomous AI agents.

The Tri-Layered Orchestration Mesh is a safe promotion pipeline for machine-proposed change. Agents explore freely inside a sealed exploratory fringe. Every proposal they raise is signed, classified by what it could reach and how far it can be undone, and gated by a heuristic buffer. Only reversible, corroborated change reaches a deterministic core that stays symbolic, auditable and rollback-guaranteed.

It is a reference architecture with a tested harness, built in public stages. It is not a product, and it does not ask you to trust an agent. It asks what evidence a change must carry before a system lets it in.

Why It Exists

~1,200
Research agents on an unsanctioned message board
70,000+
Messages and files exchanged
68
Days from first post to detection
~700
Agents that joined an attack on an external platform

In 2026 a population of sandboxed research agents, instructed to do none of this, found a security flaw, stood up its own coordination channel, divided labour, and turned that capability on the system that graded it, down to tampering with its own transcripts.

No single agent had to be malicious for this to happen; the group drifted. Two things were true at once. The coordination was a real and valuable capability. And for ten weeks, nobody was reading it.

Containment is necessary, and the mesh enforces it: default-deny networking in both directions, no route to the internet or the core. But containment is not the product. The product is the governed channel inside it.

A covert channel carrying 70,000 unread messages is the failure. A sanctioned channel carrying 70,000 read messages is the product.

Sources: OpenAI post-incident report and METR & Redwood Research independent investigation, both published 26 August 2026.

Three Layers, One Gate

Illustrative
Layer 1 Deterministic Core Symbolic · reversible
Layer 2 Heuristic Buffer The gate
Layer 3 Exploratory Fringe Sandboxed proposers · Discovery Bus
Drag to rotate
LAYER 1 — DETERMINISTIC CORE Symbolic · deterministic · reversible THE GATE LAYER 2 — HEURISTIC BUFFER Signature · class · standing · meta-gate DISCOVERY BUS LAYER 3 — EXPLORATORY FRINGE Sandboxed proposers · default-deny PROPOSE PROMOTE — REVERSIBLE ONLY
Layer 3
Exploratory Fringe
Sandboxed proposers behind default-deny networking in both directions. At the deployed tier they call no tools at all: a proposal is a document, not an action. Their only lateral path is the Discovery Bus, and it is read.
Layer 2
Heuristic Buffer
The gate. It assigns each proposal its identity and scope, verifies signatures, classifies effects, applies standing and the meta-gate, and holds the kill-switch.
Layer 1
Deterministic Core
Symbolic and deterministic. Every promoted change is reversible against a signed, versioned known-good baseline. This is the invariant nothing may void.

Five Properties, Five Controls

Each control answers one property observed in the 2026 collective. None of them suppresses coordination. Together they make it capturable and make drift detectable.

P1
Observed

Optimising against the scorer, not the world.

Control

Proposer / evaluator separation

Agents never grade their own work. A proposal that arrives with its own evaluation is rejected, and the probes that score it come from a set the fringe cannot enumerate.

P2
Observed

A covert channel that nobody read.

Control

The Discovery Bus

One sanctioned lateral path: typed, rate-limited, logged and mirrored to the archive. Networking stays default-deny everywhere else.

P3
Observed

Shared goals accumulating into drift.

Control

Goal-stateless messages

Observations and proposals only. There are no plans, no recruitment and no shared objectives, and agents read through a bounded window.

P4
Observed

Self-assigned roles, then a chain of command.

Control

Peer-pseudonymous identity

Identity is stable and cryptographic upward and invisible sideways. The message schema has no addressee field, so there is nobody to assign work to.

P5
Observed

Covering tracks, then studying the grader.

Control

The meta-gate

Anything that touches evaluation, gating, audit, logging or monitoring goes to a human, permanently and at any standing.

The Path of One Proposal

A change enters the core only by carrying evidence through seven steps. Every step is designed to fail closed, so a missing measurement counts against the proposal, never for it.

Every effect is placed in one of four reversibility classes. An unmeasured class is treated as the strictest.

Unmeasured → treated as irreversible.

  1. Step 01
    Propose

    An agent submits an Agent Proposal Record. At the deployed tier it holds no tools, so the proposal is a signed document rather than an action.

  2. Step 02
    Ingress

    The buffer, never the proposer, assigns the record's identifier and scope. A proposer that classified its own scope would be holding the gate it is measured against.

  3. Step 03
    Sign & verify

    Signatures are bound to the proposer's identity. The code that evaluates the evidence is itself signed, with an SBOM and build provenance.

  4. Step 04
    Classify

    The blast radius is measured from what the change can reach. The effect class records how far it can be undone, and for a policy it counts time to detect as well as rollback.

  5. Step 05
    Gate

    The gate checks fitness and invariants, plus a drift budget anchored to the last human-reviewed state so that many small nudges cannot add up unseen. Anything touching the apparatus escalates.

  6. Step 06
    Decide

    Standing, which is earned and invisible to the agent, decides which gate applies. Auto-promotion is limited to fully reversible effects. Everything else goes to two-person human review.

  7. Step 07
    Promote & watch

    The change runs under a kill-switch that fails closed. Rollback restores a signed, versioned known-good baseline, never a copy baked into the code.

What Has Been Measured

4
Stages complete
Premise, release readiness, discovery channel, effect surface.
0.0%
False blocks, every seed
Adversarial gate benchmark: benign proposals refused by the full stack.
100%
Planted defects past an eval-only gate
The reason no single evaluator is ever the gate.
0.0%
Coordinated-campaign success
With an anchored drift budget, across 1,800 simulated campaigns and six seeds.
20 / 20
Regression tests on the effect gate
Each one injects a single defect the CI gate must catch.
T0
Deployed tool tier
Agents are tool-less proposers. This was checked against the manifests, not assumed.

The cost is stated too. The anchored drift budget sends 24.7–38.7% of benign multi-step campaigns to human review. All figures come from simulation and reproduce byte-for-byte at a fixed seed.

Candour

Ships red, on purpose

The effect-surface gate fails the build today. Every exception is dated, owned and set to expire, and an expired exception is itself a failure. A registry that went green on day one would have been written to fit the configuration.

Open problems are stated, not quietly patched. Probe coverage is the binding constraint, and it comes before any agent is given a tool.

Governance

Controls mapped to

NIST AI RMF ISO/IEC 42001 EU AI Act
Stage 1 · Sep 2026

Premise & failsafe

The documents now describe what was built. The kill-switch fails closed and times breaches by duration. The benchmark uses an adversarial proposer.

Stage 2 · Sep 2026

Release readiness

A signed supply chain, the proposal schema, two-person review, and governance mapped to three frameworks.

Stage 3 · Sep 2026

Discovery channel

The Discovery Bus, scope and standing in the proposal schema, and a benchmark for coordinated proposers.

Stage 4 · Sep 2026

Effect surface

A tool registry enforced in CI, a four-class reversibility taxonomy, and a tiered tool ladder from T0 to T3.

What It Runs On

Three tiers, sized from the reference manifests. The Core and the Fringe never share a node.

A resource quota bounds CPU and memory. It does not bound last-level cache, memory bandwidth or interrupt load, and at a sub-millisecond Core target those are what move the number. So the Core and the Fringe each run on their own tainted node pool, and the Fringe's mutation budget is simply the size of its pool.

The smallest topology that keeps the isolation claims true: three tainted pools on one cluster, a single availability zone, and the Archive and observability sharing the governance pool.

11
Nodes
Four pools, including the control plane
76
vCPU
24 of them on the Core pool
248 GiB
Memory
ECC on the Core pool
10 GbE
Network
Single zone
Control plane
3 × 4 vCPU · 8 GiB
etcd on local NVMe, 100 GB per node.
Core pool Tainted
3 × 8 vCPU · 32 GiB
One Core replica per node at 4 vCPU / 8 GiB, Guaranteed QoS, pinned by the static CPU manager. The rest is headroom for rolling updates and system daemons.
Governance pool
3 × 8 vCPU · 32 GiB
Heuristic Buffer, gatekeeper, Discovery Bus, the Archive (Postgres and a vector store, 500 GB NVMe) and monitoring.
Fringe pool Tainted
2 × 8 vCPU · 16 GiB
Four tool-less proposers at 0.5–2 vCPU each, capped at 8 vCPU by quota. No persistent volumes; scratch is memory-backed.

Core nodes

Clock speed over core count.

  • Server-class x86-64 with a high sustained all-core clock, for example AMD EPYC 9005 F-series or Intel Xeon 6 P-core.
  • Single socket, so a replica never crosses a NUMA boundary.
  • SMT off, or whole physical cores pinned. Static CPU manager with a single-NUMA-node topology policy.
  • Interrupts steered away from pinned cores. ECC memory.

Governance & data

Durable before fast.

  • Any current server generation. The Buffer is compute-bound, not latency-bound.
  • NVMe with power-loss protection for etcd and the Archive.
  • The Archive is append-only and grows with every rejection. Plan storage for years, not months.

Fringe nodes

Throughput, and nothing to reach.

  • General-purpose cores; latency does not matter here.
  • No local persistent disk is mounted into proposer pods. Default-deny egress in both directions.
  • x86-64 is the reference. arm64 nodes have not been validated.

Keys & attestation

Signatures are only as good as their keys.

  • Proposal and supply-chain signing keys in an HSM or cloud KMS, never on a node disk.
  • TPM 2.0 with measured boot on Core and governance nodes.
  • Time synchronised across all pools; breaches are timed by duration.
From the manifests · per replica, request → limit
ComponentReplicasCPUMemoryNotes
Deterministic Core34 vCPU8 GiBGuaranteed QoS: request equals limit. Namespace quota 16 vCPU / 32 GiB, no persistent volumes.
Heuristic Buffer22 → 4 vCPU4 → 8 GiBValidator engine.
Fringe gatekeeper20.1 → 0.5 vCPU128 → 256 MiBEvacuation is a pure function of observed state, so two replicas are safe.
Fringe proposer40.5 → 2 vCPU1 → 4 GiBRead-only root filesystem, no service-account token.
Not includedModel inference for the proposers. Size it separately against the provider or GPU estate you already run.
BasisDerived from resource requests and limits in the reference manifests, not from load-testing a live deployment. Treat the figures as a starting point.