The Operating System

The Agentic Operating System — Software Around the Processor

This section is the quick read of the whole thing; every piece below goes deeper. The one idea underneath all of it: the LLM is a processor, and from a single chat all the way up to a complex fleet of harnesses, it is always the same processor. Our work is to standardize the pieces that come together around it — context, skills, tools, and the harness — so we can assemble the right thing for the right agent, on the right surface, at the right time, with persistent data, skills, rules, and context wrapped around everything. The buckets are ours and the processor is swappable, so as the models get better our whole operation gets better without a rewrite.

None of these is the product on its own. Coordinated — the spine feeding the skills, the skills composing into agents, the agents running in harnesses, and the shared context continually refined beneath them — they stop being tools and become a system that gets better every time it runs.

LLM as Processor — the Core of Everything

This is the core of everything above — and there is only one idea to hold: the LLM is one processor, and it never changes. What changes is who drives it. First you do, by hand, adding more context and more tools as you climb the altitudes. Then the real unlock: you take the same pieces you built — context, skills, tools — and stand them up in a harness so the processor runs without you, always on. That single shift, from a person operating it to a system operating it, is what turns a chat into an agent.

Where you engage it — the human-operated altitudes (1–6)

Every altitude here is a person operating the processor. When you open ChatGPT or Claude you are already using it — inside a chat someone else built for you. Climbing is nothing more exotic than adding context and tools: you can chat with it, connect it to your data, automate it, code with it, and build whole systems and interfaces on it. Same discipline the whole way up — only the size of the context and the reach of the tools grow.

How it runs without you — standing up always-on agents

This is the real power. Take the same well-designed pieces you just built and wrap them in a harness, and the processor executes on a trigger, a schedule, or an event — no one typing. Standing them up so they are always on is the whole game. There are three basic shapes, simplest first — a "real agent" is not better than a one-shot, just more expensive and less predictable, so use the simplest one that closes the task. Think of these as the primer; §6 builds them for real (the eight-slot anatomy + the harness menu).

The Modular Contextual Spine — the System's Shared Context

Now that the processor is established, this is the other key element: the software we build around it is the spine — the durable, shared context every level of the build reads from. It holds who we are, how we look, what we say, who we sell to, and how the system actually runs, and everything after this section (skills, tools, agents) resolves its context here. It lives in two places: author and refine in git, serve structured in SQL — two substrates, each good at different things. (This is context, not memory — memory is a separate, emerging layer covered in §7.)

The two halves of the spine

Commercial context — resolved once, used everywhere

The system, instantiated — process traces & data

The spine is not only documents; it is the lineage of how a record moves through the system. These are the shipped end-to-end traces.

Skills — the Composition Ladder

Capabilities compose upward: atom → bundle → workflow → agent → fleet. These are counted registry facts, not metaphors. Every skill carries its own classification in front-matter per the classification standard.

Tools — the Fourth Piece

A skill says how. A tool is what it acts on: an external surface with an API, a credential, and usually a bill. Until 2026-08-03 there was no tool registry at all — the field existed on the skill schema and was empty on every skill.

Tech stack & infrastructure — where an agent lives

A tool is an external surface; the stack is where our own agents run, are hosted, and hold a domain. Everything above plugs into this fabric.

Harnesses & the Fleet

Once you know the context, skill, tools, and shape, the harness is the environment that runs it: process model, state, retries, credentials, observability, cost profile. We keep a build-agnostic menu — patterns you can build on, never BC's own products.

The anatomy of one agent

Every agent is the same processor with eight engineered slots filled in around it — context, skills, tools, and memory from §1, plus shape, breakers, trigger, and eval — all inside a harness (the frame) that runs it and writes back to the spine. Build one by picking the shape, then filling the slots. A fleet is many of these, coordinated.

Retrieval & Graph — the Honest State

This is the least-built part of the methodology and is described as such. The 2026 consensus is that retrieval is a three-stage pipeline — retrieve (BM25 + dense) → fuse (RRF) → rerank. BioCreative currently runs none of it.

Memory — the emerging write-back layer

Retrieval and the spine (§3) are the read path — what the system knows. Memory is the write-back path, and it belongs here, not in the spine. As the fleet operates it produces learning events — corrected facts, resolved entities, outcomes, new skills — that should periodically roll back up to update the graph and, eventually, rewrite context at the top. This is distinct from git/backend refinement (the primary path today): memory is the agentic second path, and it is the least-built idea on this page.

UX & Operator Surfaces — the Eyes

Everything above is the machinery: data organized, software written, agents built, context stored, work executed. None of it is operational until a human can see it and steer it without living in a terminal. That layer is the UX — the Eyes of the four-part system introduced in section 2. It is where the whole build stops being infrastructure and becomes something a non-engineer runs.

The operator surfaces we run