AI Apps | The .NET Blog

SQL Server 2025 as Your Agent-Ready Database: Security, Backup, and MCP in One Engine

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

I’ve been following the Polyglot Tax series by Aditya Badramraju with a lot of interest. Parts 1-3 built a compelling case for SQL Server 2025 as a genuinely multi-model database — JSON, graph, vectors, and relational data all in one engine with a unified query planner. Part 4 closes the series with the parts that actually determine whether you’d trust this architecture in production.

Spoiler: the production story is solid.

One Security Model to Rule All Data Models

Here’s the thing with polyglot stacks: when an auditor asks “prove that Tenant A cannot see Tenant B’s data,” you have to answer that question for each database independently. Five databases, five security models, five proofs.

With SQL Server 2025, you define one Row-Level Security policy and it covers every data model:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

From that point, every query — relational joins, JSON path queries, graph traversals, vector similarity searches — is automatically filtered by tenant. The engine injects the predicate into the execution plan before any data leaves storage. Your calling code doesn’t need WHERE TenantID = @id everywhere. You test the policy once.

The layers compose further: Dynamic Data Masking for columns that shouldn’t show full values to certain roles, Always Encrypted for end-to-end encryption (even DBAs can’t read it), and stored procedures as the permission boundary so agents only call what you explicitly exposed.

This is the part of the architecture that matters most for compliance-heavy SaaS. One policy, one proof.

Unified Backup = Atomic Recovery

One statement, all data models, consistent point in time:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

In a polyglot stack, point-in-time recovery across five databases means coordinating five restore operations and hoping the timestamps line up within a second or two. For financial data, that two-second inconsistency is unacceptable. With one database, one transaction log, one restore — recovery is atomic by definition.

Ledger Tables for Tamper-Evident Audit Trails

For regulated industries, you need more than “we have logs.” You need cryptographic proof that those logs weren’t modified:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

Every insert, update, and delete gets cryptographically hashed into a blockchain-style structure. You can prove to an auditor — mathematically — that a row hasn’t been tampered with since it was written. In a polyglot stack, this capability doesn’t exist uniformly across all your databases.

MCP Integration: Agents Without Hand-Coded Middleware

The series built toward this: SQL Server 2025 supports the SQL MCP Server directly, which means your agents can call the database through natural language tool calls without you writing middleware for every operation.

Combine that with stored procedures as the permission boundary and Row-Level Security enforced at the engine, and you have a model where:

Agent calls a tool (e.g., “get customer context for account 12345”)
MCP translates to the stored procedure you defined
SQL engine enforces tenant isolation and column masking automatically
Agent gets exactly the data it’s allowed to see

No middleware layer. No ad-hoc query injection risk. The engine handles authorization, not the agent.

Why This Matters for .NET Developers

If you’re building .NET services with SQL Server as your primary store, the message from this series is: you don’t need to add Redis for caching, a graph DB for relationships, or a vector store for embeddings. SQL Server 2025 handles all of that — with better operational consistency than a polyglot stack and unified security that’s actually auditable.

The MCP integration means your Semantic Kernel agents or Microsoft Agent Framework workflows can interact with your data tier through the same SQL MCP Server, with the same security guarantees you’d enforce for human queries.

Wrapping up

The Polyglot Tax series is worth reading end-to-end. Parts 1-3 prove the query planner story. Part 4 proves the production story. For .NET developers building agent-first or AI-augmented applications on Azure SQL, this architecture deserves serious consideration.

Original post by Aditya Badramraju: The Polyglot Tax – Part 4.

68 Minutes a Day Re-Explaining Code to Copilot? There's a Fix for That

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

You know that moment when your Copilot session hits /compact and the agent completely forgets what you were doing? You spend the next five minutes re-explaining the file structure, the failing test, the three approaches you already tried. Then it happens again. And again.

Desi Villanueva timed it: 68 minutes per day — just on re-orientation. Not writing code. Not reviewing PRs. Just catching the AI up on things it already knew.

Turns out there’s a concrete reason this happens, and a concrete fix.

The Context Window Lie

Your agent ships with a big number on the box. 200K tokens. Sounds massive. In practice it’s a ceiling, not a guarantee.

Here’s the actual math:

200K total context
Minus ~65K for MCP tools loaded at startup (~33%)
Minus ~10K for instruction files like AGENTS.md or copilot-instructions.md

That leaves you with roughly 125K before you type a word. And it gets worse — LLMs don’t degrade gracefully as context fills up. They hit a wall at around 60% capacity. The model starts losing things mentioned 30 turns ago, contradicts earlier responses, hallucinates file names it stated confidently 10 minutes prior. The industry calls this the “lost in the middle” problem.

Effective limit: 45K tokens before quality degrades. That’s maybe 20-30 turns of active conversation before the agent starts drifting. Which is why you’re hitting /compact every 45 minutes — not because you’ve filled 200K tokens, but because the model is already rotting at 120K.

The Compaction Tax

Every /compact costs you flow state. You’re deep in a debugging session. Shared context built up over 30 minutes. The agent knows the file structure, the failing test, the hypothesis. Then the warning hits.

Ignore it → agent gets progressively dumber, hallucinates old state
Run /compact → agent has a 2-paragraph summary of a 30-minute investigation

Either way you lose. Either way you’re narrating your own project back to it like a new hire on day one.

The cruel part? The memory already exists. Copilot CLI writes every session to a local SQLite database at ~/.copilot/session-store.db — every file touched, every turn, every checkpoint. It’s all sitting on disk. The agent just can’t read it.

auto-memory: A Recall Layer, Not a Memory System

That’s the key insight behind auto-memory: don’t build a new memory system — build a read-only query layer over the one that already exists.

pip install auto-memory

~1,900 lines of Python. Zero dependencies. Installs in 30 seconds.

Instead of flooding the context with grep results, you give the agent surgical access to what actually matters:

Operation	Tokens	What you get
`grep -r "auth" src/`	~5,000–10,000	500 results, most irrelevant
`find . -name "*.py"`	~2,000	Every Python file, no context
Agent re-orientation	~2,000	You explaining what it should know
`auto-memory files --json --limit 10`	~50	The 10 files you touched yesterday

That’s a 200x improvement. The agent skips the archaeological dig and goes straight to what matters.

The recommended flow: when you’re approaching 50-70% context usage, run /clear and then prompt with “review last sessions we discussed topic X”. Instead of burning 12K tokens on blind searches, auto-memory pulls the relevant context in 50.

Why This Matters for .NET Developers

If you’re using GitHub Copilot CLI for .NET work — scaffolding services, debugging EF Core queries, iterating on Blazor components — the context rot problem hits just as hard. Complex solutions with multiple projects, shared libraries, and deep call chains are exactly the kind of codebase where the agent loses track fastest.

The install guide walks through pointing Copilot CLI at it. It’s a one-time setup.

Honestly? 68 minutes a day back in your pocket is not a minor quality-of-life tweak. That’s almost 6 hours a week.

Wrapping up

Context rot is a real architectural constraint, not a bug that will get patched. auto-memory works around it by giving your agent a cheap, precise recall mechanism instead of expensive, noisy re-exploration. If you’re doing serious AI-assisted development with GitHub Copilot CLI, it’s worth the 30-second install.

Check it out: auto-memory on GitHub. Original post by Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.