Developing an AI agent with database access
A language model answers confidently and smoothly — and that is exactly what makes it dangerous. It does not see the company's current data: inventory balances, request statuses, terms in the contract registry — and fills in the gaps with plausible numbers.
The analyst receives smooth text and rechecks every number against the accounting system, spending hours instead of minutes on a report.
The cause is not the quality of the model, but that its knowledge froze at the moment of training.
Manually inserting a fresh export into the prompt works until the first growth of the registry: the numbers become outdated by the time it is sent, and the data volume does not fit into the context.
The agent and real data remain in different worlds — and a report based on outdated numbers goes into work.
Developing an AI agent with database access changes the scheme: the agent requests the needed slice itself and builds its answer on it.
Integrating the agent with the data store goes as a separate layer — the schema is described as a contract, access is limited by roles and read-only, and the answer relies on rows that can be rechecked in a minute. This same layer decides which tables the agent sees and which remain closed.
Next, we break down how this is addressed: how to describe the schema for the agent, how to limit the selection by rows and roles, and how to make sure the answer contains no invented numbers.
What changes in working with data after launching the agent
Before launching the agent, a question to data is a chain: find the right person, wait for a window in their tasks, get an export into a table.
A typical slice went to the customer hours later, or even the next day, and by the time of the answer the wording of the question often changed.
The agent connects to PostgreSQL with a separate read-only role: it sees schemas, table descriptions, and aggregates, but cannot change a single row.
The answer to a typical question is assembled in seconds — the engineer asks it in words and receives both the result and the query that calculated that result, so the number can be verified rather than taken on faith.
Then the work layout itself changes. The share of manual exports made for one-off slices drops by about three times — only those remain where data from external systems is needed.
The load on analysts shifts from writing repetitive queries to describing metrics and checking the agent's logic, that is, to work that cannot be automated.
A separate effect is a class of errors that disappears along with manual transfer. Copying between tables and reports produced discrepancies: different period filters, an outdated slice, lost rows during consolidation.
When everyone calculates from one source and by one metric definition, a discrepancy between two reports ceases to be the norm.
Downtime also becomes less costly. The on-call engineer gets an answer to the question "what broke and since when" without waiting for an analyst — response time drops from hours to minutes, and incident investigation starts with facts, not guesses.
Ways to connect the agent to data sources
Data access mode is chosen not by ease of connection, but by which class of failures is acceptable in production.
The agent generates queries dynamically, so the load profile is unknown in advance: one unbounded query on a production database holds locks and slows writes from the main application.
Hence the basic requirement — restrictions on direct access: a separate read-only account, an execution time limit, a prohibition on schema changes, a whitelist of tables, and a call log with query text and plan.
Four modes and what they cost
| Option | When it fits | Limitations |
|---|---|---|
| Direct access to production database | Light load, internal tool, row limit | Competes with application writes, risk of locks, access by exception |
| Read replica | Stability of primary database matters, data lag acceptable | Lags behind primary database; heavy queries still need limiting |
| Data mart | Recurring scenarios: reports, summaries, regular aggregates | Updated on schedule; for a new question the mart must be extended |
| Intermediate query layer | Role-based permissions and unified access rules are needed | Layer must be maintained; non-standard questions run into the described metrics |
In practice, we combine modes: the data mart covers frequent questions, the intermediate layer covers the rest, direct read remains selectively with row and time limits.
The agent's logic does not need to be rewritten when the mode changes — only the description of access tools changes.
How we build the agent: stages of engineering work
An agent with database access is not "a model plus a query," but a framework of rights, restrictions, and checks.
That is why we start with data and access, not with question wording: until it is clear which tables the answers are based on and who is allowed to read them, the demonstration remains unstable.
- Data audit. We examine table composition, relationships, duplicates, gaps, and fields with sensitive information. We note where sources diverge and what can be relied upon without caveats.
- Relationship schema. We build a map of entities and keys by which the agent joins tables. Disputed relationships are closed with views with defined logic — an incorrect join produces a plausible but false answer.
- Permission separation. The agent operates under a separate account: read-only and only permitted views. The selection volume and history depth are limited, so a failure does not turn into an export of the entire database.
- Agent tools. For each scenario, we describe allowed selections and behavior when data is insufficient. The agent answers based on fact or reports a gap instead of filling in the answer.
- Test environment. We deploy a copy of the schema with an anonymized slice and run reference questions. We calculate the share of correct answers and response time, and fix relationships and descriptions.
- Checking agent answers. We compare answers with the analyst's calculation and analyze discrepancies. We separately look at behavior on empty selections and clarifying questions.
- Support procedures. We hand over instructions: what to do when the schema changes, how to add rules, and how to roll back changes.
What we hand over to the client: schemas, roles, procedures
A project with database access does not end with just a working agent. We hand over a package that your team can use to support it itself: see what data the agent reads and where it writes, who changes its behavior, and how to roll back a change if the answers stop being correct.
- Data flow diagram — the path from the user's question to a row in the database: which tables and views the agent reads, where it writes only after human confirmation, and where it accesses external services.
- Access policies — a separate agent account with read-only rights to the needed views, a list of prohibited fields, masking and access logging rules.
- Behavior configurations — instruction templates, limits on selection volume, thresholds after which the agent stops and hands the question to an operator.
- Agent documentation — described roles and scenarios, a catalog of available actions, examples of correct and incorrect answers with an analysis of the cause.
- Support procedure — who on your team updates the instructions, how often access rights are reviewed, and which events trigger a check.
- Update procedure — how a new version passes validation on a control set of questions, what is considered a quality degradation, and how to return to the previous version.
- Failure analysis — a log of queries and answers, incident criteria, an analysis template, and response times for requests from your team.
Project breakdown: an agent with database access
Case study of agent implementation: the service department of an equipment supplier processed up to 60 requests per day — "how many shipments under the contract," "which items are negative in the warehouse." The answer was assembled manually: an employee opened three systems, wrote a query, and consolidated the export into a table. Average response time — 40 minutes.
| Stage | Before | After |
|---|---|---|
| Preparing the answer | 40 minutes manually | 4 minutes |
| Manual exports | 12 per week | 2 per week |
| Questions without human involvement | 0% | 86% |
| Data freshness | once a day | delay up to a minute |
Bottlenecks at the start
The first limitation turned out to be not the model, but the schema description: in PostgreSQL without a dictionary of columns and relationships, the agent built queries to non-existent fields and produced a plausible but incorrect answer.
The second was permissions: the service account had extra permissions, and access was cut to views with row-level filtering by client.
The third was structural drift after migrations: discrepancies were caught by a regression set of reference questions with expected selections, which is run on every change.
Project result
Response time dropped from 40 minutes to 4, manual exports decreased sixfold, and 86% of requests are closed without a human. The remaining 14% — non-standard selections — go to an analyst with a ready query draft, not from scratch.
How does an AI agent differ from a conventional database integration?
A conventional integration answers a question that is known in advance. A scheduled report takes one source and one set of conditions — it is written once, works predictably, and barely loads the database outside the run window.
As long as the wording does not change, a rigid query is easier to debug: the result is reproducible, and a discrepancy is explained by a specific row.
The boundary lies where the formulation itself changes. Joining data from several tables, refining a filter based on the results of a previous analysis, adding a new dimension — the report will have to be rewritten: edit, check, release.
The agent differs in that it chooses the source itself: it receives a schema description, table purposes, relationships, and access rules, and then decides which data to go to and how to join it.
On complex queries, the difference is more visible.
The question "how many orders were there by region for the quarter and how does that relate to returns" the agent will break into two calls and assemble the answer as a whole, whereas a report would cover only the first half.
The choice of source is limited: a read-only account, a defined list of tables and views, a limit on selection volume, and a log — which query was sent, to what, and why.
The practical choice is simple. If questions repeat and are known in advance — a rigid scheduled query. If the wording changes, and the answer is assembled from several tables and requires clarification — the agent.
They are often combined: the agent covers one-off and composite questions, while the regular report remains stable in terms of load.
Common technical questions and concerns
The accuracy of numbers and the scope of the agent's rights are checked before implementation, not after. Below are answers to concerns raised at the evaluation stage: they concern not the model, but how the agent obtains data from the database and what it is allowed to do.
Can the agent produce a plausible but incorrect number?
The agent does not invent numbers: it forms a query, the database itself calculates the aggregate, and the model only retells the result. If the query fails, an explicit "no data" is returned, not a rough estimate. Every answer includes the query, which the engineer reproduces manually.
What happens if the database structure changes?
Between the model and the tables lies a described schema with explicit relationships. Renaming or deleting a field breaks the mapping, and the agent reports a discrepancy at startup instead of silently substituting someone else's value. The schema is corrected by an engineer, not by the model.
What permissions are granted to the agent?
A separate account: read-only, only the needed views, a limit on selection volume and execution time. Writes and schema changes are outside its rights. On PostgreSQL, this is configured with roles and a separate schema with anonymized views.
How should personal data be handled?
The agent sees views where personal fields are masked or replaced with an identifier. Access is delimited by roles, and requests are written to a log — it is visible which question led to which selection.
Can multiple sources be connected at once?
Yes: sources are described in a common registry, the agent knows each schema and matches records by keys. If one source is unavailable, the answer indicates which data was obtained and which was not.
Let's discuss the task: what to clarify before starting
Before naming timelines, we need inputs on the task, not a separate audit: how data access is structured, which questions the agent must cover, and what we consider a correct answer. This is enough to come back with a timeline estimate and a stage-by-stage work plan.
- Data sources and access method: which systems, a separate replica or production database, read-only rights, which tables and views are allowed.
- List of questions: 15–20 real formulations from employees — it shows what share of requests is typical and what requires human analysis.
- Answer format: table, summary, or chart; acceptable delay; when the agent must say "no data" rather than guess.
- Sensitive fields: what cannot be shown to roles, whether masking is needed, access separation, and a query log.
- Entry points: chat, internal portal, ticketing system — and how authentication works in each.
- Load profile: how many employees and requests per day, real-time or scheduled operation.
- Infrastructure boundaries: closed environment or cloud, security service requirements, who is responsible for access.
During the task discussion, we break the work into stages — connection to data, query validation layer, answer scenarios, validation on historical questions — and at each stage we fix a result after which we can continue or stop.
Attach the access diagram and the list of questions — we will come back with a timeline estimate and a project start plan.
