A prototype usually answers a narrow question: can this interaction work at all? A system that others can operate has to answer more: with which data, under whose identity, inside which boundaries, measured by which criteria, and with what fallback?
The distance between them is not a single “productionisation” phase. It is a sequence of small engineering decisions.
Choose a complete slice
The first slice should be small but run through the real workflow. It includes input, data access, model call, validation, human decision and the result in its destination. An isolated model test merely postpones integration risk.
Write down the boundary: supported cases, unsupported cases, permitted sources and permitted actions. This description will prove more useful than a long feature list.
Version the behaviour
System behaviour includes more than source code. Model identifier, prompt, tools, schemas, retrieval configuration and relevant policy must be attributable to a change. Where a provider cannot pin a version indefinitely, a change still needs visible evaluation and a fallback.
An unexpected answer can then be investigated as a specific deviation rather than a guess about “the model”.
Use evaluation during development
A small curated evaluation set starts before expansion. It contains realistic input forms, critical edge cases and explicitly unwanted behaviour. Automated checks suit structure, required fields, numerical grounding, permissions and sources. Professional quality also needs human judgement.
The goal is not a universal score. It is a release gate that explains what makes a change worse for this workflow and who owns a deliberate exception.
Design the failure path
Provider failure, timeout, invalid structure, missing source and rejected tool action each need visible behaviour. Depending on the task, that might be a retry, a manual queue, the previous process or a clear stop.
A fallback is sound when it can be rehearsed before an incident. “Turn off the model” is not enough if nobody knows how work continues afterwards.
Build for handover
Handover does not begin at the end. Ownership, configuration, secrets, log access, cost and the change path shape the architecture from the start.
A useful finish lets another accountable person:
- deploy the current state reproducibly,
- test a change against agreed cases,
- isolate a failure,
- return to a known state,
- understand open boundaries and decisions.
That is less theatrical than a demonstration. It is the difference between an interesting prototype and a system that can hold up in the work.
The services connect clarification, implementation and stabilisation along that boundary.
Want to assess a specific workflow?
Get in touch