Rust
brat
Use it to run several coding agents in parallel, safely.
Solution · Production AI
The demo works. Now it has to launch.
We take AI prototypes and pilots through the engineering that a real launch needs — evaluation, permissions, recovery, deployment and operational ownership — without rebuilding what already works.
Usually owned by: CTO, Head of AI or the product leader who has committed to a launch date.
The situation
Recognise where you are
A model call that impresses in a demonstration is a small part of a production system. The rest is the software around it: what state the workflow keeps, which tools it may call and with whose authority, what happens when a provider times out halfway through a task, how a bad answer is detected before a customer sees it, and who is paged when the cost per request doubles overnight.
Teams usually discover this gap late — when a security review asks for an audit trail, when an enterprise customer asks what happens on failure, or when the first real users find the inputs the test set never contained. The prototype is not wrong; it was built to answer a different question.
Our work is to close that gap deliberately. We start from your existing workflow, stack and failure cases, establish what “ready” means for this launch, and build only the components that stand between the prototype and that definition.
How we approach it
From the system you have to the result you need
- 1
Define ready
Agree the launch criteria with the owner: the tasks that must succeed, the actions that must never happen, the latency and cost envelope and who signs off.
- 2
Measure the gap
Build a representative evaluation set from real and synthetic cases, run the prototype against it and record where it fails and why.
- 3
Harden the boundaries
Add state and recovery, tool permissions and validation, human approval points, observability and cost controls — the components the measurements show are missing.
- 4
Launch and hand over
Deploy behind a reversible rollout, prove the acceptance scenarios in the target environment and transfer ownership with runbooks and decision records.
Scope
What we need, what you receive
- What we need from you
- The working prototype or pilot, and access to its repository and environments.
- Target users, example tasks and the actions the system must never take.
- The systems and data it touches, and who has authority over each.
- The launch date, expected volume and latency and cost constraints.
- What you receive
- A written definition of launch readiness with acceptance scenarios.
- An evaluation suite that runs in CI and reports task success, invalid actions and recovery.
- Implemented state, permission, approval, observability and recovery layers, scoped to the gaps found.
- A reversible deployment, runbook and handover to the owning team.
- Not included
- Guarantees about model accuracy beyond what the agreed evaluation measures.
- Replacing the model or framework unless the evidence shows it is the constraint.
- Ongoing operation after handover, which is available separately.
- How success is measured
- Agreed acceptance scenarios pass in the target environment.
- Known failure modes fail safely, visibly and recoverably.
- Latency and cost per task are measured and within the agreed envelope.
- The owning team can run, change and roll back the system without us.
How to buy it
Start with a bounded first step
Decision guide
The questions buyers ask, in the order they ask them
01
Why does our agent fail unpredictably?
Usually because state, tool errors and model variance are not separated. A failure that looks random is often a retry without idempotency, a tool returning partial data or a context window silently truncated. Measuring failures by category is the first step to removing them.
02
What does production readiness actually require?
For most launches: a representative evaluation set, explicit tool permissions, recoverable state, human approval where actions are consequential, observability of each decision, cost controls and a rollback path. The right depth for each depends on the consequences of failure.
03
Should we fix this internally, hire a contractor or use a partner?
Internally, if the team has done this before and has the time. A contractor, if you need capacity under your own direction. A partner like Neul Labs, if you want an accountable, scoped outcome with acceptance criteria — and an honest view of what not to build.
04
What would an engagement cost, and what would we receive?
Most production launches begin with a fixed-fee readiness review that defines the gap and acceptance criteria, followed by a fixed-scope sprint to close it. Both are priced in advance; see the engagement pages for indicative ranges.
Evidence
What you can check before trusting us
Client results and public engineering are kept apart; the evidence method explains why.
Client delivery
No client case study is published for this situation yet. See all case studies.
Neul Labs public engineering
Neul-owned work you can inspect — not client case studies or warranties, and never a requirement.
Rust
agentvfs
Use it to sandbox an agent’s files and shell.
Python
ormai
Use it to let an agent query a database, safely.
Python
fastagentic
Use it to ship a local agent to production as an API.
Python
memorg
Use it to add durable memory to an LLM chat app.
Rust
mcp-pay
Use it to charge for MCP tools across payment rails.
Further reading
A good fit
- There is a named workflow, owner and launch decision.
- The system needs controlled access to tools, data or long-running state.
- A prototype exists and needs evaluation, recovery, observability or hardening.
- The team wants an evidence-backed build, buy or framework decision.
Not a good fit
- The goal is an unsupervised replacement for accountable human decisions.
- Nobody can define allowed actions, data authority or a useful evaluation set.
- The requirement is a generic chatbot or a predetermined vendor purchase.
- Success depends on accuracy guarantees that no test can support.
Questions people ask
Can Neul Labs improve an existing AI system without rebuilding it?
Yes. An engagement begins with the existing workflow, stack and failure cases. The first step is to establish a baseline and identify the limiting components; the implementation then targets those components, with agreed tests, rollback and handover requirements.
Can you work with our current agent framework?
Yes. A project keeps its current framework when the framework is not the main constraint. We decide component by component whether to extend, isolate, accelerate or replace.
How do you evaluate an AI system before launch?
We define representative tasks and failure cases, use synthetic or authorised data, pin versions, record tool calls and outcomes, and measure task success, invalid actions, recovery, latency and cost. Model-based judges can supplement but do not replace deterministic checks and human review.
Does a public Neul Labs project prove production readiness?
No. A public repository demonstrates inspectable engineering. Readiness depends on the selected version, workload, deployment, data, security and acceptance tests for the specific system.
Other situations we help with: rescue an ai project · automate a business workflow · make ai useful for a team · get an ai system approved.
The demo works. Now it has to launch.
Launching without that work turns every unknown failure into a customer incident. Not launching turns the prototype into sunk cost while competitors ship.
Scope this with us