Adjoint, in practice.

What the math actually means, and why it's the right name for what we do — between research and product, between a paper and a thing a customer can rely on.

Why we picked the name

When we were naming the lab, we wanted a word that meant something — not a portmanteau, not a vowel-soup, not a synonym for "intelligent." We wanted a word that, if you happened to know what it referred to in mathematics, would tell you exactly how we think about our work.

An adjoint, in category theory, is an operator that moves between two worlds while preserving the structure that matters. It's a way of saying: over here, this object has a counterpart over there, and the counterpart obeys the same rules in its own language. That is, more or less, our day job.

A minute of math

Suppose you have two categories — call them C and D. A pair of functors F : C → D and G : D → C form an adjunction if there is a natural correspondence between morphisms F(c) → d in D and morphisms c → G(d) in C. We write F ⊣ G, and pronounce it "F is left adjoint to G."

That last bit is the part we care about. The adjoint condition is a consistency condition: it says that the round-trip — translate, do something, translate back — doesn't quietly mangle the structure. The categories may look very different from the inside, but the bridge between them respects what each side considers important.

The engineering analogy

Replace "category" with "team," and the picture becomes uncomfortably accurate.

Research teams optimize for one set of constraints: novelty, generality, the cleanest possible setup. Product teams optimize for another: latency budgets, real users, the messiest possible setup. The objects in those two worlds are very different. A paper is not a deploy. A benchmark is not a customer.

Most projects fail not because the research is wrong or the engineering is wrong, but because the translation between them silently loses the thing that mattered. — field note, summer 2025

Our work, most days, is the translation. We take an idea that proved out in a notebook and ask: what's the F that puts it in production? What's the G that pulls the production constraints back so the research can see them? And — the part that's actually hard — are F and G in agreement, or are they secretly two different functions held together with duct tape and a slide deck?

Three places it shows up

We didn't pick the name as a posture. It actually describes the shape of the work.

1. Evaluation as a left adjoint. Production telemetry lives in product-space; eval suites live in research-space. The eval harness is the translator. If it's a real adjoint, a regression in the harness is a regression a customer would feel, and vice versa. If it's not, you'll ship something that passes evals and breaks on Monday.
2. Retrieval as a structural map. Documents live in one space (high-dimensional, dense, opaque). Queries live in another (sparse, ambiguous, intent-laden). The retriever isn't just a search function — it's a claim that those two spaces have a structure-preserving correspondence. Most retrievers fail because they don't.
3. Agents as bidirectional planners. A planner generates actions in tool-space; a critic evaluates them in goal-space. The pair has to be adjoint, or the planner drifts toward what it can do instead of what should be done.

The honest caveat

The math is real, but we don't claim our pipelines are literal adjoint functors. We're not theorem-proving the existence of unit and counit natural transformations on the way to a sprint review. The word is a discipline, not a proof.

What the discipline says, in plain terms: at every joint between two worlds, write down what each side preserves, and check that the joint actually preserves it. That's a tedious habit. It's also, we think, the difference between a research result and a product.

Have a problem at the joint? Write to us.