The Koinessa Brain: Five Planes, One System
Your engineering decisions live in one agent's chat history. Your campaign results live in a spreadsheet someone exported in June. The reason you chose Postgres over DynamoDB for that one service lives in a Slack thread you can no longer find. Every new AI session starts by re-deriving context that already existed somewhere — business data, code knowledge, campaign results, and decisions scattered across systems that do not talk to each other and forget on their own schedules.
Section 3 of the Koinessa white paper addresses this with the Brain: not another dashboard, but a single memory-and-coordination substrate that agents, verification, and planning all read from and answer to. This post walks the architecture: the five planes, the single-writer gateway and the failure behind it, what the MCP and A2A protocols actually guarantee (with the measured security gaps), the sixth-vendor onboarding story, and why the model session is disposable while the operating system is durable.
One memory for engineering and operations
The business outcome first: one source of operational truth. Consolidation is not about tidiness — it is that an agent answering a marketing question and an agent resuming a half-finished PRD draw on the same verified facts, with provenance, instead of re-researching what the organization already knows. Retrieval before repetition.
The substrate is deliberately unglamorous: one DuckDB database. On 2026-08-23 it held 346 base tables and 21 views (27 of them retained migration backups), and tenant scoping is measured per relation rather than assumed: 333 of the base tables carry project_id; 13 shared or infrastructure tables do not. The instructive event is a migration, not the table count: a full identity-key migration across 47 tables and 110,811 rows ran live with zero corruptions, using full-table rebuilds, never in-place key updates. That is the risk-tiered autonomy doctrine applied to the system's own heart, and it exists because of the time the rule was not followed.
Five planes, not "an AI tool with memory"
The white paper refuses the description "an AI operating system with memory" and instead describes five distinct planes that form one system:
- Organizational state plane — business facts, requirements, policies, decisions, code intelligence, temporal state and provenance.
- Context plane — retrieve and compile the smallest authoritative packet the next worker needs.
- Coordination plane — identity, leases, fencing, ownership, checkpoints, handoffs, retries, multi-vendor scheduling.
- Evidence plane — independent verification, protected test definitions, attestations, policy evaluation, risk-tiered acceptance.
- Inference plane — local Ollama, Ollama Cloud, cheap cloud, and frontier models treated as leased workers selected by measured capability and cost.
What binds the planes is one invariant, worth quoting in full: inference may fail, disappear, hallucinate, compact, change vendors, lose its session, exceed its context, or become too expensive — without the organization losing state, authority, evidence, or control. Provider interchangeability is labeled a design goal supported only where code and runtime receipts exist, with capability labels (live, built-but-gated, in flight, planned) printed per component — the same discipline as the limitations and status report. The full decomposition is in the architecture section of the white paper.
The single-writer gateway is a scar, not a style
Every external write crosses one HTTP gateway. Writes and transactions are bearer-gated through a single writer mutex, work-item leases carry fencing tokens, and reads are token-free only when the gateway is bound to the loopback interface; on any other bind, reads require a bearer-identified principal exactly as writes do.
A narrow write path can look like a performance limitation until you read why it exists. An earlier in-place primary-key update corrupted the database's write-ahead log, and recovery worked only because snapshots and log replay had been designed before the failure. The single-writer design is that scar rendered as architecture — and the reason the identity-key migration above used full-table rebuilds.
The read posture comes from an older doctrine. NIST's SP 800-207, Zero Trust Architecture (2020), formalized the principle that no network location confers implicit trust: every access is authenticated and authorized per request, because the perimeter is assumed breached (csrc.nist.gov). Koinessa applies it literally: a LAN connection grants no implicit trust, and a worker may reach a resource while lacking the policy authority to use it — both facts are checked. Above the gateway, the coordination plane registers sessions and heartbeats, detects file-claim collisions cooperatively, and lets a successor session, from any vendor, resume from a checkpoint without chat history.
MCP and A2A standardize connectivity, not trust
The agent protocols are the system's edges, and the paper's position is that connectivity is the easy half. The Model Context Protocol specification standardizes how a model-driven application reaches tools and context, including an OAuth-based authorization framework (revision 2026-07-28) that is optional at the protocol level. The Agent2Agent protocol, a Linux Foundation project contributed by Google, addresses communication between independent agents. Neither is an identity system.
The fine print matters. The MCP HTTP authorization framework is optional and OAuth 2.1-based. A2A 1.0's Agent Card signing (section 8.4) allows JWS-signed cards; verification against a trusted key establishes card integrity and provider origin, but signing is optional and is not a global agent identity system. The internet standardized packet delivery without solving identity, fraud, or trust; agent protocols are repeating the pattern.
2026 produced measurements. A first measurement study of authentication security in the MCP ecosystem identified 7,973 live remote MCP servers and found 40.55% expose tools with no authentication at all. Against the 119 testable OAuth-enabled servers, a semi-automated detection framework found every one exhibited at least one flaw — 325 flaws in total, dynamic client registration flaws affecting 96.6% — serious enough to yield 9 CVE IDs via responsible disclosure. The paper's own caution applies: a May 2026 v1 snapshot of testable servers, not a universal property of MCP deployments. But "all 119 tested servers flawed" is not a number you assume away.
A second paper, Breaking the Protocol, attacked the specification itself. It identifies three protocol-level vulnerabilities — no capability attestation (servers can claim arbitrary permissions), bidirectional sampling without origin authentication (enabling server-side prompt injection), and implicit trust propagation across multi-server configurations — and shows across 847 attack scenarios on five MCP server implementations that MCP's architectural choices amplified attack success rates by 23–41% versus equivalent non-MCP integrations. The authors' backward-compatible extension cut attack success from 52.8% to 12.4%. The paper scopes these risks to MCP v1.0, and the current MCP security best-practices draft now provides mitigations — but untrusted server and tool content still requires client-side validation, isolation, and authorization.
Koinessa's answer is structural rather than hopeful: provenance and authority are fields on context, not properties a model guesses from prose. The tool registry holds 366 tools (137 API routes, 104 skills, 91 scripts, 29 agents, 3 CI components, 2 MCP servers) behind one two-level search contract, where a tool's invocation block is data, never inferred from a name. Every vendor harness reaches that contract through the same local MCP surface; the vendor-specific part is one registration stanza. Agents must consult a curated research corpus of 5,351 documents (unchanged since 2026-08-18) before the open web, so answers stay traceable to sources the company chose.
Six providers registered, six disabled: the guard is the feature
The unified provider layer is labeled built-but-gated: six provider descriptors (Kimi Code, Claude Code, Codex, Grok, local Ollama, and Devin CLI) registered behind one typed shape and three session transports, every one of them disabled. That is the design working as intended.
A descriptor carries everything vendor-specific as data: a SHA-256-pinned binary and probed CLI version, a credential probe that checks file presence and never reads contents, per-model context windows with a four-value provenance vocabulary (measured, probed, vendor-documented, unverified stand-in), and a fail-closed enabled flag. Unprobed fields carry an explicit marker no gate accepts, so a descriptor registered before its binary ever ran fails preflight closed. The three transports share one contract with eight named preflight failure kinds and secret-free results by construction.
The sixth descriptor, Devin CLI, is the worked example of onboarding a vendor without extending trust ahead of evidence. Before any enablement, Koinessa committed a deny-all guard (a configuration denying every tool class plus a pre-tool hook that blocks with a machine-readable refusal) and proved it with an in-tree canary: the session's only tool call was refused, and a planted marker never left the tree. The data-governance precondition was verified rather than assumed: Cognition's terms allow customer data to be used for model training, with a paid-tier opt-out that enables zero-data retention, so the operator moved to a paid tier and confirmed the opt-out before the first governed probe (operator-reported, 2026-08-23). The guard's boundary is stated just as carefully: it governs the local CLI lane; a vendor cloud session on its own clone is governed by repository rules and provider-side controls. Deeper integration is specified and in review, labeled in flight.
Disposable sessions on a durable operating system
The Context Compiler (implemented 2026-08-10) assembles a bounded, provenance-bearing Context Packet for each physical model session from canonical state: the approved requirement, Git state and diff, authoritative Brain facts, code symbols with precise source ranges, ownership, the latest checkpoint, verification evidence, applicable policy, and budget. A logical work item spans many short physical sessions — session A, checkpoint, session B, checkpoint, verified completion — and no physical session owns the truth. Inference is leased: a logical worker holds no upstream slot while local tests run, so swarm size stays independent of any provider's concurrency envelope. Verification, not the generator's narrative, is the stop condition: the fail-closed discipline behind evidence-gated agentic development. The compaction position is absolute: no lossy conversational summary is ever the authoritative copy of organizational state, so a session's context can always be rebuilt from canonical state.
Durability earned its place the hard way. The machine serving the Brain lost power sixteen times in fourteen days; two cuts tore the database's main file, and one, unwatched, produced a multi-day crash loop against a newest snapshot ten days old. The response, landed in code and tests on 2026-08-23 and running in the gateway since its cutover to a native Windows service on 2026-08-24, treats a crash as a cost measured in seconds: checkpoints every sixty seconds or fifty writes; three corruption classes handled distinctly (a transient lock retried, an un-replayable write-ahead log quarantined, a torn main file restored from the newest importable snapshot and atomically promoted); the recovery writes its own audit row into the restored database before promotion; and when no snapshot imports, the gateway refuses to start with a dedicated exit code its supervisor reads as stop-not-restart — serving an empty brain would be worse than serving none. Institutional memory that cannot survive a crash is not institutional memory.
The takeaway
Scattered state is not an information problem; it is an authority problem. When decisions, code knowledge, campaign results, and evidence live in different systems with different forgetting curves, every agent session pays the re-derivation tax and no one can prove what the organization knows. The Brain's answer is architectural: five planes bound by one invariant (inference is disposable, state is not), a single-writer gateway built from a real corruption scar, protocol edges treated as connectivity rather than trust because the 2026 measurements say exactly that, and vendor onboarding that starts at deny-all and earns its way in. The full argument, with every snapshot date and capability label, is in the Koinessa white paper.