products

— what we build, and what's open.

All of it runs in our own work before it is offered to anyone: lucas looks after our cluster, rouse is the memory our own agent runs on, multirun is how we measure the rest. Three are public and you can read them today. Two are still being built.

agents

darling

in development

A general agent: customizable persona, logically-grouped actions, and a codebase small enough to read in an evening. Includes a traces dashboard. Not public yet.

lucas

github.com/a2wio/lucas — open source, MIT

A Kubernetes reliability agent that runs inside the cluster it looks after. It reads pods, events and logs, investigates from Slack with the thread as its context, and scans the namespaces you give it on a schedule.

What it may do is a mode, not a sentence in a prompt: watcher reports and changes nothing, autonomous can remediate. The real boundary underneath that is RBAC — it reaches exactly what its service account reaches, and no further. It works best beside GitOps, where a change it makes is a change you can see.

Runs, sessions and token usage go to a small dashboard of its own.

agent internals

rouse

a2w.io/rouse, github.com/a2wio/rouse — open source, MIT

Memory with a clock. Most agent memory is recall: the agent asks, the store answers, and if it never asks, the memory never happened. Rouse adds the other direction — a file can come find the model, because it came due or because it stopped moving and somebody was promised it wouldn't.

It is a set of conventions for files on disk, plain markdown with a small frontmatter header, plus one sweeper and two seams per agent. Claude Code, Codex, Cursor, a cron job with curl: if it can read a file at startup and be started by something, it can be roused.

tools for agents

innkeeper

in development

A web authentication proxy for agents — the piece that stands between an agent and the sites it has to be logged into. Not public yet.

evals (testing)

multirun

github.com/a2wio/multirun — open source, MIT

Point it at a source — a repo at a commit — give it a task, and it fans out N isolated runs of a coding agent. Each run gets its own git worktree and its own Neon database branch, and what each one did is captured and compared side by side.

The branch per run is the point: all N runs start from byte-identical database state, so diffing each branch back against the parent tells you what the agent actually did to the data, instead of reading N transcripts. The orchestrator spawns a Kubernetes job per run and reaps it, the run history lands in Postgres and stays queryable in SQL, and a read-only dashboard reads that history and the artifacts beside it.

none of this comes with a support contract. if you want one of them run for you, or your own agents looked at, use this link [book] and we'll take a call