Whitepaper · September 2026

Private intelligence, owned together

The technical design of Sturnia: a local agent that is allowed to see everything, community co-ops that turn it into a specialist, and a federation that lets specialists answer each other.

Abstract

The people whose work would gain most from AI, clinicians, lawyers, therapists, accountants, are the people who cannot paste that work into someone else's computer. Sturnia is an AI agent built for them. It runs entirely on the user's own machine, answers only from the user's own documents, names its sources, and refuses to leave the machine unless a person decided it should. Around that agent we design two outer layers: the co-op, where a real community pools its machines and curated knowledge into one shared specialist, and the federation, where co-ops route hard questions to one another and return signed answers with disagreement preserved. Co-ops keep score with bilateral, non-transferable credits, not a token. Nothing earns standing unless it has been verified. The organising rule across every layer is the same: lessons travel, records stay home.

Motivation

The problem

General-purpose AI is cheap and everywhere, and it is built on one assumption: that your work can travel to a datacenter you do not control. For most tasks that is fine. For a referral letter, a patient's history, a client's contract or a case file, it is not. The work is confidential by law, by contract or by conscience, and the cloud's product is the cloud. "Nothing leaves your desk" is the one promise it cannot make.

Two things have changed. Models small enough to run on an ordinary laptop now read, write and reason well enough to do real administrative work. And the knowledge that makes a professional good at their job, worked examples, resolved cases, the right phrasing, lives in communities, not datacenters. Sturnia is designed around both facts: do the private work locally, and let communities combine what their agents have learned without ever combining what their agents have seen.

Our first users are clinicians, and the first job is administrative, letters, forms, summaries of the user's own records. Sturnia drafts and checks; it does not diagnose.

Invariants

Design principles

Every mechanism below exists to keep one of these true. Where a mechanism and a principle conflict, the principle wins and the mechanism is redesigned.

  1. Useful alone, better together.

    The agent is complete with no network at all. Co-ops and the federation are multipliers, never requirements.

  2. Nothing leaves unless a person asked.

    Egress is refused by default, every exception is named and counted, and anything outbound is shown word for word before it goes.

  3. Never answer without sources.

    If retrieval finds nothing, the agent says so rather than letting a model fill the silence.

  4. Nothing is earned but verified work.

    Standing, routing weight and credit follow only what can be checked.

  5. No single kill switch, including ours.

    The network keeps running without its founders. New model releases roll out to volunteers first, and many independent hands hold the rollback.

Layer 0

The agent

The agent is two processes. The engine does everything: ingesting documents, retrieval, answering, speech. The shell is a desktop window that talks to the engine over loopback HTTP and holds no logic of its own. A command line and the desktop app are two front doors onto the same engine, so a capability is never available through one and missing from the other.

  1. microphone
  2. capture
  3. wake
  4. speech to text
  5. retrieve + answer
  6. spoken rendering
  7. synthesis
  8. speaker

Retrieval: SQLite with full-text search and vector search · Models: llama.cpp and whisper.cpp as child processes bound to 127.0.0.1

Figure 1. One spoken turn, entirely on the user's machine.

Local by construction

"Local-only" is not a setting; it is enforced in the socket layer. A guard called netguard replaces the process's connect call and refuses every address that is not loopback. The model servers are child processes bound to 127.0.0.1, so the guard permits them without exception.

There are exactly three ways out, and each one is a decision a person made: first-time setup, a model download the user started, and a conversation the user deliberately pinned to a cloud provider. None of them bypasses the guard. Each runs under a permit that is scoped to one thread, carries a stated reason, and covers only the call that opens the connection. Permitted connections are counted apart from ordinary loopback traffic and shown on the Privacy screen, because traffic the user asked for is still traffic. A permit with no user decision behind it is a bug.

The promise is checkable from outside the software, too. A published script samples the process tree's TCP peers during a real answer and reports every remote address it sees. On a default install the list is loopback only. Anyone can run it; nobody has to take our word for it.

When a conversation is pinned to a cloud model, the user is told once, before the first send, exactly what the provider will receive: the question, the conversation, and the passages retrieved for it. Every answer that left the machine is labelled with where it went. Document embeddings never leave, and the default mode is local by construction.

Two speeds: talking is fast, documents are checked

The agent answers on two paths, and the split falls where the product already wants it.

Spoken or typed turnArtifact
Used forquestions, conversation, digestsanything written down: a letter, a form
Pathretrieve once, draft once, streamdraft, extract every claim, verify each against the user's documents, drop what is unsupported, finalise
Costone model call2 + N model calls for N claims
Promisegrounded in retrieved sources, named aloudevery claim checked

Nothing spoken is ever presented as verified, and nothing written to disk skips verification. We rejected the alternatives on purpose: verifying every spoken sentence costs ten or more seconds of silence per turn, and speaking a draft first and correcting it afterward means sometimes telling a doctor something wrong out loud.

The voice loop

The spoken path has a budget: under one second from the end of speech to the first audio, enforced as a test that fails the build rather than a number on a dashboard. Most of that budget comes from streaming. Synthesis starts on the first complete sentence, not the last token.

It answers only when addressed. An always-listening assistant without a wake word answers the television. Sturnia treats being addressed as a property of the transcript: an utterance counts only if it opens with the agent's name, matched fuzzily because transcription is fuzzy. A short follow-up window carries a sentence across a breath without the agent still listening when you turn to somebody else.

It can be interrupted. Barge-in uses the operating system's voice-processing unit, the same echo cancellation native assistants use, so the agent's own voice is removed from the microphone signal and cannot be mistaken for yours.

Audio is never kept. Capture lives in a bounded in-memory ring buffer. Only audio from the start of an utterance to its end is transcribed, and no audio, transcript or derived text persists beyond the turn unless the user saves it. A privacy product that quietly keeps recordings is worse than one that does not listen at all.

It speaks like a person. Answers are shaped for the ear: at most three sentences by default, and sources named the way a person names them, "from the MX-7 manual", not by filename and chunk number. Full citations stay on screen and are one question away: "where's that from?"

Sized to the machine

The user sets two budgets: how much of the machine their own agent may use, and how much a co-op may borrow (zero unless they opt in, and by default only while the machine is idle). The personal budget, capped at 70% of free memory, picks the model tier. On Apple Silicon unified memory makes the memory budget the GPU budget; on NVIDIA machines the engine offloads as many layers as fit in video memory.

Effective budgetModel tierWeights + cache
13.5 GB or moreQwen3 14B~10.5 GB
8 GB or moreQwen3 8B~6.2 GB
5 GB or moreQwen3 4B~3.3 GB
under 5 GBQwen3 1.7B~1.6 GB

The engine always reports what is actually running, read from the model server itself, never what it intended to start.

Layer 1

The co-op

A co-op is a real community, a clinic network, a trade association, a campus lab, whose machines act as one specialist agent. It has three roles:

  • Anchors. One to three always-on, wired machines at one site. They host the large specialist model and the co-op's corpus of record.
  • Members. Members' own laptops, running their own small models, contributing idle compute within the budget each member set.
  • The coordinator. A durable job queue living on an anchor.

Jobs, not weights. A hard question fans out into independent jobs, retrieve, draft a candidate, critique, verify a citation, synthesise, each essentially one stage of the agent's own pipeline run on a member's model. Jobs are restartable and delivered at least once, so a laptop closing its lid just drops its job back on the queue. The anchor runs the heavy generation and the final, authoritative answer.

We do not split one model across the neighbourhood by default, because the arithmetic forbids it. Generating text sends every token's activations across every machine boundary, in order. Over a wired LAN that costs a few milliseconds per token; between homes it costs tens, jittery. And availability multiplies: three nodes at 95% uptime give a pool that is up 86% of the time, ten give 60%, and any node dropping mid-answer loses the whole answer. Task-level parallelism isolates failures and keeps partial results. Sharding a large model remains an experimental mode behind a strict admission gate: one site, wired at 2.5 GbE or better, one trusted owner or invite set on an encrypted mesh, machines pledged always-on, identical software and model hashes.

Typed envelopes. Every message between nodes, a job, a result, a question, an answer, is a typed, signed, provenance-carrying structure. A member's result is consumed as data (candidate text, citations, signature), never spliced into a prompt as free text, so a compromised member cannot prompt-inject the anchor.

Identity. Every node has an Ed25519 key. Enrollment is by invite code, and the co-op's certificate authority on the anchor issues short-lived member certificates. A lost laptop or a departing employee is removed by revocation and an epoch bump that invalidates every older certificate. The anchor's key is also the co-op's public identity, its coop_id, which signs everything the co-op says to the outside. Inside a co-op, members talk to the coordinator over WireGuard with application-level mutual TLS binding each certificate to a role.

The co-op's testA co-op must beat the best single workstation among its members on verified quality, throughput and cost, measured and published. If pooling loses to one good machine, we say so and redesign.

Layer 1 → 0

How a specialist learns

Members hold knowledge no datacenter has. The training loop turns it into a better specialist without ever training on raw private files and without merging anyone's weights.

  1. Donate. A member explicitly contributes curated items: example question-and-answer pairs, preference judgements ("this answer is better than that one"), and evaluation items. Each passes a local PII scan and is shown in the outbound preview before it leaves the device. Consent is versioned and revocable.
  2. Train. The anchor trains one low-rank adapter per specialty (QLoRA) on a frozen, shared base model, on its own GPU. Consented member data is never shipped to an unattested third party.
  3. Grade. Before it may serve, the adapter must show a domain gain outside statistical noise, no regression on general ability, and no leak of planted canary strings.
  4. Return. What flows back to members' devices is a synced adapter, a cache of verified answers, and a router that knows when a question is hard enough to escalate. Your AI knows what the network knows.

An adapter trained on a co-op's donations serves only that co-op's own members. Anything that would cross a co-op boundary, a distillation corpus, a contribution to a shared base, must be trained under differential privacy with a tracked, published privacy budget. Removing a donation deletes it from the corpus and excludes it from all future training; a model already trained on it can only forget it by retraining or rollback, which is exactly why publication is gated behind privacy budgets.

Layer 2

The federation

A co-op is expert at one thing. Federation lets a co-op hand a question outside its specialty to the co-ops that are expert, and combine their answers into one, with disagreement shown rather than averaged away.

Layer 2Federation. Routing to the top specialist co-ops, signed answers, disagreement-preserving synthesis, bilateral credits, one reputation score.
Layer 1Co-op. Anchors host the specialist; members run churn-tolerant jobs; donations train one adapter per specialty.
Layer 0Your agent. Local engine, synced adapter, verified-answer cache. Escalates only through the PII gate and your approval.
Figure 2. Three layers. Each is useful alone; each escalates to the next only when it must.

Capability profiles. Each co-op publishes a profile signed by its coop_id: the domains it covers with their embeddings, a jurisdiction tag, capacity and latency hints. Profiles spread by gossip over iroh (QUIC with TLS 1.3, authenticated by node key), so every co-op holds a local directory. A profile is accepted only if its co-op is on a steward-signed membership list, its own signature verifies, and it is newer than the copy already held. Self-reported numbers are hints for breaking ties, never routing inputs on their own, because they are gameable.

Routing. The router is a pure function. It embeds the question, scores each co-op by the similarity between the question and the co-op's domains, weighted by that co-op's observed reputation, and picks the top few. A small exploration rate, about 5%, gives newcomers a chance to earn a record.

The question travels, never the model. Each chosen specialist answers independently on its own hardware and returns a signed answer envelope. Adapters and weights never leave the co-op that trained them.

Synthesis that keeps the argument. The asking co-op clusters the answers, detects contradictions, and produces one typed result tagged with provenance: where the specialists agreed, where they did not, and who said what. Hiding a contradiction between two specialists is the failure that would make the network worse than one honest model, so the synthesis is required to preserve it. A safety check runs on each answer and again on the result.

One plain rule. Anything a user approves for sending is seen by the co-ops that answer it; federation is not zero-knowledge. So before anything leaves, a local PII gate flags names and identifiers, and the outbound preview shows the exact envelope. The user can strip, generalise, or not send. Truly private work never needs to leave the agent.

Depth over speed. A federated answer may take minutes, not milliseconds. That is the product: the best answer the network can produce, checked, argued, and signed. The network also remembers every verified answer, so the second asking is fast.

Accounting

Credits, not coins

When one co-op answers another's question, that is work, and it should be recorded so no co-op is a permanent donor or a permanent freeloader. The ledger is deliberately not a currency. It works the way internet providers settle peering: two neighbours keeping an IOU notebook.

  • Bilateral. Each co-op keeps a separate, append-only, hash-chained balance with each specific peer. There is no global ledger, no chain, no consensus, no pool, no issuer.
  • Dual-signed. Every entry names the job, its query class and its price, and is signed by both parties. Neither side can invent a balance the other did not agree to, and presenting different histories to different peers produces a signed proof of fraud.
  • In kind. Priced in stable compute-minutes per class of question, never in dollars or per token. Credits are use-only, non-transferable and expiring, and cannot be sold or converted into anything tradable.
  • Enforced by standing. A co-op that cheats or refuses to settle loses reputation; peers stop routing it work and refuse to serve it past its credit line. The penalty bites because identity is costly: a steward invite to join, and attestation by several established co-ops plus an aged record to earn, all forfeited on proven fraud.

Contributions that are not answering questions, donating training data, authoring evaluations, earn reputation and routing priority, never minted credits. That keeps "nothing is minted" literally true.

Trust

Verification and reputation

"Nothing is earned but verified work" needs machinery that decides whose contribution was real. The whole network reads one reputation score per co-op, with one owner and three feeders: grading and spot-check pass rates, settlement behaviour from the ledger, and user acceptance and latency from federation. The score decays over time and is forfeited on fraud. The router uses it as its weight; the ledger uses it to decide who may earn.

  • Query-access grading. A quorum of two or three other co-ops, never the candidate itself or its sponsors, sends held-out prompts to a dedicated grading endpoint and scores the raw output. The adapter never leaves; only prompts go in and answers come out.
  • Single-use evaluations. Held-out items and canaries are authored by the steward and used once, because a secret benchmark burns the moment an untrusted verifier sees it.
  • No gain inside the noise. A co-op's reputation rises only for improvements that clear statistical significance.
  • Gates beside the benchmark. Safety, general-regression and backdoor checks run independently of the domain score, since a benchmark delta cannot see a targeted backdoor.
  • Property-based spot checks. Because different quantisations never match token for token, inference is spot-checked for properties (cites real sources, refuses where it should) rather than exact output.
  • Canary rollout, shared rollback. New base releases go to a volunteer group first, and rollback needs only several of many independent key holders. Shipping unreviewable weights to everyone at once would be a kill switch too.

In the first federation of roughly ten hand-recruited co-ops that already know one another, these mechanisms lean on social accountability as well as cryptography. Making the same guarantees hold between strangers at open scale, without a token, is research we will do in the open, and it is a condition for any reward attaching to anything.

For the reviewer

Security model

The claim is narrow and checkable: Sturnia answers from the user's own documents, locally, and nothing leaves the machine unless the user chose it, by a route that is named, enforced, counted and visible.

  • A token on every local request. The engine mints a fresh secret at each start, writes it to an owner-only file, and rejects any API request without it before a handler runs. Another program on the same computer cannot read the user's documents over loopback.
  • Locked origins. Cross-origin requests are allowed only from the desktop shell, and DNS-rebinding attempts are refused at the Host header.
  • Egress refused and counted, as described in Local by construction, and provable at the operating-system level.
  • Keys in the Keychain. Cloud provider keys, if the user adds any, live in the operating system's keychain, never in a plaintext file, a log or an error message.
  • A stoppable engine. The engine owns its model servers and stops them on shutdown, refuses to start beside a running copy, and can sweep orphans. You should never have to audit your own microphone with a process list.
  • Typed messages between machines. Across co-ops and within them, only signed, structured envelopes; no free text from one node reaches another node's model as instructions.

Method

Measured, not claimed

Each layer ends in a gate: a test that must pass, measured and published, before the next layer is built on it. Some are tests in the code: the voice-latency budget and the local-only proof fail the build and are never relaxed to let a change through. Others are tests in the world: a co-op beating its best single machine; a federated answer beating any one co-op's; a reward scheme surviving public, bountied attack before any reward attaches to anything.

The professional gate is held to the strictest standard. Whether Sturnia does real work for clinicians is judged against tasks that real practitioners actually needed done, over public or synthetic documents, never patient data, with two-person review in which no author scores their own runs. A model must not write those tasks. A model-written test would be fast, look excellent, and measure only that the system agrees with itself.

The plan, gate by gate, is in the manifesto's roadmap.

Reference

Glossary

Agent
The Sturnia engine running on one person's machine. Layer 0.
Anchor
An always-on, wired machine that hosts a co-op's specialist model and its corpus of record.
Co-op
A real community whose machines act as one specialist. Layer 1.
coop_id
A co-op's single Ed25519 identity key. It signs the co-op's profile, its answers and its ledger entries.
Federation
Co-ops that route questions to each other and combine the answers. Layer 2.
Envelope
A typed, signed message between nodes. Never free text handed to a model.
netguard
The engine's egress guard. It replaces socket.connect and refuses every non-loopback address unless a person asked for the connection.
Permit
A thread-scoped, reason-carrying exception to netguard, counted apart from ordinary traffic.
Steward
The convening foundation or team. It authors held-out evaluations and holds a share of the rollback keys.

Your agent alone is useful. Your co-op makes it an expert. The federation makes it wise. And at every step, your data stays home.