Prompts, Skills, Agents

A few weeks ago, I was in a conversation with a friend about moving from Gen AI to agentic systems. We spent most of it on the architectural question: what actually changes when you go from a model answering questions to a model taking actions, and what prompt engineering meant in the Gen AI phase versus what context engineering means now.

The observation that surfaced: teams that struggle most with agentic systems are the ones that carried over their Gen AI mental model intact. They optimised their prompts, got good at crafting instructions, and assumed that scaling to agents was mostly a matter of chaining those prompts together more cleverly. That is precisely where things started to break.

The prompt is important. It is one of the most important things in an agent. But it is not the only thing, and the distinction between what a prompt does, what a skill does, what MCP enables, and what the agent itself is responsible for, that is where most agentic architectures are currently underspecified.

Gen AI mental model

Prompt
(craft the instruction, get an output)

Prompt engineering: optimise the instruction.

Agentic mental model

Agent
  |-- Control loop     (decide, act, stop, or escalate)
  |-- Memory           (in-context / retrieved / episodic)
  |-- MCP Tools        (runtime-discoverable: APIs, search, databases,
  |                     code interpreters, connectors -- anything callable)
  |-- Skill [x N]      (build-time: AI capability + evaluation harness,
  |                     versioned in shared source, tested against benchmark)
  |-- Prompt [x N]     (context boundary, output contract, failure behaviour)
  |-- Observability    (decision trace, tool call quality, goal completion)

Context engineering: design the whole information environment
the model operates in.

The prompt is not config. It is the spec.

Inside an agent, a prompt is an architecture decision, not a text string waiting to be filled in. It determines what the model can see, what it is authorised to do, and how it should behave when the input does not match expectations. Write it carelessly and it becomes a liability embedded in a running system.

Most teams treat prompts as configuration, something you tune after the real architecture is done. But in an agentic system, the prompt is where the architecture lives. The context boundary, the tool permissions, the output contract, the failure behaviour: all of it is specified in the prompt, or it is not specified at all.

Prompt changes are architecture changes. When someone edits a prompt in production to “fix a tone issue,” they are modifying a running system, usually without a review, without a version bump, and without any test coverage. If a prompt is doing more than one thing, it is two architectural decisions badly merged. That is almost always the diagnosis when a team reports that their agent is “inconsistent.”

Skills: versioned, testable, shared

A skill encodes a repeatable AI capability alongside its evaluation criteria. Entity extraction, document classification, summarisation under a specific constraint. Unlike a prompt, a skill can be run against a benchmark, regressed across model versions, and verified when an upgrade breaks something. That testability is the defining property, and it is what makes a skill worth sharing rather than rewriting per service.

Both prompts and skills can live in source code. A git repo with PR-reviewed changes is sufficient governance for both. The question is not where they are stored but whether they are shared. I have watched three engineering teams in the same organisation each rewrite the same extraction logic over six months, each convinced the previous implementation had been abandoned. A common repo they all knew about would have been enough. MicrosoftDocs/Agent-Skills on GitHub works exactly this way for Azure-specific capabilities.

For most teams, a shared repo with a benchmark folder per skill is the right first step. How the agent calls those skills at runtime is a separate question, and that is where MCP comes in.

The agent layer: control flow, trust boundaries, audit trail

An agent adds a control loop and a decision to act, two things neither prompts nor skills have. It decides which skill to invoke, on what input, and whether to continue or stop. The agent does not contain the inference logic. It coordinates it.

Most confusion lives here. Teams build chained prompts with no real branching and call them agents because the framework uses the word. A bad prompt produces a wrong output. A bad agent produces a wrong action, and in an agentic loop that action may already have been taken before anyone reviews it. An agent needs a trust boundary, a halt condition, and an audit trail that reconstructs the decision sequence. Applying prompt-level governance to an agent-level system is where organisations run into trouble, and the gap usually only becomes visible after something has gone wrong in production.

Agent > Skill > Prompt: dependency is not the same as importance

The cleaner architecture: agents orchestrate skills, skills invoke prompts. But the direction of dependency should not be confused with the direction of importance. The prompt is the foundation. Everything the agent does is constrained by what its prompts specify. If those are underspecified, the agent is underspecified, regardless of how clean the orchestration logic is.

The counterargument is that this is over-engineered for most current use cases. For a single-task pipeline, the ceremony is not worth it. The hierarchy earns its cost when multiple teams share capability, when skills need to be tested in isolation, or when a model upgrade requires selective regression. That describes most systems after six months in production. Almost no one designs for it at the start, and most teams wish they had.

Where to invest, and when

The mental model shift from Gen AI to agentic is not about prompts or skills alone.

It is about designing a system that can decide, remember, act, and be held accountable across all six layers above. Teams that treat prompts and skills as the whole design surface keep running into failures that originate elsewhere: memory never architected, tools added without revisiting trust boundaries, observability never built.

Getting the full mental model right is the precondition for everything else.