Enterprise data teams are moving from dashboards and one-off text-to-SQL demos towards systems that can investigate questions, call tools, validate results, and recommend or execute the next action. Building autonomous agents over enterprise databases can unlock faster reconciliation, supply-chain analysis, customer operations, and finance workflows—but only when the agent is constrained by reliable metadata, permissions, and measurable checks.
The central design principle is simple: treat the language model as an orchestrator of governed data tools, not as an unrestricted database administrator. A production agent should discover the right data, form a plan, generate a query, validate it, execute it with minimum privilege, inspect the result, and escalate uncertainty to a human.
What makes a database agent autonomous?
A conventional text-to-SQL application usually follows one path: question, SQL, result. An autonomous agent manages a loop with state and observations. It may:
- Clarify an ambiguous request such as “last quarter” or “active customer”.
- Search a business glossary and schema catalog before writing SQL.
- Break a question into several queries across a warehouse, CRM, ERP, or operational database.
- Retry after a syntax, permission, timeout, or empty-result error.
- Check whether totals, dates, joins, and units are plausible.
- Produce a cited explanation and request approval before any consequential action.
This is closer to a controlled software system than a chatbot. Teams designing broader agent workflows can also review how to build generative AI agents, but database agents need especially strict execution and audit controls.
Reference architecture
A dependable implementation separates reasoning from access to data. A practical architecture has these layers:
1. User and application layer: Accepts a question, business objective, or scheduled task and records the identity, department, and purpose.
2. Planner: Converts the objective into typed steps, such as finding approved vendors, calculating a threshold, and comparing transactions.
3. Metadata retrieval layer: Finds relevant tables, views, metrics, joins, policies, examples, and data owners.
4. Query compiler: Produces dialect-specific SQL using approved schemas and parameterised values.
5. Policy gateway: Enforces row-level security, column masking, cost limits, read-only roles, and approval rules.
6. Execution tools: Runs queries, Python transformations, APIs, or approved write-back operations in isolated environments.
7. Verifier and response layer: Tests the result, records evidence, explains assumptions, and returns an answer or escalation.
For long-running workflows, use a stateful graph with explicit nodes and transitions rather than an unconstrained loop. This approach makes retries, timeouts, human approvals, and partial completion observable. It also complements patterns covered in building distributed systems with AI agents.
Build a usable semantic layer first
The quality of an agent depends less on prompt length than on the quality of the information it can retrieve. Raw enterprise schemas are rarely sufficient: names may be abbreviated, relationships may be implicit, and the same metric may have different definitions across business units.
Create a governed catalog containing:
- Table and column descriptions written in business language.
- Data types, units, freshness, owners, and retention rules.
- Approved joins and cardinality warnings.
- Definitions for metrics such as revenue, churn, gross margin, and active user.
- Sample values that exclude sensitive information.
- Role-specific visibility and masking requirements.
- Golden questions paired with verified SQL and expected result characteristics.
Prefer curated views or a metric layer over unrestricted access to raw tables. A view called monthly_net_revenue is safer and more useful than asking a model to reconstruct tax, refunds, cancellations, and currency conversion from dozens of ERP tables. Retrieve only the relevant metadata for each request; sending an entire warehouse schema into the context window increases confusion, cost, and leakage risk.
SQL generation needs a compiler pipeline
Never execute model output directly. Use a staged pipeline:
- Intent parsing: Extract entities, time ranges, filters, dimensions, measures, and the requested action.
- Schema grounding: Confirm that every table and field exists and is permitted for the caller.
- Generation: Produce SQL for the actual warehouse dialect, such as PostgreSQL, BigQuery, Snowflake, or Spark SQL.
- Static validation: Reject multiple statements, DDL, DML, comments used to bypass controls, unrestricted scans, and unsafe functions.
- Dry run or query plan: Estimate cost, partitions, joins, and expected row counts.
- Execution: Apply parameter binding, statement timeouts, quotas, and a read-only role.
- Result verification: Check null rates, duplicate keys, date coverage, reconciliation totals, and business constraints.
A syntax linter is useful, but it is not a security boundary. The database, proxy, and identity layer must enforce permissions independently of the model. For sensitive actions—such as changing a supplier status, issuing a refund, or writing back to an ERP—require a structured approval containing the exact records, proposed change, rationale, and audit trail.
Security and governance for Indian enterprises
Agents may process personal, financial, health, or employment data. Map each use case to the organisation’s privacy programme and applicable obligations, including the Digital Personal Data Protection Act, contractual commitments, sectoral rules, and internal retention policies. Legal review should be part of launch readiness, not a post-deployment step.
Implement controls at several layers:
- Use identity-aware access with separate service accounts and short-lived credentials.
- Enforce row- and column-level policies in the warehouse, not only in prompts.
- Mask Aadhaar-linked data, phone numbers, email addresses, account identifiers, and other personal fields unless the task requires them.
- Keep prompts, tool calls, SQL, approvals, outputs, and policy decisions in tamper-evident logs.
- Define whether data may leave India or be processed by an external model provider.
- Provide a self-hosted or private deployment path for regulated workloads; deploying Llama 3 agents is one option to evaluate, alongside model quality, latency, hardware, and support requirements.
Prompt injection can enter through database text, customer notes, documents, or tool responses. Treat every retrieved value as untrusted data. Never allow a row, document, or user message to redefine system instructions or permissions.
Evaluation before production
Accuracy should be measured against representative work, not a handful of impressive demos. Build an evaluation set from anonymised historical questions and include ambiguous, adversarial, and failure cases. Track:
- Correct table, metric, join, filter, and time period selection.
- Execution success and safe recovery from errors.
- Numerical agreement with an approved reference answer.
- Citation and evidence completeness.
- Cost, latency, warehouse load, and token usage.
- Policy violations, sensitive-data exposure, and unauthorised tool calls.
- Human approval rate and escalation quality.
Test schema changes, stale metadata, regional terminology, mixed English and Indian-language questions, fiscal years, lakh/crore formatting, GST treatment, and timezone boundaries. Use shadow mode first: let the agent generate plans and answers while analysts approve or compare them, without permitting writes.
A practical use case: vendor-payment audit
Suppose a finance team asks: “Find transactions above ₹50 lakh paid to vendors not on the approved list during the previous quarter.” A governed agent should:
1. Resolve the organisation’s fiscal-quarter definition and currency rules.
2. Retrieve approved views for payments, vendor master data, and the approval register.
3. Generate a read-only query with a parameterised amount threshold and date range.
4. Validate vendor identifiers, including sanctioned name variations and duplicates.
5. Compare results with the approved list using deterministic matching rules, not only an LLM judgement.
6. Return transaction IDs, evidence, confidence, and unresolved matches for review.
The agent should not automatically block a payment unless a separate workflow, policy, and human approval explicitly authorise that action.
Delivery roadmap
Start with one high-value, read-only workflow where success can be measured. In the first release, expose curated views, a small metric glossary, query limits, and human review. Next, add multi-step planning, result verification, and connectors to approved systems. Only then consider write-back actions with narrow scopes and mandatory approvals.
For teams building customer-facing systems, the same principles apply to voice interfaces: distinguish an agent that can safely call enterprise tools from a simple voicebot, as explained in voicebot vs voice agent: key differences for enterprises. The interface may change; identity, policy, observability, and evaluation remain essential.
FAQ
Can one agent query structured and unstructured data?
Yes. Use SQL for authoritative facts and retrieval over contracts, tickets, or policies for context. Keep provenance separate and make the agent state which source supports each claim.
Should the agent access production databases?
Prefer a governed warehouse, replica, or curated semantic layer. If production access is unavoidable, use read-only credentials, strict timeouts, row limits, and database-native controls.
How much autonomy is appropriate?
Match autonomy to risk. Answers and draft analyses can be automated earlier; financial changes, customer-impacting actions, and regulated decisions should require explicit approval.
What should builders in India prioritise?
Start with data residency, privacy classification, fiscal and regional business rules, multilingual terminology, reliable audit logs, and deployment options that fit the organisation’s security posture.
AI Grants India supports Indian builders working on trustworthy data infrastructure and agentic systems. Apply to AI Grants India if you are developing a product that can make enterprise AI safer, more useful, and easier to deploy.