Category: AI Basics

Don’t try to build “AI agents” on day one. The path that actually works is a three-phase climb. Phase 1 is a chat-driven console where the human asks and the system answers. Phase 2 adds scheduled sentinel agents that run their own checks and post structured findings to a queue. Phase 3 adds event-driven specialist agents that propose actions a human approves with one click. Skipping phases is how teams build expensive demos that never reach production. Production gets its own platform surface from day one, not on day two.

“Agents” is the word everyone wants to use. It is also the word that gets ops teams in trouble fastest. An agent that runs unsupervised against a real database is a different problem than a chat assistant that answers questions. The discipline that makes the second possible is the discipline that earns you the first.

Don’t ask an LLM to write SQL against your production schema. Curate a small set of named, parameterized queries in Markdown files with structured frontmatter, then route natural language to the right one. Aliases catch phrasing, intent families narrow the search, environment scoping prevents cross-env mistakes, and multi-section queries give you tabbed Excel exports for free. The pattern scales from twenty queries to several hundred without losing precision.

The dream of “just ask the database in English” sounds great until the model writes a join across the wrong dictionary view and locks up your test database for ten minutes. The realistic version is narrower and far more useful. Curate the queries your team actually runs, attach enough metadata to make them findable, and let the model pick the right one. The model never writes SQL. It chooses from a menu.

Letting a chat model trigger Ansible jobs is fine. Letting it trigger Ansible jobs without a registry, a force gate, prod separation, dedup, and a real audit log is how you take an environment down. This is the framework I use in a live chat-driven Oracle ops console: registry-driven job exposure, multi-play playbooks with pre-checks, hard production isolation, per-turn dedup, and intent routing for safe read-only checks. The patterns are simple. Skipping any one of them is what hurts.

Connecting a large language model to Ansible is the easy part. Most teams stop there and discover the problems the hard way. This is the framework I have settled on after running the system in a real ops environment for several months. It is opinionated. Every piece exists because something went sideways without it.

Most RAG projects fail because someone dumps a folder of PDFs into a vector store and hopes for magic. For database operations, the value is in six narrow, curated collections: SOPs, query catalog, schema notes, incident summaries, environment inventory, and guardrail rules. Index those well and a smaller model becomes useful. Skip them and even a frontier model will hallucinate confidently.

I run a chat console for our DBA team that answers questions like “who is blocking who in DEV” or “what is the approved query for top waits”. Early on I made the same mistake everyone makes. I indexed everything I could find. Confluence pages, old runbooks, vendor PDFs, scattered Word docs. The bot got worse with every document I added. Useful answers got buried under noise.

Model Context Protocol (MCP) is a small, boring contract that lets an LLM call your tools instead of trying to be your tools. For a DBA, that means the chat model never holds your DB password, never writes raw SQL into production, and never executes an Ansible playbook on its own. It asks an MCP server to do a named, validated operation. The server enforces the rules. The model just talks.

I have been building a chat-driven Oracle and Ansible console for our DBA team over the last several months. The single decision that made it safe to put in front of real engineers was choosing MCP as the boundary between the model and the systems. This post explains MCP the way I wish someone had explained it to me on day one, with no marketing.

Microsoft unveiled a significant evolution in AI-assisted software development: the GitHub Copilot coding agent. This new feature transforms Copilot from a mere code completion tool into an autonomous coding assistant capable of handling entire development tasks with minimal human intervention.

AI is evolving fast. First it helped you write code, then it summarized documents, then it started answering tech questions. Now, the next leap is here: Agentic AI.

But what exactly is it? And if you are working on database side like a  DBA or are a Cloud Architect, why should you care?

Let’s break it down—without buzzwords.