Game in the Brain

AI agents have a concept called skills — and most people (including other AI models) get it wrong. Here’s how I used Socratic prompting to walk Gemini from a confidently incorrect explanation to a genuinely useful architectural breakdown, in three rounds of questioning.

The Setup

I asked a simple question: What are AI agent skills, and how do they differ from LoRA and RAG?

When I posed the same question to Gemini, it gave me an answer that sounded authoritative but had a fundamental problem — it described tool use / function calling and labeled it “skills.”

“A skill is a specific programmatic function that an AI agent is trained to recognize and execute when needed. Instead of just generating text, the AI generates a structured command (like a JSON payload) that triggers an external system to do something.” — Gemini’s first attempt

This isn’t wrong in isolation — it’s a real thing. But it’s describing a concept that already has a name: function calling or tool use. By calling it “skills,” Gemini was collapsing two distinct architectural layers into one.

What Skills Actually Are

In modern agent frameworks, skills are something different. They’re curated methodology documents — typically markdown files — that get loaded into the agent’s context window at runtime. They don’t give the model new capabilities. They give it better judgment about how to use capabilities it already has.

Think of it this way:

• LoRA changes the model’s weights — it rewires the brain
• RAG retrieves external knowledge — it’s an open-book exam
• Tools let the model trigger external actions — they’re the hands
• Skills provide procedural expertise — they’re the training manual

An agent might already have the tool to execute Python and create files. But without a PowerPoint skill, it’ll produce mediocre presentations with wrong library choices, bad layouts, and missed edge cases. The skill contains the hard-won knowledge: use this library, avoid this pattern, structure your output this way.

The tool is the hammer. The skill is the carpentry training.

Round 1: Forcing Concrete Output

Rather than explaining all of this to Gemini and having it parrot my words back, I tried a different approach. I pointed out that what it described was already called “tool use,” then asked it to show me something tangible:

“Can you show me what an actual skill file looks like? Not the function schema or JSON payload — the actual artifact that lives on disk. If skills and tools are the same thing, why do agent frameworks maintain a separate registry of skills alongside their tool definitions?”

This worked. Gemini went from abstract definitions to producing a concrete SKILL.md example with a directory structure, step-by-step SOPs, guardrails, and a clear separation between the skill (the instructions) and the tools it references (the executable functions). It introduced the concept of dynamic context injection — the orchestrator loading skill text into the prompt only when needed.

The core architecture was now correct. But some details were embellished.

Round 2: Stress-Testing Assumptions

Gemini’s improved answer included a YAML frontmatter block with context_cost: 450 tokens, an “unloading” step where skills get surgically removed from context mid-conversation, and a label of “RAG for Skills” to describe how the orchestrator routes to the right skill.

All three of these sounded plausible. None of them were quite right. So instead of correcting Gemini, I asked it to defend its own claims:

“Where did you get that YAML frontmatter format? Is that an actual convention or did you infer it? Walk me through the mechanics of how you’d surgically remove tokens from an active transformer context window. Is vector search actually involved in skill routing, or is something simpler happening?”

Round 3: Honest Self-Correction

This is where it got good. Gemini came back with transparent, labeled corrections:

• The frontmatter: “Inferred pedagogical abstraction.” It admitted the format was a composite it constructed for readability, then pointed to Microsoft Semantic Kernel’s actual file structure as the real-world equivalent.
• Context unloading: “You cannot surgically remove tokens from an active transformer computation.” It correctly explained that LLMs are stateless, and “unloading” just means the orchestrator stops including that text in the next API call.
• RAG for skills: “Usually no, unless you are building a massive enterprise system.” For most implementations, it’s just LLM-based routing — the orchestrator lists skill descriptions and lets the model pick. Only at massive scale (thousands of skills) do you actually need vector search.
• Persona vs. skill: It correctly identified that the “You are an expert McKinsey designer” line was just a prompting technique, not what makes a skill a skill.

What Still Wasn’t Perfect

Even after three rounds, Gemini’s definition of a “minimum viable skill” was slightly over-engineered. It insisted skills need formal trigger logic, state/variable binding, and structured workflows. In practice, many real skill files are just well-written markdown instructions — no formal input schemas, no structured metadata. The trigger logic often lives entirely in the orchestrator’s external registry, not in the skill file itself.

There’s a tendency for AI models (and software engineers generally) to impose formal architecture onto what is sometimes a surprisingly simple pattern. Sometimes the answer really is just: “it’s a text file with good instructions that gets loaded at the right time.”

The Takeaway

Three rounds of Socratic pressure turned a confidently wrong answer into a genuinely useful architectural explanation. The key was never feeding Gemini the correct answer directly. Instead:

1. Round 1: Force concrete output — “Show me the actual artifact”
2. Round 2: Stress-test assumptions — “Where did you get that? Walk me through the mechanics”
3. Round 3: Demand honest self-assessment — “Label what you inferred vs. what’s real”

This pattern works because it exploits how LLMs improve with better prompting. When you ask for abstract definitions, you get confident-sounding generalities that may conflate concepts. When you ask for concrete artifacts and then poke at the details, the model is forced to reconcile its output with actual implementation reality.

The real taxonomy of agentic AI has four layers, not three: LoRA for weight adaptation, RAG for knowledge retrieval, Tools for external actions, and Skills for in-context behavioral guidance. Getting that distinction right matters — because as agents get more capable, the quality of their skills (the playbooks, not the hammers) is what separates useful output from mediocre output.

---

This post was written by summarizing a live conversation where Claude and a human collaboratively refined an explanation of AI agent architecture, then used Socratic prompting to help Gemini arrive at the same understanding independently.