Putting an AI agent into production: four things to have before launch day
An agent that works in a demo is not ready for production. Four things to have in place before launch, and how to build them on Databricks.
Building an AI agent that answers questions in a demo now takes a few days. Putting that agent into production, where real users ask real questions and the agent calls tools that act on real data, is a different job. Most projects stall between the two, not because the model is weak, but because nobody can answer three questions: is the agent answering correctly, where does it go wrong when it does, and who is accountable for what it did.
This article covers four things to have in place before launch, based on how Databricks structures agent evaluation and operations.
1. An evaluation suite before launch
Conventional software testing does not work for agents. The same question can produce different answers from one run to the next, and the agent decides the order in which it calls tools rather than following a fixed code path. You cannot write an equality check and wait for a pass or fail.
Agent evaluation instead rests on three parts:
- An evaluation dataset that reflects how users will actually ask, deliberately includes hard and rare cases, and has a reference answer or criteria for each question.
- Scorers: some built in for common criteria such as correctness, safety, groundedness in retrieved documents and correct tool use; others written for the organisation’s own business rules, in natural language or in code.
- A quality gate: an agent version that does not meet the threshold on the evaluation suite is not deployed.
On Databricks, MLflow handles this. Each evaluation is a recorded run, so a new version can be compared with the old one before it replaces it. Each score comes with a rationale in plain language, so the team can see why an answer failed.
2. A trace of every step the agent takes
When an agent answers wrongly, the first question is where it went wrong: irrelevant documents retrieved, the wrong tool chosen, wrong parameters passed, or a correct set of facts reasoned about badly. Without a trace, that question has no answer.
MLflow Tracing records every step of each request: model calls, retrievals and tool calls, with inputs, outputs and timing for each. Traces follow the OpenTelemetry standard, so they can be sent to the monitoring system the organisation already uses. Some evaluation criteria, such as whether the retrieved documents were sufficient, can only be scored when the full trace is available.
The trace is also evidence. When an answer or an action has to be explained, there is a detailed record rather than a reconstruction from memory.
3. Continuous monitoring in production
A pre-launch evaluation suite has limits: static data goes stale, and real users always ask questions nobody anticipated. The scorers used in development therefore need to keep running on real traffic after launch.
Not every request needs every scorer. The rule is that the higher the cost of missing a problem, the higher the sampling rate: safety and security scorers run on every request, while scorers that call a language model and cost more per run can cover a sample of traffic, at a rate set per scorer. When quality scores cross an alert threshold, the team hears about it before users complain.
Failures found in production go back into the evaluation dataset. That loop keeps the suite close to how the agent is really used, and every new version has to pass the failures that have already happened.
4. Scoped permissions and human approval
An agent should reach only the data and tools its task requires. On Databricks, an agent deployed as an app has its own identity (a service principal), and that identity decides which tables it can read and which tools it can call. Tools can be functions governed in Unity Catalog, so the right to call a tool is granted and revoked like the right to read data.
For high-impact actions, such as approving a transaction, changing customer data or sending messages outside the organisation, the agent should propose and a person should decide. This is more than good practice. Point d of clause 1 of Article 14 of Vietnam’s Law on Artificial Intelligence, No. 134/2025/QH15, requires providers of high-risk AI systems to design them so that people can monitor and intervene. For banks, as we explained in What Decision 33/2026 means for banks, whether a person approves also decides whether a system falls on the high-risk list at all.
Approval only counts if it is recorded: who approved, when, and on which proposal from the agent. The trace from section 2 and the approval log together make a complete record for each decision.
Where Sancire comes in
Sancire’s AI & Agents to Production package takes 8 to 12 weeks and starts at $50,000. It delivers an agent in production with evaluation, tracing, guardrails and human approval, plus the monitoring routine after launch. If you have an agent stuck at the demo stage, the 90-minute discovery workshop is the place to start.
Sources: Vietnam Law on Artificial Intelligence No. 134/2025/QH15, Article 14. Databricks documentation on evaluating and monitoring GenAI apps with MLflow, read on 28 September 2026, and on production monitoring, read on 16 October 2026. Feature names and status change quickly; check the current documentation before designing.