How we run

How we run a company on agents.

We are a small lab, and agents do most of our work. This page is the operating model behind that: what each job looks like in our week, who holds the gates, what happens when a model is down, and how a change gets from an issue to main. It runs on the same engine you can install.

01 · The operating model

Nine jobs, every day.

Every worker, person or agent, senses, thinks, remembers, makes and speaks. A company also has to connect them, run the machines, guard the doors and steer. Here is what each job looks like for us.

  1. 01Sense

    Hear, see, and notice first.

    We talk more than we type. Dictation goes to Voice on a GPU box we own, and its vocabulary knows our own words, so names come out right.

  2. 02Think

    Agents that reason with you and answer to you.

    Agents work in Core terminals beside us, each with a task, a log and a way to ask for help. They reason on the model chain below; open models run on our own boxes with Computer.

  3. 03Remember

    Nothing learned is lost.

    Research, notes and every repository we read go to the Library, so an agent starts from what we already know. Notes are plain Markdown files that people and agents both write.

  4. 04Make

    From issue to shipped, with a review at every gate.

    Code ships through the Factory. An agent builds each change from an issue, checks and a second agent review it, and a person merges. The gates are below.

  5. 05Speak

    Say it once and it reaches everyone.

    Agents draft what we say: release notes, posts, this website. Speak reads finished work aloud, so a long result can be heard instead of read.

  6. 06Connect

    Every person and every agent, one reach away.

    Agents sort and draft our mail; only a person sends. Anything waiting for a person shows up on the phone through Mobile.

  7. 07Run

    On machines you own, always on.

    Everything runs on a handful of Ubuntu machines we own: laptops, workstations and GPU boxes. Core runs on each one, and one list shows every terminal on every machine.

  8. 08Guard

    Find the hole before anyone else does.

    Internal services answer only on our private network. Keys live in a secrets store, never in a repository. Watchdogs restart what stops, and a serious alert reaches a person.

    • Built into every part
  9. 09Steer

    You see the whole day, and nothing important ships without you.

    An hourly work log records what every agent did, and one queue holds what waits for a person. Nothing important ships without one.

    • Built into every part

02 · The approve gate

Agents read, draft and build. A person sends, merges, and does anything that can’t be undone.

This is the one rule every part follows. Where we can, it is enforced in code rather than asked for in a prompt.

Mail

The mail daemon refuses a send from any connection that has not shown the person token, whatever the caller claims. The agents’ command-line client has no send command at all.

Lumbridge Mail

Code

Builder agents hold no code-host token. Their git key can push only factory branches, and merging to main is a person’s button.

Lumbridge Factory

Anything irreversible

Spending money, deleting data and changing who has access wait for a person. An agent that needs one of those says so in its terminal and stops.

Lumbridge TUI

Budgets

Every factory ticket has a token budget and a wall-clock budget. Reaching one asks a person; it does not kill the work.

Lumbridge Factory

03 · When a model is down

Three models deep.

Every part calls an OpenAI-compatible endpoint, so the model behind it is a setting, not a rewrite. Our agents fall back in a fixed order.

  1. 01

    A frontier model

    The first choice for hard work: a hosted frontier model, called through its API.

  2. 02

    Our own boxes

    If it is down or out of capacity, open models on GPU boxes we own, served and watched by Lumbridge Computer.

  3. 03

    Another hosted model

    If those are busy too, a model hosted by a different provider. Slower work beats no work.

Lumbridge 1 is a separate thing: a hosted model you call by the token. Point any part at it, at your own boxes, or at both.

04 · The factory gates

From issue to main, with a person last.

This is the line our repositories run on. A new commit starts the gates again, and whoever wrote a change, a person merges it.

  1. 01

    Ask

    A person on the allowed list labels an issue. Anyone else’s text is recorded and never acted on.

  2. 02

    Build

    A builder agent works in a sandbox on its own branch, as its own unix user, behind a default-deny network.

  3. 03

    Checks

    Every required check is green on the exact commit.

  4. 04

    Review

    A separate reviewer session reads that same commit. After three rounds of findings it stops and asks a person.

  5. 05

    Current main

    The branch contains today’s main, so what passed is what lands.

  6. 06

    Merge

    A person merges. Agents never do.

How the Factory works

Straight answers

What people ask us.

Is all of this open source?

The engine is: twelve parts under Apache-2.0. Our prompts, review policies, evals and the instances we run are not. They are how we work, and we can set up yours.

Do agents ever act without a person?

All day, inside the gate. They read, sort, draft, build, test and review without asking. They stop at sending, merging and anything that can’t be undone.

Do we need GPU boxes?

No. The engine runs on ordinary Ubuntu machines. Point it at Lumbridge 1 or any hosted endpoint; add your own boxes later if you want open models in-house.

How big is your team?

Small. Agents do most of the work, and you talk to the engineers who wrote the code.

Run your company this way.

We install the engine on your machines, get your first agents running, and stay accountable for it.