Production AI Systems
A production AI system is an LLM application with deterministic boundaries: retrieval you can audit, tools with typed contracts, evaluations that gate every deploy, and fallbacks when the model is wrong. Pruning Labs builds these end to end - retrieval pipeline, agent orchestration, evaluation harness, and the operator console your team actually runs it from.
Most AI projects fail at the boundary, not the model
The model is rarely the hard part. The hard part is everything around it: what gets retrieved, what the model is allowed to do with a tool, what happens on a malformed response, and how anyone proves the system is still correct three releases later.
We treat an LLM as one non-deterministic component inside an otherwise deterministic system. Every input is bounded, every tool call is typed, every output that touches money, health, or legal state is validated before it leaves the process.
- Retrieval that cites its source documents, chunk by chunk, so answers are auditable
- Typed tool contracts - the model chooses, the runtime validates and executes
- Evaluation suites run in CI against golden datasets before any prompt change ships
- Explicit fallback paths for low-confidence, timeout, and refusal cases
How we build retrieval
Most RAG failures are ingestion failures. Documents are chunked without regard to structure, embeddings are generated once and never re-scored, and nobody measures recall. We start at the corpus.
We build structure-aware chunking, hybrid search (dense vectors plus lexical BM25 on Postgres), reranking on the top candidates, and a recall benchmark that tells you what percentage of answerable questions actually retrieve their source. If retrieval recall is 62%, no prompt engineering will save the answer quality - you fix retrieval first.
- pgvector on PostgreSQL - one database, transactional consistency, no separate vector store to keep in sync
- Hybrid dense + lexical retrieval with a reranking pass
- Incremental re-indexing on document change, not nightly full rebuilds
- Per-query retrieval telemetry: what was fetched, what was used, what was cited
Agents, where they earn their cost
Multi-agent architectures are oversold. Most workloads are better served by one model with good tools and a state machine around it. We use a supervisor pattern only where the task genuinely branches - research, triage, and multi-system reconciliation.
When we do build agents, the orchestration layer is ordinary software: a durable state machine with retries, idempotency keys, and full replay. If a run fails at step seven, it resumes at step seven.
Evaluation is the deliverable
We hand over an evaluation harness with every AI system, because it is the only thing that lets your team change prompts without fear. Golden datasets, regression thresholds, and a CI gate - the same discipline any other production system gets.
What you get
- Ingestion and retrieval pipeline with measured recall
- Agent or workflow orchestration with durable state
- Evaluation harness plus golden datasets wired into CI
- Operator console for exceptions, overrides, and audit trails
- Cost and latency telemetry per request
- Handover documentation and a working runbook
Typical stack
- Claude
- OpenAI
- PostgreSQL + pgvector
- FastAPI
- Next.js
- Temporal
- Cloudflare Workers
Related work
Medikle
How Pruning Labs built a deterministic dosage engine and multilingual patient assistant for Medikle, cutting intake from a five-step form to a single conversation.
Hireeing
How Pruning Labs built a direct ATS extraction pipeline, deterministic resume matching, and a zero-friction autofill extension for Hireeing's early-career recruitment platform.
Hindi PDF Editor
How Pruning Labs built a privacy-first PDF platform with Devanagari glyph shaping and OCR running entirely in the browser on Rust and WebAssembly - zero bytes uploaded.
Further reading
Retrieval recall is the RAG metric that actually decides quality
Most RAG systems fail at retrieval, not generation. How to measure recall@k on your own corpus, what a passing number looks like, and why prompt engineering cannot fix a retrieval problem.
When not to build an AI agent
Multi-agent architectures are oversold. A practical test for whether a workload needs an agent, a single model with tools, or ordinary deterministic code.
pgvector or a dedicated vector database
When PostgreSQL with pgvector is the right default for RAG, what actually breaks at scale, and the specific signals that justify moving to a dedicated vector store.
Questions we get asked
How long does a production AI system take to build?
A scoped first release typically ships in six to ten weeks: two weeks on corpus and retrieval, three to five on the system and interface, and the remainder on evaluation, hardening, and handover. Discovery-only engagements run two weeks.
Do you use pgvector or a dedicated vector database?
pgvector by default. For corpora under roughly ten million chunks it is fast enough, it keeps your embeddings transactionally consistent with your source rows, and it removes an entire class of sync bugs. We move to a dedicated store only when measured latency demands it.
How do you prevent hallucinations?
You constrain rather than hope. Answers are grounded in retrieved passages with citations, outputs that drive actions are schema-validated, confidence thresholds route to a human, and the evaluation suite catches regressions before release.
Can you work with our existing model provider or on-premise requirement?
Yes. We build against a provider-agnostic interface, and we have shipped systems on hosted APIs, on cloud-hosted open-weight models, and fully inside a client VPC where data residency required it.
