A working prototype
Running on your data, in the workflow it would actually live in. Clickable, not imagined.
Tech
Output, not slideware.
Most AI products are not chatbots. They are agents finishing tasks across systems, scoring models behind a single field, tools called from software your team already runs, classifiers inside processes nobody watches.
Four things carry one into daily use: the prototype, the stack under it, the production build, and the rhythm that keeps it current.
- Prototype
- two weeks
- Production
- six to twelve
// one request
traced- retrieve240 mshybrid · rerank
- classify180 msfast model
- reason1.4 sfrontier model
- tools320 msMCP · scoped
- validate40 msschema
which model answered · what was retrieved · what it cost
The first commitment
“Is this worth building properly?”
Two weeks, on your data, in your workflow.
A prototype is evidence, not a demo. It runs the happy path, on data we prepared, with permissions that come later, against one model with no fallback.
It answers one question, and both answers are useful. Either one arrives in two weeks.
A written note on what it proved
What worked, what did not, and what the evidence says about building it properly.
A production estimate, by layer
Itemized against the nine decisions below, so the next commitment is priced before you make it.
Two different objects
The prototype is not a small production build.
It is a different thing entirely, and that is the whole answer to why one takes two weeks and the other takes three months. Switch between them and watch what has to change.
Dataa sample we preparedrecords as they actually arrive
Usersin the room with usnot there, and not briefed
Modelsone, no fallbackrouted by task, with fallback
Permissionscome laterenforced before retrieval
Costmeasured per runcapped per user and workload
Failurewe restart itretries, fallback, tested rollback
Six things change, and every one of them is engineering the prototype was allowed to skip.
The stack
Nine decisions, made in writing before the build starts.
Every AI product is these nine layers, whether or not anyone chose them deliberately. We choose them with you, and we write down why.
Four are worth deciding carefully, because undoing them later costs real money. The rest can change whenever the evidence changes.
// nine layers, one system. The lit plate is the one you are reading.
Our defaultHeadless or embedded. Chat where the task has no defined end.
A chat box is the right answer far less often than it gets specified. Most work has a beginning and an end, and belongs inside the software people already have open.
Our defaultDeterministic backbone, model called at chosen points.
Cheaper to run, easier to debug, and predictable under load. Autonomy is reserved for steps whose path genuinely cannot be known in advance.
Our defaultLangGraph checkpointing under an hour, Temporal beyond it.
Anything that runs long enough to be interrupted needs to survive the interruption. The threshold is roughly an hour of wall-clock work.
Our defaultHybrid search plus reranker before anything exotic.
Retrieval sets answer quality more than the model does. Hybrid search with a reranker resolves most of it without a research project.
Expensive to reverse: the embedding model.
Our defaultpgvector under ten million vectors, Qdrant or Weaviate above.
A dedicated store earns its place when scale, metadata filtering, or tenant isolation calls for it. Below that, it is one more system to operate.
Expensive to reverse: where the data sits.
Our defaultGateway always. It is what makes routing real.
One door out is what turns routing, budget caps, provider fallback, and per-call logging from intentions into mechanisms.
Expensive to reverse: gateway or no gateway.
Our defaultMCP, with auth and per-server permissions in front.
A shared protocol means a new tool is a configuration change rather than a build. The permissions layer in front of it is not optional.
Our defaultSuite gating deploys, same as ordinary tests.
Quality that is only checked by eye drifts silently. A suite on real cases from your work catches the regression before it ships.
Our defaultOpenTelemetry GenAI conventions, into monitoring you already run.
Open conventions mean the traces land in the tooling your team already watches, instead of a second dashboard nobody opens.
Expensive to reverse: whether tool calls are logged.
Why those defaults
On orchestration.
Workflows are cheaper, more predictable, and easier to debug than agents. Autonomy earns its place where the number of steps genuinely cannot be known in advance.
Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.
Anthropic, Building Effective AI Agents, December 2024
On retrieval.
It sets answer quality more than the model does. Hybrid search plus a reranker resolves most retrieval work on its own. A dedicated vector store earns its place when scale, metadata filtering, or tenant isolation calls for it.
On routing.
Cheap fast model for classification and extraction, frontier model for the reasoning that needs it, in the same system. The gateway is what makes that possible.
The build
“What makes it survive real users?”
Production engineering.
The prototype earned the decision. This build makes it something your organization runs every day, on records as they actually arrive.
// hardening0 of 7
- data
- entitlements
- schema
- tool scope
- caps
- fallback
- rollout
Real data
Real records replace the clean sample. Missing fields, duplicates, the twelve-year-old naming convention nobody documented.
Entitlements
Filter by permission before retrieval, so the system only ever reaches what the user is cleared to see.
Structured outputs
Schema validation on everything downstream, with defined behavior when a response falls outside it.
Tool permissions
Scoped access per tool, and human confirmation on consequential actions.
Cost controls
Caps per user and per workload, sized against real production volumes rather than pilot ones.
Failure paths
Retries, provider fallback, and a rollback that has actually been tested.
Rollout
Waves, with a measurement at each one, so adoption is observed rather than assumed.
// what you get
- A production system, with every stack decision documented.
- Entitlement-aware retrieval and budget caps.
- An evaluation suite in CI, and tracing into monitoring you already run.
- Integration into the software your team already opens.
- Source and documentation included.
“Who keeps it current?”
A routing decision made in March is worth revisiting by September.
Models improve, prices fall, providers ship new versions. Re-benchmarking is not maintenance, it is the cheapest performance work available, and it usually pays for itself.
Changing an embedding model means reindexing the corpus. We design for that from day one, so it stays a scheduled operation rather than a crisis.
Monthly, sized to the system: a named senior contact, a re-benchmarking rhythm, a visible backlog, and a cost model held against real spend. Everything documented for handover at any point.
Prototypetwo weeks
Decisiongo or stop
Productionsix to twelve weeks
Run and evolvemonthly, sized to the system
FAQ
Questions we get.
Two weeks for a prototype, three months for production. Why?
Different objects. The prototype runs on data we prepared, for users in the room, one model, no fallback. Production runs on data as it arrives, for users who are not there. The second timeline goes to retrieval quality, entitlements, evaluation, failure handling, and integration.
What does it cost to run per month?
It depends on volume and routing, and we model it during the prototype rather than estimating it afterward. The prototype reports cost per run on your real data, which extrapolates to production volumes with reasonable accuracy. Budget caps per user and per workload are set before launch.
Can you take over a system another vendor built, or one our team built quickly?
Yes, after an assessment. We look at how retrieval is evaluated, where permissions are enforced, and what is traced today, then give you a costed path forward with the options side by side.
Do we have to use your stack?
No. We build on what you run. We give considered input on the four expensive-to-reverse decisions: data location, embedding model, gateway, tool logging.
Which models do you use?
Usually several in the same system, routed by task. The benchmark sits in the AI pillar; this pillar implements the result.
Do you build agents or workflows?
Both, and the choice is made per step rather than per project. Most systems we ship are a coded workflow that calls a model at specific points, with autonomous behavior reserved for the steps where the path genuinely cannot be known in advance. That mix is cheaper to run and easier to reason about when something needs changing.
What if we already have a data warehouse and a cloud provider?
Good, that shortens the build. Most of these layers sit on top of infrastructure you already run, and retrieval in particular tends to work better close to the systems where your data already lives. We start from your stack and add what the use case needs.
Can our data stay in Europe?
Yes. Residency and sovereignty are separate questions and we answer both at design time. Residency is where the data physically sits. Sovereignty is whose law reaches it, which depends on who operates the infrastructure rather than where the building is. Both go in the architecture document before the build starts.
How do we know it is working after launch?
An evaluation suite runs in CI on a set of real cases from your work, so a change that moves quality shows up before it ships. In production, tracing shows the full path of any request: which model answered, what was retrieved, which tools were called, what it cost. Your team has the same view we do.
Can our own engineers work on it?
That is the intent. Source, documentation, and the architecture decision record are yours throughout. Where your team wants to own a layer from the start, we build it with them rather than handing it over later.
Do we own what you build?
Yes. Source, documentation, and data are yours.
Related work
What this looks like in practice
Three builds that went into production and stayed there: ERP integration behind a human approval step, two platform APIs behind one workspace, and a quotation pipeline sales actually uses.
Procurement and supply chain
Supplier documents matched before receipt
Mismatches surfaced at goods receipt, far too late to act. Extraction, three-way matching, and an exception queue moved the discovery forward to the confirmation stage.
Handwritten extraction droppedRead the case→
Demand generation
An ads factory for two platforms
Two people ran both ad platforms alongside everything else. A campaign workspace now drafts, tests, and adjusts. Neither ad manager gets opened in normal operation.
Both ad managers retiredRead the case→
Sales and pricing
Quotations assembled from client context
Pricing logic lived in three people’s heads. Writing it down was most of the project. Sales now checks and sends rather than assembling from scratch.
The pricing logic, written downRead the case→
July 202613 min read
AI orchestration: the architecture after one model
One model rarely ships. Orchestration coordinates specialized models and tools, then adds decision points you should govern before you build.
Read the piece→
July 202613 min read
Code or platform? The question after the POC
The demo worked. Now: build it in code, or run it on a platform? Four questions, ordered so the first hard answer ends the discussion.
Read the piece→
June 20269 min read
12 NotebookLM prompts that do real work
Most people give NotebookLM lazy prompts and get book reports back. Twelve our team uses to pull real work out of it instead. Each prompt included in full and formatted to copy.
Read the piece→Talk to us
Talk to us about AI.
A conversation with the senior team about your markets, your data, and where AI would actually pay back for you. No slides, no obligation, and if the honest answer is that AI is not your next move, you will hear that too.