The public projects
An operating layer for specialized local AI agents.
active · flagship One small resident model, many specialists — each an adapter, a library of notes it has learned to navigate, and its own scoped tools — and a router that abstains to a frontier model for whatever falls outside every specialist’s ground. Numbers on this page are checked nightly.
Version control for live-patched agent systems.
revived — validation in progress Change your harness while it runs and still know what worked: every step stamped with the harness version that produced it. Being rebuilt as a Rust core (v0.1, in progress); its merge draft (v0.2) hands each real conflict between two harness manifests to an agent and checks the resolution.
Auditable evidence for gene predictions the reference annotation does not have.
prototype · stage 1 For each predicted protein-coding gene missing from the reference, it gathers the evidence a biologist would collect by hand into an evidence graph, and writes a report in which every sentence cites the graph nodes it rests on. No language model in this stage. It explains candidates; it does not pick which to validate first. Repository; how it relates to the two projects above is below.
ai-os subtree (last changed 2026-09-06), a frozen copy of
agentvcs, the memory package, the robot demo and the 2025 toolkit, kept readable.Twenty-five more repositories are archived and read-only — each is listed, with where it moved if it moved, in the archive.
The flagship · lora-kernel · Apache 2.0
One GPU, one small resident model, and a shelf of QLoRA adapters — each an expert defined by its corpus. An OpenAI-compatible API reads every request, serves it with the expert whose corpus it falls in, and sends everything else to a frontier model. The client names no model.
Version 1.0 adds what a small expert cannot hold in its weights: a library of short notes per subdomain, and an adapter trained on the habit of navigating it. The weights hold the navigation; the notes hold the content, and a person can read, diff and correct them.
Read the architecture article → En español The memory Repository
The finding that reorganised the project
Same adapter, same cases. Only the serving path changed.
A fluid-mechanics expert — 6-to-9-step chains with a calculator and a
per-case handbook — scored 11/90 when tool results came back as
tool_calls messages. Written inline, the way its corpus taught it to read them,
it scores 90/90 (79 : 0, paired). For four days that gap had been read as
“small models cannot reason”.
Tool block, argument order, system prompt, result format.
Under a foreign system prompt 2 of 32 live turns call a tool; under its own, 19 of 32. Serve an expert the way its corpus taught it, and suspect the path before the model.
Same corpora, same recipe, a new base.
Both released members were retrained on Qwen3.5-4B and each
ties its own earlier release: inbox triage 471/475, desk commitments
240/240. They have since moved again: every released member is now on Gemma 4 E4B,
and the Qwen releases stay as the control arm.
What deliberately never becomes a weight?
The library. A weight delta cannot be read, cited or corrected by a person; a half-page note can. Site rules override the textbook before the expert ever sees the note.
The core of version 1.0
search, open, calc —
with results written inline. A software referee turns the pages, applies the site's rules
and cuts a walk that skips a required step.built — measured in part All five parts are built. Libraries now exist over an open textbook’s procedures (CC BY 4.0) and over US regulations ingested verbatim. On real documents the central claim holds where it was measured: an expert trained on walks over one regulation family cites on a family it never saw, and a number edited in the library after training is answered from the edit (below). On generated procedures it did not: the library arm did not beat the untrained base handed the same notes.
What is measured
| what | the number | run |
|---|---|---|
| A reasoning expert served the way its corpus taught | 90/90 against 11/90 through tool_calls, 79 : 0 paired | M7 arm 0b |
Inbox triage, retrained on Qwen3.5-4B |
471/475, a tie with its earlier release; the bare base scores 346/475 | M1 |
| A second expert on the same inbox, a different question | 240/240, a tie with its earlier release | M1 |
| The API routes per request; the client names no model | 0.546 → 0.775 on a 240-case replay, 0 misrouted | P41, P62 |
| A procedure merely pasted into a 3B’s prompt is not followed | 0 tool calls on 351/351; the trained expert beats it 137 : 1 | P61 |
| Trained on walks over real regulations, an expert cites on a regulation family it never saw | 18/23 against the untrained base’s 9/23, 10 : 1 paired; a second seed ties it | REAL3 |
| A number edited in the library after training is answered from the edit, not the weights | 17/17 rows answer the new value, each cited to the edited statement, 0 stale | EDIT0 |
| The router that replaced the keyword dictionary as the default: a request is factored into its task and its content | foreign text served locally 0/600 against the dictionary’s 294/600; unseen senders 0 of 120 lost | ROUTE0 |
What is not, or does not work
The full ledger, including everything that failed and the instruments that lied: RECORD.md. The position: PLAN.md.
Where it sits in an organisation
Under the agent column, not beside it.
An organisation that runs on agents draws the same picture: people in a few roles, an agent runtime with one agent per role, the applications they operate, the channels people already use, and one database underneath. In that picture every agent is a system prompt over the same remote model. Here each role becomes an expert — an adapter trained on how this organisation does that job — and the role a message arrives from is the route.
Records, habits, knowledge.
Records stay in the database. Habits go in the adapter. Knowledge stays in notes a person can read and correct — two drawers per role: how we do it here, and what we know. What an expert is measured to handle is answered on the organisation’s own machine; the rest goes to the frontier, or to a person where policy says nothing leaves the building.
| organisation | roles that become experts | what goes in the two drawers |
|---|---|---|
| a distributor | customer service, receiving, dispatch, purchasing, claims | the site’s handling procedures · catalogue, carriers, service levels |
| an accounting or law office | intake, document review, deadlines, billing | the firm’s checklists and templates · the rules of its jurisdiction |
| a school or training centre | enrolment, teaching support, communications, purchasing | how this school handles each case · programme, calendar, regulations |
| a repair or field-service company | equipment intake, diagnosis, spare parts, warranties | the procedure for each kind of repair · manuals, parts lists, warranty terms |
| a club or community centre | memberships, activity sign-ups, facilities, collections | how this club handles each case · activities, fees, house rules |
| a property manager | tenant requests, maintenance, collections, suppliers | the escalation procedure per building · contracts, by-laws, supplier terms |
not measured These are where the design points, not results. What they share is what makes a region worth an expert: the same few procedures, repeated daily, with local rules that differ from the textbook, over data that should not leave. The first library in the repository is built from an open textbook’s step-by-step procedures.
For a team running agents together
The second project · agentvcs · Apache 2.0
Version control for live-patched agent systems: change your harness while it runs and still know what worked.
revived — validation in progress Every step of a long multi-model run is stamped with the exact harness version that produced it — prompts, models, sampling, tools, adapters, router — so a patch applied while the system runs can be gated, attributed, rolled back, or resumed from a checkpoint instead of re-running from the start. It was frozen in 2026 and is active again.
The newest project · gene-evidence · Apache 2.0
Auditable evidence for gene predictions that the reference annotation does not have.
prototype · stage 1 Carbon-A, a public set of
gene predictions, covers thousands of GenBank assemblies, and some of its predicted genes are absent
from the species’ reference annotation (NCBI RefSeq). Each is either a gene the reference missed
or a prediction artefact. For each one, gene-evidence analyze collects what the reference
annotates at the locus, a retrocopy signature, Swiss-Prot homology, Pfam domains, ORF sanity and
optional RNA evidence into an evidence graph: every node is one tool output with its tool,
version, database hash, parameters and raw values. The report cites graph nodes in every sentence,
and check-report fails if one does not. There is no language model and no learned
model in this stage; the rules are fixed and written down in
EVIDENCE.md.
Why locus context is read before homology.
A processed pseudogene is a copy of a spliced mRNA inserted back into the genome: no introns, nearly identical to its parent, often with a reading frame intact enough for a predictor to call it a gene. On those loci a near-identical homolog and the parent’s domains point the wrong way. So a pseudogene at the locus or a retrocopy signature puts a candidate last, whatever the evidence for it says. On the rat development run, 578 of 947 candidates (61 %) sit on loci the reference already calls pseudogenes.
A development run on rat, not a test of ranking quality.
947 candidates analysed. Two independent runs gave byte-identical graph and report (determinism.txt), and every sentence passed the citation check (check.txt); 35 unit tests on synthetic fixtures, no network. The top 100 are all tier 1, and reading them found the failure mode written down before the run: repeat-rich families fill them — 32 hit the Smok kinase family, 24 T-cell receptor or immunoglobulin variable segments, and 2 retroviral Pol polyproteins, rank 1 among them. The tier rule was not changed after seeing it.
checked nightly Each of these numbers is read from the run’s committed files by the same check as lora-kernel’s.
Use the report to explain a candidate, not to choose which to validate first.
Checked against independent long-read transcript evidence on plant genomes, the fixed tier ordering ranked supported candidates better than chance but worse than the gene predictor’s own confidence score, and demoting candidates on their evidence against did not improve the top of that ordering. The tiers are a reading aid, not a prediction.
Nor does the project claim that tier 1 is enriched for real genes, that a candidate ranked last is not a gene — retrocopies can be expressed, and pseudogene calls can be wrong — or that “no Swiss-Prot hit” means “novel”. Its README says so first.
How the three connect
Not today. It is the first real-data case lora-kernel is meant for.
next — not built gene-evidence runs no
model and does not use lora-kernel. What the two share is one rule: a statement that does not cite
its source does not ship. In gene-evidence, check-report fails any sentence whose
citation does not resolve to a node of the evidence graph. In lora-kernel, the served endpoint
withholds an answer whose citation fails the referee’s check. The plan is a next stage in
which a lora-kernel expert reads the evidence graph and drafts or critiques the report, with
gene-evidence’s checker gating every sentence it writes. Nothing of that stage is built or
measured.
With lora-kernel, yes, today. With gene-evidence, only as a plan.
built agentvcs’s lora-kernel example reads
lora-kernel’s serving configuration into a harness manifest and turns measured configuration
changes into gated patches, so blame attributes each change in a metric to the patch
that brought it.
next — not built gene-evidence already records what a run
depends on: tools, versions, database hashes, parameters. The plan is to run each evidence run as
an agentvcs run, so that a new database release or a rule change is a patch, and a change in the
report is traced to the change that caused it.
| connection | status | what it is |
|---|---|---|
| agentvcs ↔ lora-kernel | built | agentvcs’s lora-kernel example
reads a lora-kernel checkout (read only) into a manifest, turns nine measured configuration changes
into gated patches whose numbers come from lora-kernel’s committed results files, and hands a
conflict between two branches to Claude Code through merge resolve. Imported, not live:
nothing is re-run, the two branches are constructed for the demo, and CI runs it on a fixture with a
stand-in for Claude Code. |
| gene-evidence → lora-kernel | next — not built | A lora-kernel expert that reads the evidence graph and drafts or critiques the report, gated by gene-evidence’s own citation checker. It would be lora-kernel’s first real-data case. Today gene-evidence runs no model. |
| gene-evidence → agentvcs | next — not built | Each evidence run as an agentvcs run: inputs, database versions, tool outputs and report under
one manifest, so blame can trace a change in the report to the database release or
rule change that caused it. Today gene-evidence records its versions in its own
versions.json and graph. |
Research Lab · ANFAIA
agentvcs is among the projects that passed the ANFAIA Research Lab. The work it carries there is the one described above: version control for agent systems that are patched while they run.