The Production AI Playbook: What Enterprise Agents Need Before Launch

A bank chatbot can answer "what is my account balance?" in a demo. The production question is different: can it handle 20,000 monthly conversations, spot when a policy document is stale, avoid leaking PII, stop after a tool fails three times, route the hard case to a person, and leave enough evidence for compliance to reconstruct what happened?

That production gap is the useful frame from Sandipan Bhaumik's Databricks session, The Production AI Playbook: Deploying Agents at Enterprise Scale. The model matters, but the operating system around the model matters more: evaluation, observability, data, orchestration, and governance.

For mid-market and private-equity-backed companies, this matters because most AI work is stuck between two false choices. One side wants a quick demo that impresses leadership. The other wants a giant platform program before anything ships. The right path is narrower and more practical: pick one workflow, define the business target, build the measurement layer first, and expand only when the agent has earned more authority.

The Demo Is the Least Expensive Part

The pattern is familiar: leadership pressure creates an AI pilot, the first meeting becomes a model debate, the team builds in a controlled environment, the demo works, and production exposes everything the demo hid.

The failures are not mysterious. The agent sees messy user input instead of polished prompts. It needs data that was written for humans, not machines. It calls APIs that time out, return partial results, or require permissions. It faces policies that changed last week. It may need to coordinate with other agents or workflow steps. When something goes wrong, no one can prove which document it read, which tool it called, or why it took an action.

That is why the first production question is not "which model?" It is "what would make this system visible, measurable, and accountable?"

OpenNash uses the same starting point in client work. Before building the agent, we define the workflow boundary, the systems it can touch, the actions it can take, the cases it must pass, and the humans who own exceptions. A customer support agent, an invoice agent, and a CRM cleanup agent may use similar model APIs, but their release gates should look different because their business risks are different.

Start With Evals, Not Prompts

The strongest production advice is also the step most teams skip: define evaluation before touching code. Evaluation is the spec for an AI system.

That means business metrics, not vague quality words. A support agent might need to deflect 60% of simple tickets, keep policy accuracy above 85%, escalate all refund requests above a threshold, stay under a response-time target, and maintain CSAT within a defined band. A finance agent might need perfect arithmetic, correct vendor matching, no write-back without approval, and an exception flag when a document is missing.

The evaluation set should come from real work. In the Databricks banking example, the team collected 200 cases based on how human agents answered customer questions. That dataset became the reference point for model comparison, prompt changes, regression tests, and post-launch monitoring.

This is the same reason we argue that every production failure should become an eval case. A static test set goes stale. A living test set grows from incidents, reviewer overrides, policy changes, and edge cases. Over time, the eval suite becomes institutional memory.

Use layers:

MLflow's LLM and agent evaluation docs describe the same pattern in platform terms: datasets, expected outputs, scorers, human feedback, LLM-as-a-judge checks, and production monitoring. The business translation is simple. Do not ask whether the agent sounds smart. Ask whether it passed the cases that represent the queue.

Make Every Decision Traceable

An agent is not a single request and response. It may classify intent, retrieve policy, call a customer database, reason over the result, run a guardrail, draft an answer, retry a failed step, and then write back to a ticketing system. If you only log the final answer, you have no production evidence.

Tracing needs to capture the chain:

• User input and session metadata.
• Prompt, model, temperature, and version identifiers.
• Retrieved documents and document versions.
• Tool calls, parameters, raw results, failures, and retries.
• Guardrail checks and policy checks.
• Final output, escalation decision, and human override.
• Cost, latency, token use, and error data per step.

MLflow Tracing is a useful reference here because it captures inputs, outputs, and metadata for intermediate steps in LLM and agent requests. It also ties tracing to dataset collection, which is the key loop: production traces become future eval cases. OpenTelemetry's GenAI semantic conventions point in the same direction by giving teams a common vocabulary for model and agent telemetry instead of one-off logs that only one engineer can read.

For operators, this is not just debugging. It is cost control and risk control. A duplicate API call may look harmless in a demo. At 50,000 tickets a month, it becomes a budget problem. A stale policy document may look like a bad answer. In a regulated workflow, it becomes an audit problem. A tool retry loop may look like latency. In production, it can become an outage.

The standard dashboard should show more than uptime. It should show deflection rate, pass rate by eval category, stale retrieval hits, duplicate tool calls, human escalation rate, override rate, PII flags, cost per resolved case, and failure types by week.

Treat Data as Agent Infrastructure

Most company data was built for humans. Humans forgive broken labels, stale folders, duplicate records, and unclear ownership. Agents do not. They will read the wrong document and answer with confidence.

That creates two data foundations.

The first is question data: policies, product docs, CRM records, invoices, tickets, contracts, transaction data, and APIs the agent uses to do work. This data needs ownership, freshness checks, access rules, and version history. In the banking story, customer feedback dropped after an interest-rate policy change because the vector database still served the old policy. The fix was not a better model. It was data freshness and trace visibility.

The second is tracking data: traces, eval results, human feedback, incidents, tool logs, and cost data. As a company moves from one agent to ten, this tracking data becomes an operating asset. It tells leaders where agents are helping, where risk is rising, and which workflows deserve more automation.

For PE operators, this is a diligence point. If a portfolio company claims it has production agents, ask to see the data contracts behind them. Who owns the policy corpus? How quickly do document changes reach retrieval? Which records can the agent read? Which systems can it write to? How long are traces retained? Can incidents be replayed?

Permissions Are the Blast-Radius Control

Agent permissions should be designed like production access, not like a demo API key.

The OWASP Top 10 for LLM Applications calls out risks that map directly to agent deployments: prompt injection, insecure output handling, sensitive information disclosure, insecure plugin design, excessive agency, and overreliance. The common thread is authority. The more tools and data an agent can access, the more damage a wrong step can cause.

Production agents need least-privilege design:

• Read-only access by default.
• Separate identities for each agent and environment.
• Tool allowlists by workflow.
• Field-level and row-level controls where records contain sensitive data.
• Approval gates for record-changing actions.
• Rate limits and retry caps for expensive or risky tools.
• Secret isolation, redaction, and PII masking in traces.
• Clear stop conditions when the agent is uncertain or a tool fails.

The goal is not to make the agent timid. The goal is to let it do useful work inside a bounded area. A support agent can draft a refund response without issuing the refund. A finance agent can flag an invoice discrepancy without posting to the ledger. A sales ops agent can prepare CRM updates and require approval before writing to the system of record.

This is also where the rollout plan matters. In early stages, the agent should run in shadow mode or recommendation mode. Only after the eval suite, traces, and human-review data support the move should the agent receive limited write authority.

Governance Is What Happens at 3 A.M.

Governance sounds abstract until the first production incident. Then it becomes very concrete: who gets paged, what dashboard do they open, how do they contain the issue, and what evidence do they need?

NIST's AI Risk Management Framework is helpful because it frames risk management as a lifecycle practice across design, development, use, and evaluation. The EU AI Act's record-keeping requirement for high-risk systems pushes in the same direction: systems need automatic logs that make operation traceable. Even when a mid-market company is not directly in scope for high-risk AI regulation, the operating lesson holds. If the agent touches money, customers, compliance, healthcare, employment, credit, insurance, or legal workflows, evidence is part of the product.

A production incident playbook should define four moves:

1. Detect through eval dashboards, alerts, user feedback, or human-review queues.
2. Diagnose with traces, retrieved document versions, tool logs, and prompt history.
3. Contain by rolling back a prompt, disabling a tool, lowering autonomy, routing to humans, or pausing the workflow.
4. Fix by changing the right layer and adding the incident to the eval suite.

That last step is the difference between firefighting and compounding improvement. If an incident closes without a new eval case, the business has no guard against repeat failure.

Pick the Model in Week Seven

The timing in the banking case study is the point. In the eight-week project, the model decision happened in weeks seven and eight. Weeks one and two built the evaluation layer. The team defined success, gathered real examples, set accuracy and latency targets, built the automated eval pipeline, and instrumented the system. Only then did model comparison become useful.

That ordering saves money. It also saves meetings.

Without an eval set, model selection becomes a room full of opinions. With an eval set, the team can compare candidate models against the company's own cases, cost targets, latency limits, and policy risks. That is how OpenNash approaches Harbor-style agent evals for real business work: the harness should let the company test model swaps, prompt edits, tool changes, and retrieval updates against the same work.

The same discipline applies after launch. Model providers change capabilities, pricing, and deprecation schedules. A production agent should not depend on one model forever. It should have a release process that can test alternatives, promote winners, and roll back losers.

A Practical Rollout Path

The safest rollout is staged:

For a support workflow, the agent might start by drafting replies. Then it can answer low-risk policy questions. Later it can update ticket fields. Only after enough evidence should it perform customer-facing actions without approval, and even then only inside a narrow policy boundary.

For finance, the bar is higher. Let the agent extract, match, and flag. Keep posting, payments, and approvals gated until the eval suite proves the exception paths.

For sales operations, let the agent enrich accounts and draft updates before allowing writes to CRM fields that affect reporting, compensation, or customer communication.

Where OpenNash Fits

OpenNash builds the operating layer that turns agent demos into owned business systems.

We start by mapping the workflow and the business metric. Then we build the eval set from real cases, connect traces, define permissions, add human review, and wire dashboards to the operating cadence. The agent may use an OpenNash-built orchestration layer, MLflow-style tracing, Harbor-style sandbox evals, existing CRM and ticketing APIs, or a client's preferred model provider. The platform matters less than the control loop.

The handoff should include the agent, prompts, tool definitions, eval suite, trace schema, dashboards, incident playbook, rollout plan, and ownership model. The client should be able to change models, update policies, add cases, review failures, and prove why the system behaved a certain way.

A production-grade agent is not a smarter chatbot. It is a measured workflow with permissions, tests, evidence, and recovery paths. Once that foundation exists, autonomy can grow without turning every launch into an act of faith.