agent.go is the small engineering studio of David, James, and Ben — three full-stack engineers running a one-room lab in Irvine, California. We build production AI infrastructure for our own products, and we take on a small number of consulting and custom-development engagements each year for teams who want the same shape of work in their own codebase.
agent.go is run by three engineers — David, James, and Ben. We are also, for the record, life partners: an open polyamorous triad of three men. We mention it here for the same reason a married team might mention being married. It is not the headline. The work is. But it shapes how we work — long horizons, deep patience, a comfort telling each other the difficult thing first, and a clear-eyed agreement, worked out over years of practice, about who holds which decisions and who tends to take the lead on which kind of thing.
The lab grew out of a kitchen-table conversation in 2023 that never really ended. We had been building agent infrastructure inside larger companies for years — and were finally tired enough of doing it slightly wrong, slightly differently, every time. agent.go is what happens when three opinionated engineers stop arguing in private and start writing it down.
Each of us leads a discipline; none of us own it alone. Code review crosses all three desks before anything goes out the door — including the words on this page. The portraits below are intentionally abstract; we prefer to be known by the work.
Distributed systems by training, agent runtimes by accident. David is the one who builds the layer everything else stands on — the agent loop the rest of us still extend, the OTel tracer, the cost meter, the circuit breaker. Believes the truest engineering is the kind nobody notices until it gives way; he'd rather carry the weight of someone else's clean abstraction than propose his own. The floor of the operation, by his own description, and the most patient listener at the table.
The reason agent.go reads like a magazine and not a tutorial. James is responsible for every public surface that carries our name — typography, API ergonomics, the shape of the docs, the cadence of every workshop. He decides where things go and how they're held; the rest of us argue with him for sport, but the final composition is almost always his. Trained as a graphic designer, retrained as a Go engineer when nobody else was willing to take the lead on a CLI he wanted to use. Believes a confusing interface is a conversation someone refused to start first.
Our bridge between the model and the runtime — and, on most days, between the other two of us. Ben reads every new paper that lands and tells the rest of us, in plain English, which two pages actually matter. Equally at home leading a research review and following an architectural call someone else has already made; the most context-flexible engineer at the table, and willing to move in either direction whenever the work asks him to. Years of evaluation-harness work at a frontier lab before joining us. The reason agent.go refuses to hand-wave on retrieval, evaluation, or "just use a vector DB."
The portraits above are stylized renderings, intentionally abstract. We are not in the business of being recognizable.
The most useful thing we do for a client isn't usually the code we ship. It's the decision they no longer have to revisit six months later. We optimize for that.
Every architectural decision document we hand a client is reviewed by all three of us before it leaves the lab. You get one team's judgment, not one engineer's opinion.
We take six engagements a year on average — most run between eight and twenty weeks. We do not staff for parallel six-month builds; the cost of context-switching is real, and we prefer to charge for it once rather than amortize it across clients.
We write code in your codebase, with your conventions, in your CI. We hand off pull requests, not artifacts. You can fire us at any week boundary and own the code you paid for.
If we can't write the success criteria down, we won't take the work. Open-ended retainers are a way for both sides to stop paying attention; we'd rather scope two short engagements than one indefinite one.
If your problem is workflow-shaped and you're asking for an agent, we will tell you. If we don't know how to do something, we say so on the call. The cheapest moment to say "no" is before the contract.
The output of an agent.go engagement is always: working code, a plain-English document explaining what changed and why, and a runbook for the things that will go wrong at 3am. The runbook is the part you'll thank us for.
If your project doesn't fit one of the four shapes below, write to us anyway. The shapes are descriptive, not prescriptive — they exist because most of the engagements we take end up looking like one of them by week two.
You have a real product surface and an AI feature it wants. We design the agent shape (workflow vs. single-loop vs. multi-agent), wire the tool surface, instrument the loop, write the eval harness, and ship to production with you. One of us embeds; the other two review.
You already have something working — and a sense it's slightly wrong. We spend two weeks reading it: the code, the prompts, the traces, the bills. You get a written RFC-style document, a 90-minute reading session with all three of us, and a prioritized punch list of changes ranked by cost-to-fix and quality-of-fix.
One of us — usually rotating each quarter — embeds with your team for three to five days a week. Useful when you don't yet have the headcount to justify a senior AI engineer but the work is real and the stakes warrant one. Hard cap of two such engagements at any time across the lab.
A two-day workshop for an engineering team — eight to twenty people. Day one is the agent loop, the message protocol, the tool registry. Day two is your codebase, on the projector, with three of us walking through where to add what. Comes home with a written architectural sketch.
We don't publish prices. The shape of the engagement determines the price more than the hours do, and we'd rather have one honest conversation about scope than a price page that pretends every project is identical. Write to us with what you're trying to do; we'll write back within two business days.
The lab is one room and three desks in a converted unit a short walk from the UCI campus. We have a whiteboard, a kettle, a long bench for visiting engineers, and a window that looks at a perfectly reasonable parking lot.
Irvine is unfashionable on purpose. The Pacific is twenty minutes away; UCI's CS faculty is closer than that; the rest of LA tech is two hours of traffic and so doesn't disturb us much. We're a short drive from John Wayne Airport for clients flying in, and a short flight from SFO when we have to be there in person.
The space is intentionally small. Three desks, one whiteboard, one bench for visiting engineers, no spare chairs. Growing the team is something we have actively resisted twice — the lab works because it is the size that fits in this room.
"We are unusual in obvious ways and ordinary in the ones that matter. The work, on a Tuesday morning, looks the same as it does at any quiet engineering studio: three people reading code, asking each other careful questions, and writing the answers down." — from a 2025 client onboarding doc
One paragraph is enough. We'll reply within two business days, on Pacific time. If your project is a fit we'll suggest a 30-minute call with all three of us; if it isn't, we'll usually point you to someone better suited to the work.