AI Agents Have Started Asking Your Database Questions

Caglar Ozenc 15 min read

AI Agents Have Started Asking Your Database Questions: The Quiet Revolution of 2026, the Market Numbers and the Data Manager's 12 New Responsibilities

In the first five months of 2026 the most discussed concept in the data world was not a new LLM or a new vector database, it was AI agents. Put like that it reads as an ordinary trend sentence. But when I look at the numbers underneath, what I see are the numbers of an infrastructure shift rather than a trend. This post is the map I drew from verifiable data accumulated over the last six months: where the market is going, how MCP turned into a standard, which decision sits where among the vector engines, what an agent platform choice bills an organisation, how the EU AI Act and the KVKK timeline line up beside each other, and which 12 items a data manager has to put on the table before the second half of 2026 begins.

Opening an AI agent to your database is like taking on a grown up intern. The only difference: this intern never sleeps, reads the documentation in a second, and tests the boundary right up to the moment you set one.

PART 1: AGENTIC AI TODAY, THE NUMBERS DO NOT LIE

1. MCP now belongs to a foundation, not to a company

There are two tests that make me believe a protocol is genuinely a standard. Have its rivals adopted it, and has it left the control of a single company. The Model Context Protocol (MCP) that Anthropic announced in November 2024 passed both tests six months apart. In March 2025 OpenAI formally adopted the protocol; in December 2025 Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation. Anthropic, Block and OpenAI took founding seats; Google, Microsoft, AWS and Cloudflare joined as supporters. The company that created the protocol gave up its only signature on it, willingly.

According to The New Stack's analysis of the MCP 2026 roadmap, as of March 2026 the numbers are: 97 million SDK downloads a month, over 81 thousand stars on GitHub, more than 200 official MCP servers (among them PostgreSQL, GitHub, Slack, Google Drive, Notion, Jira and Salesforce). The headings of the 2026 roadmap also look familiar to me: enterprise production readiness, audit trail and observability, SSO integrated authentication instead of static client secrets, enterprise governance policies. That list reads as if it came off a DBA's agenda, not an LLM agenda.

What that means in practice: for an organisation investing in agents, "which MCP server do we connect to and how" is not an engineering decision, it is a control decision. An MCP native line keeps vendor changes cheap, but the authorisation decision has to end at your policy layer, not the protocol's.

2. What Gartner says: 40% of applications will contain an agent in 2026

The weight of the numbers comes from the reports Gartner published one after another. As stated in the press release of 26 August 2025, by the end of 2026 40% of enterprise applications will contain a task specific AI agent. A year earlier that share was under 5%. The forecast of 21 January 2026 carries a harder sentence: by 2028 half of organisations will adopt a Zero-Trust Data Governance model, because unverified AI generated data keeps multiplying.

In the D&A Predictions release of 11 March 2026 the three main trends of 2026 are listed as: AI agents, advances in semantics, and the convergence of data and analytics platforms. Right after that, the "Agent Sprawl" release of 28 April 2026 proposes a six item management framework: a central agent inventory, an identity and permission model, AI TRiSM tools, policy based management, runtime enforcement, performance monitoring. Putting all these lists side by side, what I see is that agents are starting to be discussed as a management discipline rather than a technology addition.

The problem an organisation without that discipline will meet in mid 2026 will be a derivative of the problem seen by those who connected their application with the "sa" account in 2003. The name changed, the logic did not.

3. 22 April 2026: five vendors announced in the same week

There is a date the sector analyses underline. On 22 April 2026 five large technology companies announced their enterprise AI agent products almost simultaneously: OpenAI Workspace Agents, Google Gemini Enterprise Agent Platform, an expanded Salesforce and Google Cloud partnership, the Anthropic Claude Agent SDK and other smaller announcements. What that tells me is that vendors are no longer in a "product competition" but in an "ecosystem standard" race. The second half of 2026 will be the six months where agent platform contracts land on the table most often.

PART 2: THE VECTOR STACK, THE MARKET HAS OPENED

4. The vector DB market is running towards $3.2 billion

The numbers in MarkTechPost's May 2026 comparison give a plain picture. The vector DB market was $2.1 billion in 2024; IDC's 2026 estimate is $3.2 billion; annual growth is over 25%. 78% of enterprise AI teams use a vector database infrastructure. In the managed segment Pinecone holds roughly 70% market share. Qdrant stood out in ANN-Benchmarks 2025 with 1840 QPS over 1 million vectors. pgvector runs at production speed inside an existing PostgreSQL up to roughly 10 million vectors.

To simplify the decision matrix you can read four engines roughly from the table below. I covered a similar decision framework in the SQL Server 2025 + Ollama demo as well.

EngineModelStrength~10M vectors, monthly cost (approx.)Natural decision point
PineconeFully managedGetting to production fast, ecosystem~$70Teams with no time for operations
WeaviateOpen source + CloudHybridising BM25, dense and filters in one query~$135Hybrid retrieval quality is the priority
QdrantRust based, open sourceHigh QPS, parallel requests~$65Scenarios where throughput dominates
pgvectorPostgreSQL extensionInside existing Postgres, SQL semantics~$45 (RDS example)Starting a v1, hybrid OLTP + retrieval

The hidden side of the table opens at the 100 million vector line. At that level Pinecone can pass $700 a month while a self hosted Qdrant or pgvector line can stay under $100. So choosing a vector DB is not only a performance decision, it is a TCO and operational capability decision.

5. Start with pgvector, move when you need to

The starting pattern I see most often in the field is this: begin the PoC and v1 stage on pgvector inside the existing PostgreSQL; move to Pinecone, Weaviate or Qdrant once query latency and hybrid search requirements appear and hit a ceiling. This pattern works for three reasons. First, starting without splitting the database keeps operational cost down from day one. Second, existing capabilities such as SQL semantics, row-level security and audit logs come as a gift. Third, the migration decision rests on data rather than feeling. Not "we heard about Pinecone, let us buy it", but "p99 latency is not enough".

A note for the Microsoft side: as I touched on in my SQL Server 2025 native vector starter guide, the SQL Server 2025 vector type opens a similar "v1 line" on top of the existing engine. The workload profile can change the decision.

Ask the vector DB question not as "which is fashionable" but as "for whom, in what time, at what cost will we move the data". In a PoC every engine shines; in production the bill and the operational fatigue tell you the difference.

6. Hybrid search: why there is no single door

In 2026 the real investment in a RAG line is not standing up a single vector store. It is building a hybrid retrieval line: combining BM25, dense vectors and metadata filters in one query. Weaviate leads on squeezing that into a single query, but as an architectural decision this is independent of which vendor you pick. The typical problem for teams that do not design hybrid search is this: the model returns not "the right answer" but "the answer that is close as a vector". Seeing 95% recall in a PoC with cherry picked queries tells you nothing about how it will perform in production. Retrieval quality is meaningful against a real user query distribution, not against a single benchmark number.

PART 3: CHOOSING AN AGENT PLATFORM, THE DECISION ARITHMETIC

7. Copilot Studio and Agentforce: two philosophies, two bills

In Smartbridge's 2026 comparison and CRM Curator's platform analysis there are two names sharing the field. A simplified decision matrix is below.

DimensionMicrosoft Copilot StudioSalesforce Agentforce
CoreIntegrated with Microsoft 365 + Azure + Power PlatformCRM native, Atlas Reasoning Engine
Identity / permissionsEntra ID, existing Microsoft RBACSalesforce user model plus permission sets
PricingCopilot Credit packs: $200 a month for 25,000 creditsAgentforce Add-on: $125/user/month; Agentforce 1: $550/user/month (1M Flex Credits included), an extra 100K Flex Credits $500
Natural marketAn agentic layer on the Microsoft stackAutonomous decisions inside a CRM workflow
Data access logicThrough Microsoft Graph + Fabric/SQL/365CRM objects, through Data Cloud

When deciding, to my mind you look at the existing data stack before the technical capability. If you are in the Microsoft ecosystem, Copilot Studio is the natural choice. If your CRM workflows end in Salesforce, Agentforce produces value faster. But no decision gets corrected "after the vendor is chosen"; as I wrote in my ETL vs ELT post, a modern stack decision is taken together with the direction of the data flow.

8. An MCP native line or a vendor locked stack

This dimension sits above the previous table. Are you building the agent on a vendor's closed platform, or on an MCP native line? The MCP native route offers flexibility and low lock-in; the vendor platform brings fast time to value but hands platform authority to the vendor. The model I have seen work best in the field is usually a hybrid: critical data paths MCP native, the UX layer close to the user built with vendor agents.

PART 4: THE SECURITY SURFACE, VERIFIED THREATS

9. Multi-tenant RAG leakage: the 83% nobody talks about

A sad ratio keeps repeating in the security reports published through 2026: cross tenant data leakage risk is found in roughly 83% of multi-tenant RAG systems. Unpacked, that means the data of the SaaS provider's customer A can be read by customer B's agent without being asked for. In the classic RDBMS world this problem has been solved with row-level security for years, but on the vector side it is often left out of the design.

The fix does not look like it can be written in a single sentence, but at its core it stands on three legs. The tenant identity has to be embedded into the metadata during embedding generation; it has to be made mandatory as a filter in the hybrid search query; and policy enforcement has to be applied at query time. Tenant isolation left as "we will add it later" is not a defence at the moment of a breach.

10. The three threats OWASP draws

In the framework OWASP published for the LLM and agent ecosystem, the three fundamental threats of 2026 are: goal hijacking, making the agent perform an unintended task through prompt injection; tool misuse, using the tools the agent is authorised for outside their purpose; and identity and privilege abuse, gaining access to data beyond the scope of the identity the agent is bound to. In the field these three are usually not separate incidents but a chain. A prompt injection (goal hijacking) leads to stepping outside a tool call (tool misuse); and there, the wider the agent's permission scope (privilege abuse), the bigger the damage.

11. Knowledge base poisoning

As underlined in CSO Online's analysis of RAG pipeline security and Adversa AI's May 2026 resource collection, polluting externally sourced knowledge bases with manipulated content (retrieval poisoning) has become one of the main attack classes. There is really only one thing to say here: anyone with write access to internal knowledge bases is a potential prompt author. SharePoint, Confluence, product documentation, customer support articles, every source feeding your RAG line has to be included in the content verification matrix. Otherwise the agent returns the wrong answer with a smile on its face, and the organisation pays the reputational cost for years.

The agent's security perimeter is not the model's perimeter. It is the range of sources in the RAG line, the metadata filters of the vector store, and who can write to the audit log.

PART 5: THE AGE OF REGULATION, EU AI ACT, KVKK AND TURKEY

12. EU AI Act: 2 August 2026 is approaching

According to the European Commission's official documents, the EU AI Act came into force on 1 August 2024. From that point the timeline opens in stages.

DateWhat comes into force
2 February 2025Prohibited AI practices and AI literacy obligations
2 August 2025Governance rules for General Purpose AI (GPAI) models
2 August 2026Full application date of the EU AI Act
2 December 2027High risk systems (biometrics, critical infrastructure, education, employment, migration, asylum, border control)
2 August 2028AI systems embedded in products (lifts, toys and the like)

For those looking from Turkey, the point highlighted in Lexology's impact analysis matters: Turkish companies may fall outside the direct scope of the EU AI Act, but organisations serving customers in the EU or selling products into the EU market come into scope indirectly. So the 2 August 2026 timeline is not only an EU timeline; it is also the timeline of Turkish organisations doing business with the EU.

13. Turkey: from soft law towards a legal framework

According to Nemko's summary of AI regulation in Turkey, Turkey is developing a risk based framework in parallel with the EU. The building blocks currently in hand are: the Recommendations on the Protection of Personal Data in the Field of Artificial Intelligence published by KVKK in 2021 (privacy by design, data minimisation, a legal basis for training data and so on); YOK's ethical guidelines in the academic context; and KVKK's Board Decision 2019/10 dated 24.01.2019 (breach notification to the Authority within 72 hours of becoming aware). On the legislative side a risk based AI law is being worked on.

The practical upshot: an organisation in Turkey investing in agents in mid 2026 cannot lean on the comfort of "the legislation is not written yet". The framework in hand consists of the trio "2021 KVKK Recommendation + Board Decision 2019/10 + the shadow of the EU AI Act", and it has to act according to that trio. As I wrote in "Why AI Projects Fail", data quality and compliance often shape an organisation's risk surface more than the model's performance does.

PART 6: THE DATABASE MANAGER'S NEW ARCHITECTURAL FRAME

The concrete counterpart of the picture above is that control comes down to the database level. Seven years ago the most advanced security investment on the DBA side was row-level security. As of 2026 four more layers sit on top of it: agent identity, just-in-time access, detailed auditing per agent call, and retrieval policy.

14. Row-level security and just-in-time access, the practical counterpart on the SQL side

On the SQL Server side, giving a row filter per agent identity settles into a pattern like the one below. It sits on top of the identity layers I described in my SQL Server authentication post; on the PostgreSQL side the same logic is written with CREATE POLICY.

-- 1) Agent kimliği için filter predicate
CREATE FUNCTION dbo.fn_tenantFilter(@tenant_id INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS allowed
WHERE @tenant_id = CAST(SESSION_CONTEXT(N'tenant_id') AS INT);

-- 2) Security policy
CREATE SECURITY POLICY dbo.AgentTenantPolicy
ADD FILTER PREDICATE dbo.fn_tenantFilter(tenant_id) ON dbo.CustomerData;

Every time the agent opens a session it sets its tenant_id with an sp_set_session_context call and the filter engages automatically. On the just-in-time side the logic goes like this: when the agent is about to make a tool call, a short lived credential (5 to 15 minutes) is generated and automatically revoked once the call finishes. An agent bound to a fixed, broadly privileged service account is now a pattern below minimum hygiene.

15. The agent audit log schema, the only witness in a breach

The example schema I recommend is below; it needs standardising per organisation.

CREATE TABLE dbo.AgentToolCallAudit (
  audit_id          BIGINT IDENTITY PRIMARY KEY,
  ts_utc            DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(),
  agent_id          NVARCHAR(128) NOT NULL,
  agent_run_id      NVARCHAR(128) NOT NULL,
  tool_name         NVARCHAR(128) NOT NULL,   -- MCP sunucusu / araç
  tool_input_hash   NVARCHAR(64),             -- prompt + parametre hash
  tenant_id         INT,
  rows_affected     INT,
  latency_ms        INT,
  identity_scope    NVARCHAR(256),            -- scoped token sahibi
  policy_applied    NVARCHAR(256),            -- hangi politika eşleşti
  outcome           NVARCHAR(32),             -- success / denied / error
  outcome_detail    NVARCHAR(MAX)
);

Two points in that schema are non negotiable to my mind. First, the log has to be written to immutable storage (WORM or blob immutability). Second, the log door has to be an independent store inside the organisation, not left solely to the cloud provider's management layer. As I wrote in the 2026 Data Platform Manifesto, if there is a single witness at the moment of a breach it is the log; but if it is unclear who can write to and change that log, the witness becomes a weakness rather than a defence.

PART 7: THE 12 ITEM AGENT READY DBA CHECKLIST

Putting together the verified facts gathered over the last six months, the 12 items a data manager has to have on the table before entering the second half of 2026 are:

  1. Has an inventory of the agents in active use and under evaluation been produced?
  2. Is the list of MCP servers each agent connects to, and its contract, written down?
  3. Has agent identity been separated from the broadly privileged fixed service account?
  4. Has the just-in-time access model (short lived tokens, scope limited permissions) gone into operation?
  5. Are row-level security and dynamic data masking active in front of the agent's door?
  6. Has tenant_id been made mandatory in the embedding metadata on the RAG line? Is the hybrid search only queried once that filter passes?
  7. Was the vector DB choice (pgvector / Pinecone / Weaviate / Qdrant / SQL Server 2025 native vector) made on TCO and operational capability?
  8. Is there a written inventory of who can write to knowledge base sources, and a content verification procedure?
  9. Is the agent call audit log schema on immutable storage and in an independent storage layer?
  10. Has an internal threat model been written for OWASP's three agent threats (goal hijacking, tool misuse, identity abuse)?
  11. Has the 72 hour notification flow required by KVKK Board Decision 2019/10 been adapted for agent incidents?
  12. Is the EU AI Act 2 August 2026 timeline in the preparation file for customers served in the EU?

Adding the questions "who owns it?", "what is the deadline?" and "where is the evidence document?" to each of these 12 items and tracking them in a single table is the most useful approach to my mind. When the audit arrives, that table is the file it asks for.

CLOSING: THE DBA IS NOT DEAD, THE TEAM JUST HAS A DIFFERENT NAME

Data management has changed its definition twice in the last twenty years. First it was "the DBA keeps the system up". Then it became "the DBA is a performance and data quality engineer". 2026 is the year of the third wave. The DBA now sits at the centre of the team deciding what the agent will see, what it can do and through which door it enters at which moment. This role does not replace the CISO or the CDO. But a DBA now sits at both of their tables.

What the market says is clear: by the end of 2026 40% of enterprise applications will contain a task specific agent, the vector DB market is running towards $3.2 billion, MCP has settled into the Linux Foundation as an infrastructure standard, and the EU AI Act comes fully into force on 2 August 2026. Those four numbers are enough on their own: a data team not built around agents will spend the next six months catching up with the teams that were.

In an organisation that has not invested in data quality and compliance, the technology that pulls the trigger fastest will be the agent. I put that sentence in when writing "Why AI Projects Fail"; today it deserves another line underneath. Because the intelligence that finds forgotten data fastest is now the agent itself.

Winners win at the planning table, not in the fire. The second half of 2026 will belong to the organisations that set their table around agents.

Primary sources cited in this post:

Caglar Ozenc — Microsoft Data Platform MVP, founder of DMC Bilgi Teknolojileri, database consultant. Contact.

Related posts:

  1. A Short History of Vector Search Inside the Database
  2. SQL Server Diagnostics With MS SQL-Health MCP
  3. SQL MCP Server: Secure Setup in 3 Steps
  4. 20 Million Rows, Three Engines: Measuring Doris, PostgreSQL and SQL Server
  5. Why Is SQL Server Agent Job History Empty? The sysjobhistory Problem

Leave a comment

Comments appear after approval. Your email is not published and not shared with third parties.