What we know how to do, what we instrument so that you have numbers of your own, and the point at which each approach stops working. None of these pages contains a result, because a capability is a statement about method rather than a claim about a client.
C1
Getting the right passages in front of the model. Most quality problems that look like reasoning problems are retrieval problems.
7 practices · 3 limitsC2
A labelled set, a threshold agreed in writing, and a gate in CI. Built before the feature, not after the first complaint.
8 practices · 3 limitsC3
Explicit state, typed tools, bounded loops and a replayable trace. An agent is a distributed system, so we build it like one.
8 practices · 3 limitsC4
What the system may do alone, what it must hand to a person, and what the person receives when it does.
8 practices · 3 limitsC5
Quality, latency and cost per task on a dashboard your team owns, with an alert when any of the three moves.
8 practices · 3 limitsC6
The application around the model: interface, data model, auth, pipelines, infrastructure as code and a deployment your team can run.
8 practices · 3 limitsengineering / how they fit together
Read left to right, the diagram is the six capabilities in the order they appear in a build. Retrieval and context feed the orchestrator, guardrails sit on the output path, and evaluation, observability and cost run underneath the whole thing rather than beside it.
Good. That conversation is more useful than a capability deck, and it is roughly what the first call sounds like.