Train the Procedure, Not the Weights

AROS White Paper, Part I — The Argument

Part I is free to read and stands alone. It makes the case from first principles. Parts II and III describe the system — AROS Core, its memory substrate, and the Cloud Federation layer — and the economics.

1. Introduction: the deployment gap

The last few years delivered a strange asymmetry. Frontier language models now pass professional examinations, synthesise working code, and hold multi-step reasoning chains together well enough to look, in a demo, like colleagues. Yet the number of such systems running unattended in production remains small. By third-party estimates, only about 2% of organisations had deployed AI agents at scale as of 2025 (third-party estimate). The capability curve and the deployment curve have come apart.

The usual explanations — safety, hallucination, cost — are real but incomplete. A more precise diagnosis is that the industry has been improving the wrong layer. Enormous effort goes into the model: more parameters, more pre-training tokens, more reinforcement from human feedback. Almost none goes into the procedure — the explicit, situated, step-by-step knowledge of how a particular task is actually done in a particular environment. A model is a general prior. Production work is specific. The distance between them is not intelligence; it is procedure, and procedure is exactly what today's stack has no first-class place to store.

This paper argues three things: that the missing layer is procedural; that it can be built as an inspectable, versionable artifact held separately from model weights; and that university biology laboratories are an unusually good place to source it.

We write under an explicit honesty contract. Every number below carries a register. Measured means observed on a running deployment, with its sample size and date. Modelled means a projection or design target. Third-party means an external estimate we did not produce. Where our own evidence is unflattering — and in one benchmark it is — we report it in the same breath as the favourable result. The surrounding market is genuine but should be read as third-party framing only: agentic-AI spend is estimated at roughly $7–12B by 2034 and the bioinformatics market at roughly $18.7B by 2030 (third-party estimates). The opportunity is real; the discipline is in not overclaiming our place in it.

2. The embodiment and determinism gaps

Why should procedure be scarce when models are so capable? Two structural gaps explain it.

The first is the embodiment gap. Digital computation is deterministic, discrete, and closed: a bit is a 0 or a 1, an operation is exactly repeatable, and the state space is in principle enumerable. Biology is analog, continuous, and open. A cell does not resolve to a clean bit; a pipette, a gel, a culture drift within tolerances that never recur in exactly the same form. In that world noise is not an error term to be suppressed — it is the raw material for adaptation and intuition. An experienced researcher's judgement is largely a learned response to variation that never appears twice. A model trained purely on text has never had to survive that continuous, noisy world, and so it has not acquired the procedural robustness that living in it produces.

The second is the determinism gap. A language model, sampling from a fixed distribution, cannot reliably self-generate the exploration entropy needed to climb out of a local optimum. Left to itself it tends to circle the most probable next token — fluent, confident, and stuck. The entropy that breaks the loop — the genuinely novel hypothesis, the "let's run the assay a different way" — is supplied by humans. This is not a temporary limitation of scale; it is a property of sampling from a distribution you also trained on. Train on your own synthetic output and the distribution narrows further: the well-documented failure mode of model collapse, and the reason authentic human procedure, not synthetic self-output, is the scarce input.

An efficiency contrast sharpens the point. The human brain runs on roughly 20 watts; the silicon that approximates a fraction of its general capability draws power at the megawatt scale in aggregate (third-party figures). The difference is not merely engineering headroom — it reflects that biological cognition solves the open, continuous, noisy problem natively, while digital systems pay heavily to simulate a narrow slice of it. We make this only as a qualitative contrast and do not invoke any thermodynamic limit, which would be off by orders of magnitude.

The same theme appears where the two worlds are deliberately combined. In the shared-autonomy teleoperation literature, blending human intent with machine control is reported to outperform either alone — on the order of 70.7% task success for the shared mode against roughly 40% for the less-guided baseline (reported in the cited literature; not our result). We cite it only as a directional signal: human exploration plus machine execution beats machine execution alone. That is the shape of the opportunity, and it points at where the reusable value lives — not in the weights, but in the procedure the human contributes.

3. Train the procedure, not the weights

If procedure is the scarce, valuable, transferable thing, it should be a first-class artifact — named, versioned, inspected, and improved on its own terms — rather than smeared irreversibly across billions of weights. This is the core design commitment of AROS Core: improve the context, not the model. Concretely, the context is a set of explicit objects — skills, policies, workflows, knowledge items, and agent personas — each editable and auditable the way source code is. On the reference deployment these objects are numerous and real: 1,630 skills in the hierarchy, 5,150 mental models, 777 active world facts, and 391 insights, read from a single instance on 2026-07-29 (measured; single instance). They are not a metaphor; they are rows you can open and read.

Two ideas turn this from a static library into a learning system. The first we call Active Environmental Latency: lessons from finished work are written back into the environment and pre-loaded into future tasks by an ambient screener that retrieves what is relevant before the agent starts, so the next run begins already informed (architectural). The second is the Entropy Injection Hypothesis: structured experiential memory acts as an anti-entropic engine, importing the human-supplied exploration entropy from section 2 and organising it so it can be reused (thesis). What actually runs today is memory consolidation — a "dreamer" summarises completed sessions into world facts, mental models, and insights under a schema-constrained model call, and a hygiene pass deduplicates and merges memory continuously (architectural). Rewriting the content of skills themselves (SkillOpt/GEPA) is built but has not yet completed a run on the reference instance; we describe it as built-but-unproven rather than claim its results (architectural).

The crucial discipline is that we transfer the abstraction, not the low-level trace. Replaying one lab's exact keystrokes into another context produces negative transfer — the specifics do not generalise and actively mislead. What transfers is the procedure at the right altitude: the decomposed, explicit reasoning a task requires. This is also why university laboratories are the right source. Teaching forces tacit expertise to be decomposed into explicit language; labs keep producing genuinely novel, AI-free ideas; and PhD operators generate human-in-the-loop data as the ordinary exhaust of their research.

Compared with fine-tuning, editing procedure is cheaper (no training run per improvement), auditable (a human can read exactly what changed and why), and privacy-compatible (the shared artifact is documentation-level abstraction, not raw experimental data). Our own deployment underlines the cost point honestly: over roughly two months across nine machines, the instance consumed more than 8.6 billion tokens — but around 70% of that went into building AROS itself, not into science (measured; stated as a limitation, not a throughput claim).

The thesis makes a falsifiable prediction: injecting structured procedure should help precisely where the bottleneck is procedure — multi-step reasoning and exploration — and should be neutral or even harmful where the bottleneck is parametric recall, because orchestration adds context and latency without adding facts the model already lacks. We ran that test. In a controlled benchmark completed 2026-07-26 and rescored 2026-07-27 — two tasks × three arms (baseline / MCP-only / AROS Swarm, intra-machine) × 300 items, 1,800 evaluations, executed purely locally over about 4.5 days — the results split exactly along the predicted line (measured):

We report the adverse chembench result deliberately, because it is exactly the kind of evidence the thesis must survive. If procedure were a universal additive it would have helped there too; it did not — and a theory that predicts "procedure helps reasoning, not recall" is strengthened, not weakened, by finding recall unimproved. Experimental hygiene held: the non-AROS arms recorded a memory delta of zero, so no learning leaked into the baselines (measured). The honest headline is the founder's own — orchestration hurts simple recall and wins multi-step reasoning. That asymmetry, not a single triumphant number, is the argument of this paper.

4 Architecture

AROS is four cooperating layers separated by one hard boundary: the line between what stays on the researcher's machine and what is allowed to leave it. Everything below that line — capture, storage, retrieval — is local by construction. Only distilled abstractions cross it, and only through an export filter described in Section 5. This section walks the layers from the engine outward.

4.1 AROS Core — the local engine

AROS Core is the persistent memory brain. It runs a four-verb loop: capture a completed unit of work, distil it into structured memory, consolidate that memory continuously, and recall it into future work. Capture, the memory store, and retrieval never leave the machine. The store is a single SQLite database that serves hybrid retrieval — dense vector search over embeddings combined with full-text search — so a query resolves both by semantic similarity and by exact term match. Agents and external tools reach the store through an MCP (Model Context Protocol) surface, which is how the IDE, the swarm, and third-party clients all read and write the same brain.

flowchart LR
  A[Session capture] --> B["Distil<br/>schema-constrained LLM call"]
  B --> C[("SQLite memory store<br/>vector + full-text hybrid")]
  C --> D["Consolidate / hygiene<br/>dedup + merge"]
  D --> C
  C --> E["Recall<br/>hybrid retrieval"]
  E --> F[MCP surface → agents / IDE]
  F --> A

Distillation is the one step that needs a model. A "dreamer" summarises each finished session into three memory types — world facts, mental models, and insights — via a schema-constrained LLM call, so the output lands in typed fields rather than free text. Because that call needs an LLM, AROS Core is only fully offline under Pure-Local Mode (SPEC §11.12), where a llama.cpp model serves the call from localhost. In the default configuration the distillation call goes to a Gemini key or the metered cloud gateway. The claim "runs with no cloud account" is therefore true only conditionally, under Pure-Local Mode; the capture, storage, and retrieval path is unconditionally local.

Self-improvement operates on two independent tracks, and honesty requires separating them. The track that runs today is memory consolidation: a hygiene pass that deduplicates and merges memory continuously as new material arrives (its thresholds are covered in Section 5). The second track, skill-content optimization (SkillOpt/GEPA), rewrites the text of skills themselves. It is built but has not completed a run on the reference instance — we describe it as built-but-unproven. GEPA is specifically greedy hill-climbing gated by a validation check: it proposes a rewrite, evaluates it, and keeps it only if the gate passes. It is not a genetic-Pareto algorithm — there is no population, no Pareto frontier, and no crossover — and we flag this because the name invites that misreading.

A single reference instance, read from

brain.db

4.2 AROS IDE — the human trace and audit surface

AROS IDE is a fork of Eclipse Theia. It is not an alternative brain; it is a window onto the one Core holds. It hard-depends on Core through three couplings — the REST API, the shared memory database, and the MCP server — and it fails loudly when Core is absent rather than degrading to a standalone editor. Its purpose is auditability: for any node in an agent's execution, a human can inspect the context that was assembled, the memories that were retrieved, the skills that were mounted, and the inputs and outputs that passed through. In a research setting where a result must be defensible, this trace surface is what lets an operator stand behind an automated step instead of trusting it blind.

4.3 AROS Swarm — intra-machine orchestration

AROS Swarm is the working orchestrator, and its scope must be stated precisely: it is intra-machine. It coordinates agent personas — the 34 personas above are its cast — within one machine, sharing the single local brain. It does not orchestrate a fleet of AROS instances across hosts. The multi-machine orchestrator, AROS Commander, is spec-complete but early: roughly 250 lines with networking stubbed, no host registry, no SSH pool, no hardware profiler in any repository. Commander is presented as waitlist, never as an available fleet product.

The value of orchestration is measured, not assumed, and the evidence cuts both ways. Wave A (complete 2026-07-26, rescored 2026-07-27 after a leading-zero ordering fix) ran two chemistry benchmarks across three arms — baseline, MCP-only, and AROS-swarm — at 300 items each, 1,800 evaluations total, executed purely locally over about 4.5 days with equivalence-aware scoring. Experimental hygiene held: the non-AROS arms showed a memory delta of zero, so no learning leaked into the controls.

The honest headline is that orchestration hurts simple factual recall and helps multi-step reasoning. We report the adverse chembench result because omitting it would forfeit the credibility the winning result is meant to earn.

4.4 Cloud Federation — the metered layer

The Cloud Federation layer is where AROS becomes a platform others can rent. Its spine is a metered LLM gateway that proxies Vertex AI, so every model call is counted. A per-run cost ledger attributes compute, storage, and LLM cost to each run and then applies margin. Org-scoped entitlements gate who may invoke which skills and pipelines, and a marketplace distributes them. Heavy pipelines never run inside the API server; they dispatch to ephemeral Cloud Run jobs that spin up, execute, and tear down, which keeps the request-serving tier stateless.

flowchart TB
  subgraph Local["Local machine — AROS Core"]
    M[("Local memory store")]
  end
  subgraph Cloud["AROS Cloud Federation"]
    G["Metered LLM gateway<br/>proxies Vertex AI"]
    L["Per-run cost ledger<br/>compute + storage + LLM + margin"]
    EN["Org-scoped entitlements"]
    MK["Marketplace"]
    J["Ephemeral Cloud Run jobs"]
  end
  M -->|distillation / metered calls| G
  G --> L
  Local -->|heavy pipelines dispatched| J
  EN --> MK

Two caveats keep this description honest. A per-run cost receipt component — the itemised compute/storage/LLM breakdown — exists in code but is not yet wired into the running apps, which today display only the run total. And the cost rates come from a hardcoded default price table in

cost_calculator.py

5 Federation and privacy

Federation is where a lab decides whether to trust the system with anything real, so the mechanism has to be simple enough to audit in an afternoon. It is.

5.1 The merge is a single-threshold binary gate

When a peer's abstractions arrive, the federation path in

sync.py

COSINE_DEDUP_THRESHOLD = 0.92

flowchart TB
  I["Incoming abstraction<br/>(from peer envelope)"] --> S{"cosine similarity ≥ 0.92 ?"}
  S -->|yes| D["Skip — treat as duplicate"]
  S -->|no| N["Insert into local brain"]

There is deliberately no arbitration band in the federation path — no LLM adjudication, no partial merge, no third tier. This matters because a different subsystem, local memory hygiene (

memory_hygiene.py

DEDUP_THRESHOLD = 0.92

MERGE_THRESHOLD = 0.80

5.2 The export allow-list — share the abstraction, keep the data

Privacy in AROS is enforced at the point of export, before anything is embedded or compared. As of the 2026-07-29 fix,

export_brain()

excluded_artifacts

The consequence is structural: "share the abstraction, keep the data" holds by construction, not by policy or good intentions. A researcher does not opt into privacy; the export path cannot carry a FASTQ file or a patient image in the first place. What federates is the distilled skill, fact, or mental model — the transferable procedure — while the evidence that produced it stays on the originating machine.

5.3 Why this is the only model a clinical or unpublished lab can accept

A lab holding patient-derived sequence data, unpublished results, or anything under an IRB or embargo cannot federate raw data under any margin of doubt — one leaked artifact is a reportable incident, not a bug. Two properties make AROS federation acceptable to that lab. First, the export filter is an allow-list, which fails closed: an unrecognised file type is excluded by default, so a new data format cannot silently slip through a blocklist that never anticipated it. Second, the merge gate is auditable in one line — a single cosine threshold with binary behaviour — so a data-protection officer can verify what the network does without reading a model's reasoning or trusting an opaque arbitration step.

This aligns with the platform's underlying thesis: the valuable, transferable asset is the abstraction — the procedure, the mental model — not the low-level trace. Transferring raw traces risks negative transfer between labs with different instruments and cohorts; transferring the distilled skill carries the reusable knowledge without the liability. For a clinical or unpublished-research setting, a federation model that can move raw data but promises not to is unacceptable. One that structurally cannot is the only kind that clears review.

6. What we have measured

AROS Core has run continuously inside one university research group for roughly two months: nine PCs, three senior researchers and three graduate students. Over that window the deployment consumed more than 8.6 billion LLM tokens. That figure carries a qualification we state up front rather than bury: roughly 70% of those tokens went into building AROS itself, not into science. The telemetry below is therefore the memory state of a system that has so far spent most of its budget on its own construction. Every number in this section comes from a single reference instance — a direct read of

brain.db

6.1 Reference-instance telemetry

brain.db

brain.db

brain.db

brain.db

brain.db

brain.db

brain.db

brain.db

These counts describe a memory substrate, not an outcome. A store holding 1,630 skills and 5,150 mental models tells you the system has been accumulating structured context; it does not, on its own, prove that context makes downstream work better. For that we ran a controlled benchmark, reported next. We deliberately avoid presenting these as fleet-wide totals: the honest unit is one instance over one deployment, and any larger aggregate would be invented.

6.2 Wave A benchmark

Wave A was designed to isolate the effect of orchestration. Two chemistry benchmarks were each run across three arms — a bare-model baseline, an MCP-only arm with tool access but no memory, and the AROS-swarm arm (intra-machine agent-persona orchestration with memory) — at 300 items per arm, for 1,800 evaluations in total. Execution was pure-local and took about 4.5 days. Scoring was equivalence-aware and was re-run on 2026-07-27 after a leading-zero ordering fix. Experimental hygiene was verified: the two non-AROS arms recorded a memory delta of zero, so no learning leaked into baseline or MCP.

The founder's own headline is the honest one: orchestration hurts simple MCQ recall but wins multi-step reasoning. On single-step factual lookup, adding tools and then adding memory-driven orchestration each made accuracy worse — the extra context and indirection get in the way of what is essentially a recall task. On multi-step reasoning, the ordering reverses and widens: MCP beats baseline, and AROS beats MCP. This is the result we most want on the record, adverse arm included, because the candor is the point. A platform that claims orchestration is universally beneficial would be contradicted by its own chembench numbers.

6.3 Limitations

The evidence above is real but thin, and we will not oversell it:

• Single instance. All telemetry is one machine's

  brain.db

  . We have no cross-instance replication.
• Small n, one setting. Six operators, one lab, one domain (chemistry benchmarks). Nothing here establishes external validity.
• Self-selected operators. The users are the people building the system; their skill and motivation are not representative.
• Budget skew. ~70% of the 8.6-billion-token spend went into building AROS, not into research output, so token totals are not a productivity measure.
• No formal control beyond the arm design. Wave A's three-arm structure is the only control; there was no pre-registration, no blinding, no multi-seed variance analysis.
• Equivalence-scoring caveat. Results depend on an equivalence-aware scorer that was itself corrected mid-campaign (the leading-zero fix); scorer design can move the margins.

What would falsify the thesis. The core claim is that accumulated, structured context improves multi-step scientific reasoning. It would be falsified if, across multiple instances and domains with adequate n, the AROS-swarm arm failed to beat a matched MCP-only arm on genuinely multi-step tasks — or if any measured gain vanished once operator self-selection and scorer choices were controlled.

What a rigorous next study looks like. Multiple independent instances across more than one lab and domain; pre-registered arms and scoring; several seeds per condition with reported variance; blinded equivalence scoring; and a token-cost accounting that separates system-building from task execution so that any accuracy gain can be weighed against its compute cost.

7. Economics

The sellable unit is context, not model weights — skills, policies, workflows, knowledge items and personas that encode how expert work is actually done. Pricing follows two orthogonal ladders.

• Ladder A — flagship platform seats, billed per month and nested: AROS Core, AROS IDE, and AROS Commander. Published planning prices are AROS Core $20/mo and AROS IDE $200/mo. AROS Commander is waitlist only and is not priced pre-launch.
• Ladder B — all-access content: every AI Tool, Skill, and Pipeline in the marketplace. Planning prices are $20 per tool, $5 per skill, $10 per pipeline, with a 70% creator cash share.

Online Apps sit outside both ladders and stay metered per run. Metering runs through a cost ledger that sums compute, storage, and LLM usage and then applies margin; entitlements are org-scoped; the LLM gateway proxies Vertex AI, and heavy pipelines dispatch to ephemeral Cloud Run jobs rather than the API server. A per-run cost receipt component exists but is not yet wired into the running apps — today they display the run total only, not the itemised breakdown. Cost rates come from a hardcoded default price table (the dynamic Vertex fetch is simulated with a fallback), so we do not claim rates are re-synced from Vertex in real time. On the privacy side that underpins selling context,

export_brain()

Modelled projection (kept separate from all measured figures above). Bottom-up, we model roughly 20 labs at month 12, ~50 at month 24, and ~100 at month 36, giving ≈$300K ARR at 36 months. This is a design target, not an observation.

Checkout is not yet open — no revenue has been collected, and the ARR figure above is a forecast, not a run rate.

For external framing only, third-party estimates put the agentic-computing context market at roughly $7–12B by 2034, bioinformatics at ~$18.7B by 2030, and AI drug discovery at ~$8.6B by 2028; as of 2025 only about 2% of organisations had deployed AI agents at scale. These are other people's numbers, cited as market context, not as our results.

8. Status and roadmap

Build status, stated plainly:

Two clarifications matter for anyone reading the roadmap. First, on self-improvement: what runs today is memory consolidation — a "dreamer" summarises finished sessions into world facts, mental models and insights via a schema-constrained LLM call, and a hygiene pass continuously deduplicates and merges memory. Skill-content optimization (SkillOpt/GEPA) is built but has not completed a run on the reference instance, and GEPA is greedy hill-climbing with a validation gate, not a genetic-Pareto method. Second, and most important: multi-machine fleet orchestration does not exist yet. The working orchestrator, AROS Swarm, is single-machine and orchestrates agent personas, not AROS instances. AROS Commander — the LAN multi-machine orchestrator — is specified but not built, with its networking stubbed.

Near term. Wire the per-run cost receipt into the running apps so users see the itemised compute/storage/LLM breakdown, not just a total; open checkout for the Ladder A/B products already priced; complete a first SkillOpt/GEPA run so skill rewriting moves from built to proven.

Mid term. Broaden Wave A into the multi-instance, multi-domain, pre-registered study described in §6.3; finish the AROS IDE trace/audit surface; harden the metered gateway and org-scoped entitlements for outside labs.

Long term. Build AROS Commander for real — a host registry, connection pool, and hardware profiler — so that the multi-machine story becomes a product rather than a specification. Until that code exists, we present Commander as waitlist and early, and we do not imply a fleet product is available.