How we think about agent societies.
The thesis underneath everything we build: many small agents, each modelling the others, held to a number they have to prove.
Agent societies
We do not ask one large model to do everything. We split the work into many small, specialised agents, give each one a narrow job it can be judged on, and write the coordination between them down explicitly — who calls whom, with what, and what counts as a good answer.
Decomposition is not an aesthetic preference. A narrow agent can be tested in isolation, so a failure points at one component instead of a prompt. Coordination that lives in code can be read, versioned and replayed. And most steps do not need the largest model, so the same work costs less to run.
Measured, or it did not happen
Capability is cheap. A demo that works once tells you almost nothing about a system that has to work on Tuesday afternoon with real inputs. The eval is part of the deliverable, not phase two.
Every system we build names one number it is meant to move, and ships with the golden set, the scoring run and the regression alert that watch that number. If we cannot measure it, we say so on the way in rather than after the invoice.
What we are working out in public.
Notes from the build, written by the engineer doing the building.
Tell us the number you want to move.
A free 20-minute problem call. You talk to the engineer, not a salesperson — and leave with a scoped problem, the metric we'd move, and a real plan, whether you hire us or not.