AI Agents

Yesterday I gave a talk for MSSQLTips called “Building a DBA Agent for Your SQL Server Estate”. I’ll drop the recording into this post once it’s published. What I want to do here is pull the whole thing together in writing: the demos, what I actually ran against a live SQL Server estate, and the argument I’m making when I say an AI agent can be trusted near production.

If you’ve been following along, this is the third post in what’s turned into a series. In Giving AI Agents Visibility Into SQL Server with MCP, I built sql-mcp-server, a custom MCP server that gives an agent real DMV access. I said at the end of that post that skill files were coming in a follow-up also in Using Claude Code as a Database SRE Agent, I showed a skill file catching a silently unprotected DR instance against the Everpure Fusion fleet API and how to build compliance and observability reports quickly. So here we are.

I’ve been thinking a lot lately about what it actually takes to make an AI agent genuinely useful for database work, both for administration and for application access to the data tier. Writing the T-SQL code is the easy part. A coding assistant can do that out of the box. The hard part is giving it visibility into a running SQL Server: which sessions are blocked right now, where the wait stats are pointing, which indexes the optimizer is begging for. Without that, the agent is just guessing. With application access, an agent can propose how things should work, but what if we had tools that added context describing the agent database’s schema and what the entities actually mean to the application when interacting with the database agentically?