What Makes an AI Agent Production-Ready?

A production-ready agent is one that can safely serve many real users, not just answer a demo prompt. The difference is rarely the model. It is the operational layer around it: identity, access control, observability, quota, memory, and deployment choice. Vanna 2.0 frames this as "user-scoped execution, rich UI components, and quota management built-in," and its SQL Agent page lists the admin features that separate a prototype from something you can ship. If your agent only needs to answer questions for you on your laptop, you do not need most of this. If other people will use it against real systems of record, you do.

Demo agent vs. production-ready agent

A demo agent usually runs as a single trusted user with broad credentials, no per-user limits, and no record of what happened. That works until a second person logs in.

The pattern is consistent: production readiness is about constraining and recording what the agent does, not about making it smarter.

Why user-scoped execution is the gating requirement

The single most important property is that every request runs as a specific user, with that user's permissions. This is what "user-scoped execution" and "multi-tenant agents" mean in practice.

Consider a SQL agent that lets employees query company systems of record. If the agent connects with one admin database account, then a sales rep can read finance tables simply by asking nicely. The agent has no way to know the request should have been denied. User-scoped execution fixes this by binding the query to the requesting user's identity, so the database enforces the same rules it would for that person typing SQL directly.

This is why identity comes before capability. An agent that can do more than its user is allowed to do is a security incident waiting to happen, and no amount of prompt engineering substitutes for it.

The capabilities you must add before launch

Vanna's page lists these as optional hosted admin features. Treat them as the checklist for going live:

• Access control — control who sees what. Without it, multi-tenant isolation is impossible.
• Observability — real-time metrics and distributed tracing. You need to answer "why did this answer come out wrong?" after the fact.
• Agent memory — a hosted vector database for learning. Persistent memory is what lets the agent improve across sessions instead of starting cold every time.
• File system — secure file storage and retrieval. Agents that read or produce files need somewhere safe to do it.
• Audit logs — comprehensive activity tracking and compliance. Required when someone asks who ran what and when.
• Data retention — long-term storage for conversations and logs. Needed for debugging, review, and compliance windows.

Two of these deserve emphasis. Observability is not optional at scale: without tracing, a wrong answer is unexplainable, and an unexplainable agent cannot be trusted with real decisions. Agent memory and file storage affect reliability and user experience directly — a user who has to re-explain context every session will stop using the agent.

Choosing a stack without locking yourself in

Vanna's "Choose Your Stack" section is built around avoiding vendor lock-in: the framework works with any LLM provider and any database, and you select your options to generate configuration code.

• LLM providers shown: Anthropic, OpenAI, Gemini, Ollama
• Databases shown: SQLite, PostgreSQL, MySQL, Snowflake, BigQuery, and other databases via docs

The practical test for lock-in is whether you can swap one component without rewriting the agent. If your prompts, memory, and access rules are tied to a single vendor's proprietary format, you are locked in regardless of what the marketing says.

Open source, cloud, or self-host

The page presents three deployment paths:

1. Open source — pip install vanna, multi-database, multi-turn, access controlled. The page notes a 30-minute path and a 1-minute "Dummy Database in Colab" with no sign-in.
2. Cloud — the hosted option.
3. Self-host — run it yourself.

The admin features above (access control, observability, memory, file system, audit logs, retention) are described as optional hosted features, with a link to pricing. That distinction matters: if you go open source, you are responsible for providing equivalents of those capabilities yourself. If you want them managed, the hosted path is the one to evaluate — check the pricing page for current terms, since cost and plan details are not specified here.

A reasonable decision rule: start open source to validate that the agent answers useful questions against your data, then decide whether you want to operate the identity, observability, and retention layer yourself or pay for it hosted.

A concrete readiness test

Before calling an agent production-ready, walk through this with a second user account:

1. Log in as a user with limited permissions and ask for data they should not see. Expected result: denied, by the same rules the database enforces.
2. Ask a question that requires multi-turn context. Expected result: the agent remembers the prior turn.
3. Restart the service and repeat. Expected result: memory and files persist.
4. Trigger a wrong answer and try to trace it. Expected result: you can see the steps, not just the output.
5. Check the audit log for the above activity. Expected result: each action is recorded with the responsible user.

If any step fails, that is the gap between your prototype and production.