When you start working with language model–based systems, a simple pattern often appears: almost everything seems to be a .md (Markdown) file with some text instructions. The agent is a .md file, skills are .md files, instructions are .md files, and policies are .md files. That quickly raises the question: is everything in this universe just a .md file with a prompt?

There are practical reasons for using Markdown. It is human-readable, easy to version-control, and easy to review in tools like Git. Putting the “prompt” in a file separates behavior from code, which means you can adjust how an agent behaves without redeploying anything. It also lets non-developers participate by editing the .md files directly.

An agent, in this setup, is usually defined as a .md file that describes who the agent is and what it is supposed to do. You can think of it as a role description for the language model. The file typically contains the agent’s identity (“You are a customer support assistant”), its responsibilities (“Help users solve product issues”), its tone (“Be clear and calm”), and its boundaries (“Do not give legal or medical advice”).

A skill is also a .md file with a prompt, but it represents a specific capability instead of a role. A skill describes what the system can do in a reusable way. For example, a “summarize ticket” skill file might explain that when given a long support ticket, the model should return a short bullet-point summary. The file usually defines the purpose of the skill, when it should be used, what the input looks like, and what format the output must have.

An instruction is again a .md file with text, but with a narrower focus. It describes how responses should look in a particular context. Instructions might set formatting rules (Markdown, JSON, plain text), length limits, language and tone preferences, or other local constraints. For example, an instruction file might say “keep answers under 200 words, write in English, and respond in Markdown.”

A policy is a .md file that defines rules and constraints the system must always follow. It covers safety, compliance, and domain-specific restrictions. A policy file might say “do not output personal data,” “do not provide medical or financial advice,” or “refuse to help with illegal activities.” Policies typically override anything else: if an agent or skill would violate a policy, the policy should win.

So from one angle, yes: agents, skills, instructions, and policies can all be “just” .md files with prompts in them. But they are not the same thing. In practice, it helps to treat them as different concepts: agents as roles, skills as capabilities, instructions as local guidelines, and policies as global rules.

A simple project structure might mirror this way of thinking, for example:

• agents/support-agent.md
• skills/summarize-ticket.md
• instructions/chat-formatting.md
• policies/safety.md

In a typical interaction, the system might load the support agent, apply the summarize skill for long tickets, format the answer according to the chat instructions, and enforce the safety policy. All of that behavior is driven by separate .md files, each with a clear purpose.

There are limits to this .md-file view. Tools, APIs, code execution, state, and workflows usually live outside Markdown. Still, as a mental model, “a universe of .md files with prompts” is useful, as long as you remember that not everything is literally just a file. The important part is not Markdown itself, but the structure: clear definitions of agents, skills, instructions, and policies that you can read, review, and evolve over time.