What we use, and what we reach for first

AI work is Python work — the model clients, the eval harnesses, the data tooling all live there — and a service in a second language means a serialisation boundary through which the interesting types do not survive. FastAPI's request and response models are the same Pydantic classes the pipeline already uses, so the API schema and the OpenAPI document are generated from the code rather than maintained beside it.

One fewer system to operate is usually worth more than the last 10% of recall. The documents, their metadata, the permissions on them and their embeddings stay in one database, so a filtered search is a WHERE clause rather than a two-phase query against two stores that can disagree. Backups, migrations, access control and on-call all stay in a system your team already runs.

Most problems described as agentic are a fixed sequence with one ambiguous decision in the middle. A loop that plans its own steps makes that pipeline non-deterministic everywhere, which turns a testable system into one you can only evaluate statistically — and makes every failure a transcript to read rather than a stack trace. If you can draw the flowchart, build the flowchart.

Without a bar agreed in advance, 'is it good enough' is settled by whoever is most confident in the room, and every prompt change becomes a debate with no evidence. A set of real inputs with expected behaviour turns that into a number that moves. It is also the only way to change a model or a prompt six months later without re-testing by hand.

A migration at the end is where estimates go wrong, and it is also where a dependency on the agency quietly becomes permanent. Building in your accounts means the IAM, the network boundaries and the quota limits are the real ones from the first deploy, so the constraints show up in week one rather than week eleven. You own the IP, the repository and the infrastructure definitions throughout.