LLM as CPU, agent as OS

The more I build with Claude Code, the less it feels like a chatbot. It reads files, calls APIs, manages context, schedules tool calls, enforces permissions. That’s not a chat interface. That’s an operating system.

The analogy isn’t decorative. It’s structural.

The stack

The LLM is the CPU. Raw processing. It takes instructions, reasons through them, and produces output. It doesn’t know what’s on your filesystem. It has no memory between sessions. It forgets everything the moment the context window closes. A CPU without an OS.

The agent is the operating system. Claude Code, Cursor, Codex — these are the OS layer. They manage the context window (RAM), handle the tool call loop (process scheduling), read and write files (I/O), and mediate between you and the model. The LLM decides what to do. The agent makes it happen.

Skills, commands, and MCPs are the applications. They extend what the agent can do. Domain knowledge, predefined workflows, external connectivity. You install them, the agent gains new capabilities.

Skills

A skill is a folder with a SKILL.md and optional reference material. It encodes domain knowledge — how to approach a type of task, what conventions to follow, which tools to use.

Skills load on demand. The agent doesn’t carry every skill in context at all times. When a request matches a skill’s trigger, the agent loads those instructions — like an OS loading a program into memory when you launch it.

I have a content-writing skill for this blog. It contains the frontmatter schema, tag taxonomy, voice guidelines, formatting rules, and an editorial checklist. When I ask Claude Code to write a post, that skill loads automatically. I don’t re-explain the rules each session.

I also have skills for the OpenSpec workflow — proposing changes, applying tasks, archiving completed work. Each one teaches the agent a specific procedure with its own conventions and guardrails.

.claude/skills/
├── content-writing/       # Blog voice, formatting, editorial checklist
├── openspec-apply-change/ # Implement tasks from a change proposal
├── openspec-archive-change/
├── openspec-explore/      # Thinking partner for discovery
└── openspec-propose/      # Create new change proposals

Commands

If skills are applications, commands are shell scripts — predefined workflows you invoke by name. A command is a markdown file in .claude/commands/ that expands into a full prompt when you type its slash command.

The distinction: a skill provides knowledge the agent draws on when relevant. A command is an action you trigger deliberately.

For this blog, I run /blog:propose with raw notes or a topic. Claude Code gets the full brief template, asks clarifying questions, and writes a structured brief. I review and edit the brief — strip anything I haven’t verified, sharpen the angle, add sources I’ve actually read. Then /blog:write reads the brief, loads the content-writing skill, and produces the .mdx file. /blog:archive runs a final build verification and closes the change.

.claude/commands/
├── blog/
│   ├── propose.md    # Create a brief for a new post
│   ├── write.md      # Write the post from a brief
│   └── archive.md    # Verify build and archive the change
└── opsx/
    ├── propose.md    # Propose a code/infra change
    ├── apply.md      # Implement tasks from a proposal
    ├── explore.md    # Think through a problem
    └── archive.md    # Archive completed work

You don’t type out a 20-step deployment every time — you write a script and run it. Commands do the same for agent workflows.

MCPs

Model Context Protocol servers are the connectivity layer. Where skills provide knowledge, MCPs provide access to external systems through a standard protocol.

Each MCP server exposes tools (functions the agent can call), resources (data it can read), and prompts (templates for common interactions). The agent discovers what’s available and decides which tools to invoke based on the task.

My current setup:

MCP Server	What it provides
GitHub	Repository management, PR creation, issue tracking, code search
Supabase	Database queries, migrations, project management
Context7	Up-to-date library documentation and code examples
Firecrawl	Web scraping and content extraction
Tavily	Web search and research
cOS	Personal knowledge base — documents, notes, structured collections

I don’t tell Claude Code “use the GitHub MCP to create a PR.” It figures out the right tool from context, the same way an OS routes a file operation to the right driver.

The line between skills and MCPs: skills define what to do (procedural knowledge). MCPs define how to connect (tool access). A skill might say “create a PR with a conventional commit message.” The GitHub MCP provides the API call that makes it happen.

Why this matters

Every major computing paradigm eventually needed an OS. Hardware got operating systems. Servers got hypervisors. Containers got Kubernetes.

If you’re using an agentic tool, invest accordingly:

• Build your OS config. A CLAUDE.md and context directories tell the agent how to behave in your project. Without them, every session starts from zero. I wrote about the skills involved in the prompt stack.
• Package repeated workflows as skills. If you explain the same process session after session, that’s a skill waiting to be written.
• Connect MCPs for the tools you actually use. GitHub, your database, your docs. Don’t install everything — connect what matches your workflow.
• Let the agent orchestrate. The value isn’t in any single skill or MCP. It’s in the agent combining them — reading an issue, querying the database, generating code that follows your conventions, and opening a PR.