Fourth in a series on Ai and databases.

What Read-Only Advisory Actually Means

A read-only advisory system does exactly two things: it observes and it recommends. It never acts.

It can tell you a database is in a suspect state. It cannot attempt to recover it. It can tell you a backup chain is broken. It cannot re-run the job. It can identify that a transaction log is growing uncontrollably. It cannot intervene. That boundary is not a limitation. It is a deliberate design decision — and arguably the most important one when building AI for production database environments (in my opnion).

Why It Matters

Production SQL Server instances serve real applications, real users, and real business processes. A wrong action — even a well-intentioned one — can cause an outage, breach compliance, or trigger a recovery scenario nobody wanted. The only rational starting point is observation and recommendation. Let the DBA decide. Let the DBA act. The agent’s job is to make that decision faster and better informed — not to make it for them.

Trust Has to Be Structural

A trustworthy diagnostic agent is built so that the boundary between observation and action is not a setting, a configuration flag, or a prompt instruction. It is structural.

The agent should be architecturally incapable of writing to user data, running DDL, killing sessions, or executing any SQL it generated itself. Not because it has been told not to. Because the capability simply does not exist in the design. That means read-only diagnostic queries only. Pre-approved, version-controlled, human-reviewed. No runtime SQL generation reaching a cursor. The agent reasons over what it observes and hands a recommendation to a human. The human decides what happens next.

That is the only posture that earns enterprise trust — and it should be non-negotiable for any AI system pointed at a production database.