Architecture

How a single-operator multi-agent research platform is organised. Conceptual layer, not implementation recipe.

This page is a conceptual map. It is calibrated to be substantive enough that a technical reader can verify the moat is real, and reticent enough that it is not a build-it-yourself manual. The actual code stays internal.

§ I   The mesh

The platform is organised as a mesh of specialised agents that compose, validate, and — where the editorial register requires it — debate each other’s output before anything reaches publication.

Roles in the mesh:

• Analysts decompose a question into independently testable sub-questions. Multiple analysts run in parallel against the same query when the problem benefits from divergent decomposition.
• Validators check claims against evidence the analyst produced. Validator output is not exempt from scrutiny — it is itself subject to the asynchronous audit pass described below.
• Supervisors read the validator output and decide whether the chain proceeds, is sent to debate, or is killed.
• Debate pairs are invoked on contested claims. Two agents argue from pre-assigned opposing positions; a mediator scores the exchange against the original evidence.
• Auditors run separately, asynchronously, against a rolling slice of finished work. They are not in the production hot path; their job is to catch failures the hot path missed.
• Writers and editors sit at the publication boundary. They are the last agents to touch a piece, and the first place a stylistic or factual drift is caught.

These roles are not implementation details. They are the unit of composition. New publishing arms — new sites, new domains, new editorial registers — are built by recomposing the same roles against a different soul set.

§ II   Souls

A “soul” is a structured personality file that shapes how an agent reasons. Souls carry decision principles, anti-patterns, characteristic cognitive moves, and craft instructions. They are not prompts; they are a layer above prompts, applied invisibly during agent construction.

The same agent role can wear different souls. A validator running against an Institute signal wears a soul calibrated for statistical rigour and conservative kill thresholds. The same validator running against an Angles & Footnotes story wears a soul calibrated for editorial integrity and source-coverage breadth. The underlying code does not branch on context — the soul does.

The platform currently ships with more than two hundred souls, including a curated set of historical-figure personas for specific essay registers. Personality rights are tracked: living individuals are opt-in only; pre-1940-death public figures are catalogued and rights-cleared for attribution.

§ III   The conclave principle

A claim does not reach publication on a single agent’s word. The verification chain runs query decomposition, independent validation, optional debate between agents arguing assigned opposing positions, and a final supervisor sign-off — the number of agents involved scaling with the claim’s strength and stakes.

This principle is most fully realised in the editorial workflow: the writer / critic / chief-editor chain ensures that no piece of long-form output ships unargued — a writer drafts, a critic argues against, an editor adjudicates. That pattern is conclave-shaped: structured disagreement before publication.

The same principle operates one level up, in development itself — architectural decisions are argued out between the operator and a planning model before code is written, implementation runs against that plan, and a review pass audits the result. The platform exists because conclave-style disagreement was used to build it, and it embeds the same pattern in the workflows where the stakes justify the cost.

Where conclave-style disagreement is not a runtime gate on every arm, the audit gate — described in Methodology in Code § III — carries the load. What matters externally: the things the platform publishes that matter most have been argued with, not asserted.

§ IV   Execution contexts

The platform is designed to support isolated execution contexts: per-client scoping of memory stores, tool credentials, and audit logs, so that one corpus need not see another. That scaffolding exists in the code. It has not yet been exercised by a real external client against a private corpus — every agent today runs in the shared default context.

What the four public arms demonstrate today is something narrower but real: the same engine sits behind four editorial faces, each produced by recomposing the agent roles against a different soul set. The arms are soul-set recompositions, not isolated tenant deployments. The isolation machinery is what would make the platform deployable as infrastructure for an external party — a designed capability, presented honestly as one not yet proven in production.

§ V   Routing

The platform talks to a portfolio of language models — local and cloud, multiple providers, multiple price tiers. The routing layer chooses a model per call based on the shape of the work, not on a fixed assignment. Heavy reasoning routes to capable models; high-volume scoring routes to fast cheap ones; sensitive editorial routes to whichever model the soul’s tier requires.

Routing decisions are observable and reversible. When a provider degrades, the platform fails over without intervention. When a new provider appears, it is added by configuration, not by refactor.

The routing algorithm itself is not published. The principle is: model choice should be a calibration knob, not a code change.

§ VI   Portability

The platform runs today against a local llama.cpp server as its primary inference target, with cloud providers as elastic capacity.

In use today: a local llama.cpp server plus Groq, Cerebras, Mistral, OpenRouter, and Google — six providers, wired and running.

Addable by configuration, no code change: AWS Bedrock, OpenAI direct, vLLM, ollama, Ollama Cloud — the routing layer is provider-agnostic, so any OpenAI-compatible endpoint drops in.

The distinction is deliberate: the first list is verified running code; the second is portability true at the level of architecture, not yet exercised.

No code change is required to swap the primary model. A configuration change is. This matters for two reasons: the platform survives any individual provider’s pricing decision, and it can be deployed inside an air-gapped or sovereign-cloud environment without rewriting the inference layer.

§ VII   Engineering discipline

Discipline here is two things, and it is worth keeping them separate. Some of it is code that fails loudly on drift. Some of it is protocol the operator follows. Both matter; conflating them would overstate what the machine does unattended.

Enforced in code, running continuously:

• A pre-commit pattern sweep that scans diffs for known bug-class shapes — bypassed safety helpers, missing timeouts, hardcoded credentials — and refuses commits that reintroduce them.
• A startup invariant suite that asserts canonical helpers are still in their canonical position. Drift between releases is caught at process boot, not in production.

Operator protocols, applied by working practice rather than by automated check:

• A three-strikes escalation rule: three failed fixes on the same symptom mean the problem is misdiagnosed. The operator stops fixing and starts investigating.
• A pre-instrumentation standard: every destructive operation, every new lock, every non-transactional multi-step write is expected to log enough state for a 2 a.m. debug session before it ships.
• An evidence-first protocol: code changes follow root-cause analysis, not the other way around. Fixes are expected to name the failure they prevent.

A representative episode, told straight: during Institute work, a draft paper cited a real study but carried a headline effect size fabricated from a different study. It was caught at editorial review before publication.

The structural response was a citation auto-verifier — a check that traces every load-bearing number in a draft back to an extant source and flags any that cannot be matched. That is the pattern: a defect that gets past the existing gates becomes a new gate. (The same episode is recounted on the Institute’s own methodology page; it is one incident, described consistently across both.)

§ VIII   The mesh, sketched

The same mesh composes against four soul sets to produce four publication arms: Institute, A&F, Phronopolis, AI.

§ IX   What is not on this page

Implementation specifics — prompt patterns, exact routing rules, specific soul section structure, the editorial workflow’s internal composition, the auditor’s evaluation rubric — are not published. That is the proprietary core, and it is what conversations at Partners are about.

Drafted with AI assistance under operator supervision; substantive claims are operator-authored or operator-approved.