Foundation0
Menu

Instruments · for one person and their agents

A lab’s worth of instruments, for one person

A language model on its own reads text and writes text. Everything else a scientist needs, from a notebook to a budget, has to be built around it. This page explains that surrounding machinery from first principles, and the four instruments that we and our founding members are building.

Exo · private preview Auto-research-agent · released autofoundry · open source v0.1 As of 14 Oct 2026

The harness, part by part

How to read: the model sits in the middle; each part around it is something the harness adds. Pick a part to see what the model lacks without it, what a lab would use instead, and which instrument on this page builds it.

A diagram of a harness: the model in the centre, surrounded by five parts (memory, record, permissions, cost meter and tools), each joined to the model by a spoke.
Part //

Memory

Without it
Each request starts from nothing but the text sent with it. Yesterday is gone unless someone pastes it back in.
With it
A memory that outlives the session: every message kept in a searchable log, and each request built from short layered summaries plus the latest messages word for word.
In a lab
Colleagues who remember last month’s dead ends, and the group’s shared notes.
Source: exo.askaconsult.com (“the code around a model that lets it act”), the members’ READMEs, and this page.A diagram, not data.
Show as a table
The five parts of a harness
PartWithout itIn a labBuilt here by
MemoryEach request starts from nothing.Colleagues and shared notesExo; Auto-research-agent
RecordNo trace of who asked, which model answered, or what was accepted.The signed lab notebookExo
PermissionsA model that can act can push, post or pay in your name.The safety officerExo
ToolsIt can describe an experiment but not run one.Equipment and techniciansExo; Auto-research-agent; autofoundry
Cost meterYou cannot see which model answered or what it cost.The grant office’s ledgerExo

00//From first principles

Plain words first

The model is the engine. The harness is the car.

A large language model is a program that has read a vast amount of text and learned to continue it. Give it some text and it writes more. That is all it does. It cannot open a file, run a test or remember yesterday. It does not know what its answer cost, or which version of itself produced it. Each request starts from nothing but the text sent with it, and that text has to fit in the model’s context window: the most it can read at once.

So everything useful about an AI system lives outside the model, in the software around it. That software is called a harness, like the straps that let a horse pull a cart. We prefer a car. The model is the engine: powerful, and useless on its own. The harness is the rest of the car. Tools are the wheels and the steering. Permissions are the brakes and the seat belt. The record is the logbook, memory is the driver’s sense of the road so far, and the cost meter is the fuel gauge.

Why this matters to someone working alone

A university lab gives a scientist more than equipment. It gives them a notebook others can audit, colleagues who remember last month’s dead ends, a safety officer, technicians, and a grant office that tracks what was spent. An independent researcher has none of these.

Yet people working alone or in small groups have lately been producing large, checkable results with AI. On this site, founding member eumemic used an AI coding agent to search NASA data on more than four million stars and by 14 October 2026 counted 665 small-planet candidates (not yet confirmed) that the official searches had passed over. In a public race started by founding member Doug Colkitt, people and their agents took a saving in fast multiplication from 2−182 to about 2−9.2 in a week, every step checked in exact arithmetic, though all of it still rests on a machine-written paper nobody has yet reviewed. Each of those results came from a person, a model and a harness. When the harness is good, one person can work like a lab. When it is poor, the work is hard to repeat, hard to credit and easy to get wrong.

What a lab gives you, and the harness version
A lab hasA harness can give
A bound, signed notebookA record that can only grow, each entry signed
Colleagues who rememberA memory that survives sessions
A safety officerPermissions that ask before anything leaves
Equipment and techniciansTools: files, code, rented computers
A grant officeA cost meter that never shows an unknown price as zero

01//Exo · Aska Digital

Private previewEarly build · no outside reviewOpen source when ready to ship

Exo: one agent, one memory, one record, and consent to the exact words.

Exo is the harness Aska Digital is building, first for its own daily work. Its central idea comes from accounting: keep a record that can only grow, and work out everything else from it.

The Exo mark, drawn live

Stage 2 · lattice. Nineteen cells, 114 dots: the honeycomb as an orb.

Every edge is 2(√2 − 1), twice the ball radius in Aska’s incentre lattice, another project on this site. Drag the stage from 0 (an egg) through 1 (a cell) and 2 (a lattice) to 3 (four dimensions). Lattice egg renderer from Project Exo, © 2026 Aska Digital, MIT.

Sealed until release, like Seldon’s Time Vault

What it does, in four ideas

  1. Start from a record, not a memory. Every meaningful event (what you said, a rule you gave, what an agent did, whether you accepted it) is added to a log that is never edited. Each entry is signed and carries the fingerprint of the entry before it, so changing any old entry breaks every link after it. Everything Exo believes about you is computed from that record, the way a bank balance is computed from the transactions. Whitepaper §3
  2. One agent, one continuous memory. Every window, scheduled run and message from another agent is a thread of one agent with one log. Each turn is a fresh request built from summaries plus the latest messages. See it work below.
  3. Ask by consequence, and bind consent to the exact words. Private steps that can be undone run at once and are logged; anything public, irreversible, paid or touching other people waits for you, and your yes covers a fingerprint of those exact words. Try it below.
  4. A harness that watches itself. Every model call records which model was asked for, which one answered, each failed try, the wait for the first word, the tokens and the cost. Plain rules read that record after each turn and file findings; a fix counts only after 20 quiet turns or 3 days. A price Exo does not know reads “unknown”, never $0. §9, §13.5
  • 3 of 5
    build waves built and in daily use on one agent
    exo.askaconsult.com · status
  • 1,485
    root-suite tests passing at revision a0fc85e (65 skipped), plus 751 in six plugin suites; reported by Aska, 13 Oct 2026
    roadmap · latest verified work
  • 7 days
    the longest an “always allow” lasts for anything that leaves your machine (30 days for other acts; credentials never)
    whitepaper §15.3
  • 8
    messages folded into each leaf of the summary tree that replaces a growing transcript
    whitepaper §17.2

Build waves, as the Exo site lists them

  1. Wave 1Core skeletonBuilt
  2. Wave 2Re-home plugins on the coreBuilt
  3. Wave 3Terminal and web clients, learning loopBuilt · daily use on one agent
  4. Wave 5A small devicePlanned

exo.askaconsult.comWhitepaper v0.2RoadmapTerminal clientWeb app

03//Explainer · the summary tree

Illustration · simplified

Memory that stays one page long.

Most chat apps send the whole conversation with every request, so each request is longer than the last, until it no longer fits. Exo builds every request fresh: summaries of the old, and the latest messages word for word.

The whitepaper’s picture is a long book. “To keep reading well you need the summaries of everything so far, plus the last few pages in full.” The last 12 messages travel verbatim (word for word). Older messages are cut into leaves of 8, and each leaf gets one short summary. When the summaries together pass a budget of 6,000 tokens (the word-pieces a model reads; Exo estimates one per four characters), the oldest pair of neighbouring summaries at the same level merges into one, a level up. Nothing is thrown away: every original message stays in a local database you can search.

What one request carries, as the conversation grows

How to read: the bottom strip is the whole conversation, oldest on the left. Boxes above it are summaries: filled boxes are sent with the next request, outlined ones are older summaries already merged into a parent. The chart below compares the size of each request with a plain transcript. Drag the slider, or press play.

Ctrl //
Rules from Exo whitepaper §17.2: a verbatim tail of 12, leaves of 8, merge the oldest neighbouring pair when summaries pass 6,000 tokens. Assumed sizes (ours, for illustration): a message is about 250 tokens and any summary about 500.Exo credits the idea (“a verbatim log with a tree of summaries, a fresh model call each turn”) to OptChat (Victor Taelin) and UniiChat (Higher Order Company), and copies no code.
Show the numbers
Tokens per request at a few conversation lengths (assumed sizes as above)
MessagesSummaries sentMessages word for wordExo request, tokensPlain transcript, tokens

04//Explainer · the climb

Illustration · not the Exo software

Learning that has to beat the noise.

Exo’s site promises a model fitted to you. Its whitepaper says how a lesson earns its place: a change is kept only if it scores better on an exam built from your own past decisions, by more than the exam’s own wobble, and does not score worse on questions the process never saw.

The exam is personal: questions about you with known answers, pairs of a reply you rejected and the one you chose, and real past moments cut off just before you gave your verdict. It is split by time. The oldest part is train, which the reviewer may read. The middle is dev, where each candidate change is scored. The newest part, plus a fixed 20% sample, is held out: the loop never reads it, and uses it only for the final keep-or-drop. The whitepaper’s picture is a hillside in fog: you cannot see the top, but you can tell whether one small step takes you higher.

Why hold anything back? In the whitepaper’s words, “any process that tries many small changes and keeps the ones that score better will, given enough tries, find changes that fit the quirks of the test rather than the person.” Turn the held-out check off below and watch that happen.

The climb, one change at a time

How to read: each dot is one proposed change. The top panel is the dev exam: the orange staircase is the current setup’s score and the shaded band is its run-to-run noise. A filled dot was kept; a hollow dot was dropped, either because its gain stayed inside the noise or because it fell on the held-out exam below. Press “Propose a change”.

  • the current setup’s score
  • run-to-run noise
  • kept
  • dropped: no gain beyond the noise
  • dropped: fell on held out

Ctrl //
Rules from Exo whitepaper §22.5: score the current setup more than once to measure its noise; drop a candidate unless it beats the current setup on dev by more than that noise; keep it only if held out does not drop. Made-up lessons and simulated scores (seeded, the same for every visitor); no Exo eval score is published.
Show every change
Every proposed change in this illustration (simulated scores, % of exam questions)
No.ChangeDevNeeded on devHeld outDecision

05//Exo OS · Aska Digital

Private previewPhase 0 · research and designOpen source when ready to ship

Exo OS: the same core, as an operating system.

An operating system is the layer of software that decides which program may touch which file, device or key. Isolation lives there. Exo OS asks what an operating system looks like when an agent like Exo is its foundation, not an app on top.

The public record is short, and we keep to it. Exo OS runs the same core and the same protocol as Exo, with no fork, in its own repository. Phase 0 is research and design of the base system, the shell, security and small hardware; the operating system “is meant to supply the isolation.” The whitepaper (version 0.2, October 2026) is blunt about the rest: “nothing of it is built, and no machine runs it.”

Since that whitepaper, one piece has moved from design into code. The roadmap’s evidence panel of 13 October 2026 says: “Exo OS can now require every tool call to pass through an installed execution broker” (a separate program that carries out approved actions), while “the operating-system sandbox behind it is still being built.”

Roadmap card: Exo OS, phase 0Whitepaper §27

Where each layer stands

How to read: what you use at the top, the machine at the bottom. A solid outline is built and in use; a dashed outline is designed, with nothing running yet. Pick a tool call and send it down the stack to see how far it gets today.

  1. Clientsterminal and web appBuilt
  2. Exo coreone protocol · the gateBuilt
  3. Execution brokerevery tool call can be made to pass through itIn code
  4. Exo OS sandboxbase system · shell · isolationPhase 0 design
  5. Hardwarea small companion devicePlanned

Pick a tool call, then send it.

Source: Exo roadmap, evidence panel, 13 Oct 2026; whitepaper §27. The walk-through is our illustration, not the Exo software.

06//Auto-research-agent · rohanarun

Released softwareMIT licenceFounding member’s project

Auto-research-agent: send your own agent to an open problem.

Founding member rohanarun’s Mac app makes it, in its README’s words, “dead simple to point your Codex or Claude at open problems, put unused tokens to work, and help push the frontier.”

A sidebar lists open research projects from a catalog, “Auto Research by Super”: GitHub repositories that publish an auto-research.md guide written for agents. Press play and the app clones the project, hands the guide word for word to the coding agent you already have (OpenAI Codex or Claude Code), and shows the conversation live. It also shows each project’s latest claim and a small chart of its progress.

Optionally it runs several agents at once. On a timer it stops them, asks the model to merge what they found into one shared summary, and starts fresh agents from that summary. The defaults are 2 agents and a 10-minute interval.

Every agent also gets the same research policy, which reads like a lab’s code of conduct. It asks agents to keep formal proofs, exact finite checks, measurements, conditional results and a maintainer’s acceptance apart, and never to weaken a check to make a candidate pass. Its plainest line: “Never manufacture a record, passing check, publication, or external outcome.”

Status, plainly. Released software, not a research result. The README says the downloadable version 1.2.3 is “Developer ID signed and Apple notarized”. It was published on 13 October 2026 (12 commits that day), MIT-licensed, written in Swift with no third-party Swift dependencies. No research result made with the app is documented yet.

The member behind it

rohanarun builds software that lets AI coding agents work on open research problems. Working with Codex and Claude, they are the most active contributor to the integer-multiplication race, and they hold the current reviewed record there: PR #1094.

κ = 0.001672660197076918Reviewed record at the time of writing (selected 13 Oct 2026). Checking the live value…

Repository · rohanarun/Auto-research-agentrohanarun on GitHub

The loop: propose, check, pool, restart

How to read: step through one round. Agents work in parallel at the top; the timer stops them and their findings are pooled into one shared summary, which the next round starts from. Change the number of agents to see the round widen.

A loop of four steps around a shared summary: propose, check, pool and restart, fed by a catalog of open projects.
Ctrl //
Source: Auto-research-agent README (lines 55–69) and its research policy (Resources/ResearchPolicy.md). “Check” is the policy every agent receives plus each project’s own review; acceptance happens upstream, with the project’s maintainers.
Show the steps as text

    07//autofoundry · Ryan Shea

    Open-source software · v0.1.0MIT licenceFounding member’s project

    autofoundry: one experiment, many rented machines.

    Training a small AI model is now cheap enough that an agent can run hundreds of short experiments. The hard part is renting the hardware. Founding member Ryan Shea’s command-line tool does that across four clouds.

    A GPU (graphics processor) is a chip built to do many small calculations at once, which is exactly what training a model needs. Cloud companies rent GPUs by the hour, each with its own sign-up, prices and quirks. In Andrej Karpathy’s autoresearch, AI agents edit a training script and re-run it on their own; the README calls autofoundry “a CLI companion” to it. You name a script and a GPU type, and autofoundry:

    1. searches four providers (RunPod, Vast.ai, PRIME Intellect and Lambda Labs) for matching machines, and rents them;
    2. copies the script over, runs it and streams the output back live;
    3. collects whatever numbers the script prints after a --- line;
    4. reports the best, mean and worst result across the runs, and shuts the machines down.

    Why does the spread matter? Training involves chance: the same script on two identical machines rarely gives the same number. One run is one sample. Several runs show how much the result wobbles, and a change is only worth keeping if it beats that wobble. That is the habit of every good lab, made cheap.

    Is the change real, or noise?

    How to read: experiment A is a baseline; B adds one change that truly helps a little. Each dot is one run on one rented machine (lower is better). The bar on each row spans worst to best, and the tall tick is the mean. Rent more machines per cloud, run again, and watch whether B’s lead clears the noise.

    • A · baseline
    • B · one change
    • best–worst bar, mean tick

    Ctrl //
    Simulated numbers. The steps follow the autofoundry README; the scores are drawn at random in your browser (A centred on 1.000, B on 0.995, the same run-to-run spread for both), so the lesson is about noise, not about any real model or provider.Each run reports a validation loss: how wrong the model’s guesses are on text it did not train on.
    Show the runs
    Every run in the current draw (simulated)
    ExperimentCloudMachineValidation loss
    • 4
      GPU clouds searched and rented from: RunPod, Vast.ai, PRIME Intellect, Lambda Labs
      README
    • 33 of 40
      commits on main carry an Anthropic Claude co-author line (Haiku 4.5 on 22, Opus 4.6 on 11)
      git history, 14 Oct 2026
    • 92
      test functions in the repository (not run by us)
      tests/ in the repository

    Repository · shea256/autofoundryshea256 on GitHubkarpathy/autoresearch

    08//Status at a glance

    As of 14 Oct 2026

    What exists, who made it, and what has been checked.

    An instrument is only as trustworthy as what you can check about it. Here is each one, in the same terms.

    The four instruments
    InstrumentMade byWhat it isStatusCodeWhat has been checked
    ExoAska DigitalA harness: memory, record, gate, cost meterPrivate preview
    3 of 5 build waves built    		Private; open source when ready to shipAska’s own test runs (1,485 + 751 passing, 13 Oct 2026). No benchmarks, no outside review.
    Exo OSAska DigitalThe same core as an operating systemPhase 0 design
    One piece is in code: an execution broker every tool call can be made to pass through. The sandbox behind it is still being built.    		Private; open source when ready to shipNothing outside can check yet (private).
    Auto-research-agentrohanarunA Mac app that runs coding agents on open problemsReleased
    v1.2.3    		Public, MITSigned and notarized by Apple, per its README. No results made with it documented yet.
    autofoundryRyan SheaA command-line tool that rents GPUs on four clouds and runs one experiment everywhereOpen source
    v0.1.0    		Public, MIT92 test functions in the repository, not run by us. Not on PyPI.