The Birth of Bob¶
An Autonomous Agent for SQL Server Self-Healing and Network Monitoring
Ward T. Minson
For every DBA who has opened a 200-page health report at midnight and wondered if there was a better way. There is.
How to Read This Book¶
This book has three parts. Part One is the origin story: where Bob came from, and why a DBA with nearly twenty years behind him would spend eighteen months building a local AI agent when cloud tools were already sitting on his workstation. Part Two is the build: infrastructure, models, the agent architecture, the protocol that ties it together. Part Three is the road ahead: self-healing, community, and what it means to scale sovereignty beyond one server room.
If you are a senior DBA who wants to know whether any of this is safe to run near regulated data, start at Chapter 1 and read straight through. If you are a developer who wants to wire a new capability into Bob this weekend, jump to Chapter 7 and come back to the rest later. If you run Proxmox at home and your question is hardware, Chapter 4 has the sizing table you want.
The code samples in Part Two are tied to SHAs in the live Bob repository at hyp3rsoft/bob on the internal Gitea. The placeholder <sha> appears where the M15 code-sample pass will fill in verified hashes against the production system. Every infrastructure fact, IP address, hostname, and VM ID matches production as of the date on this manuscript. If something has drifted, make audit will tell you before the book ships.
Agent Vocabulary¶
A single-page glossary for the vibe coder who needs to talk to a DBA, and the DBA who needs to talk to an agent. Five terms. No hand-waving.
Query plan. The execution strategy SQL Server chooses when it runs a query. Represented as an XML tree or a graphical diagram in SSMS, it shows which indexes the optimizer selected, how it will join tables, where row-count estimates went wrong, and which operators will consume the most CPU or I/O. A DBA reads query plans to find why a query is slow. Bob reads them to decide whether a proposed fix is safe to apply. A plan with an estimated row count of 1 against a table that actually has 8 million rows is the shape of a bad plan. You learn to recognize the shapes.
Wait stats. When a SQL Server thread cannot run, it waits. The sys.dm_os_wait_stats DMV records what it waited for and how long. A session waiting on PAGEIOLATCH_SH has a disk I/O problem. A session waiting on LCK_M_X has a locking problem. CXPACKET waits at scale suggest a parallelism configuration issue. Bob's sensor layer polls wait stats continuously. They are the primary signal that tells the agent something has changed.
Deadlock graph. Two transactions, each holding a lock the other needs. Neither can proceed. SQL Server kills one and logs the event as an XML deadlock graph in the system health session. A single deadlock is a curiosity. Three deadlocks on the same two tables every hour is a design problem. Bob parses these graphs on a 5-minute cycle, correlates them against application activity patterns, and flags recurring cycles for investigation.
MCP tool. A capability registered with an agent through the Model Context Protocol. When Bob's reasoning layer decides it needs to run a diagnostic query, scan the network, or send an alert, it calls a named tool with typed parameters. The tool does the actual work and returns a structured result. Tools are the hands. The LLM is the brain deciding when to reach for them. Bob has 24 inline tools (including run_command, network_scan, docker_action, mcp_call, write_file, and notify) and 210 additional tools loaded from feature modules at startup. The mcp_call tool is the gateway to 43 registered MCP servers covering databases, infrastructure, network management, and more.
System prompt. The instructions given to an LLM before any conversation or tool message. It defines the model's role, its constraints, what it is allowed to do, and what it must never do without preconditions met. Bob's ReAct system prompt tells the model it is Ward's executive assistant and master IT/cybersecurity engineer, lists every available tool with descriptions, includes a dynamically generated summary of all 43 MCP server capabilities grouped by category, and specifies the mandatory human-in-the-loop rule: before executing any action that changes network, OS, filesystem, services, or security, check authority first and use create_task to queue it on the Kanban board for Ward's approval. It is the most important configuration file in the stack. A precise system prompt produces precise output. An ambiguous one produces creative interpretations you did not want.