Build an AI Agent in 10 Minutes with Claude Code

Build an AI Agent in 10 Minutes with Claude Code

   July 25, 2026       Codez Tech

---

Ask most people how to build an AI agent and you get a shopping list: an orchestration framework, a graph library, a vector store, a week of glue code, and a diagram nobody can maintain. That was a fair answer eighteen months ago. It is now the slow way to do it, and the frameworks are increasingly the part you rip out later.

The hard part of building an agent has moved from orchestration code to specification. You don’t write the loop anymore — you assemble the agent from files Claude Code already knows how to load, and the scaffolding really is six steps you can finish in one sitting.

Six steps, no orchestration code — just files Claude Code loads for you.

The below topics are covered in this blog -
1. Why “building an agent” got dramatically simpler
2. Step 1 — Install Claude Code
3. Step 2 — Build context with CLAUDE.md
4. Step 3 — Build memory
5. Step 4 — Build skills
6. Step 5 — Build the agent team
7. Step 6 — Run on autopilot with Routines
8. The four building blocks, compared
9. Common mistakes
10. The Takeaway

1. Why “building an agent” got dramatically simpler

An agent is a control loop wrapped around a model: decide the next action, take it, observe the result, repeat until done. You used to write that loop yourself. Claude Code ships it. What you supply now is context and constraints — who the agent is, what it knows, what it can touch, and when it should stop — expressed as plain markdown files the tool discovers and loads on its own.

That is the whole shift. Instead of coding orchestration, you author four kinds of file: persistent context (CLAUDE.md), accumulated memory, on-demand skills, and specialized subagents. The roadmap below is the map for the rest of this post — six steps, in order.

The six-step build: install, context, memory, skills, agents, autopilot.

2. Step 1 — Install Claude Code

This is the foundation everything else sits on. As of mid-2026 the recommended install is the native installer, which has zero dependencies — no Node.js, no npm — and auto-updates in the background. The npm package is still fully supported if you prefer to pin versions or standardize on npm across a team; that route needs Node.js 18 or later.

# Recommended: native installer (no Node.js needed)
# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# Alternative: npm (requires Node.js 18+)
npm install -g @anthropic-ai/claude-code

# verify
claude --version

You authenticate in the browser on first launch with a Pro, Max, Team, Enterprise, or Console account — the free Claude.ai plan does not include Claude Code. Pick whichever surface fits your workflow: the terminal, the desktop app, or the VS Code side panel. They read the same files, so nothing below is surface-specific.

3. Step 2 — Build context with CLAUDE.md

CLAUDE.md is the always-on onboarding doc. Claude Code reads it at the start of every session and re-reads the project-root copy after a compaction. It can live at several scopes: a project file (./CLAUDE.md, shared via git), a personal file for every project (~/.claude/CLAUDE.md), and a gitignored CLAUDE.local.md for private notes. Claude walks up the tree and concatenates what it finds.

# CLAUDE.md

## Role
Senior backend engineer on a TypeScript / Node service.

## Voice
Terse. No filler. Explain trade-offs, not basics.

## Banned
No new dependencies without asking. Never touch src/legacy/.

## Defaults
Tests with vitest. Conventional commits (feat:, fix:, chore:).

The discipline that matters: CLAUDE.md is billed to context on every single turn. Put conventions and pitfalls here — the things that differ from tool defaults — not facts Claude can rediscover from the codebase in one session. A bloated CLAUDE.md quietly taxes every request and, past a couple hundred lines, actually reduces how well Claude follows it.

4. Step 3 — Build memory

Separate from CLAUDE.md, Claude Code keeps its own auto memory: notes it writes based on what it learns and the corrections you make. Each project gets a directory at ~/.claude/projects/<project>/memory/ containing a MEMORY.md index plus per-topic markdown files. The index loads at session start; the topic files load on demand. Run /memory to browse, edit, or delete anything it has saved — it is all plain markdown.

~/.claude/projects/my-service/memory/
    MEMORY.md          index: what is stored where
    debugging.md       fixes to problems solved once
    conventions.md     patterns inferred from the code
    preferences.md     how you like to work

The mental split: CLAUDE.md is your instructions to Claude; auto memory is Claude’s notes to itself. Because it accumulates automatically, the same mistake tends not to land twice — but treat it as advisory, not enforcement (more on that in the mistakes section).

5. Step 4 — Build skills

A skill is a folder with a SKILL.md file (plus optional scripts) that Claude Code loads on demand when your task matches its description. It turns a 200-word workflow you keep re-typing into one reusable, discoverable capability. Personal skills go in ~/.claude/skills/; project skills go in .claude/skills/ and version-control with the repo.

~/.claude/skills/changelog/SKILL.md

---
name: changelog
description: Summarize recent commits into a grouped changelog.
             Use when asked to write release notes.
---
Read the last 20 commits. Group by feat / fix / chore.
Output markdown with a heading per group. Omit merge commits.

The single most important line is the description. It is the trigger — Claude reads it every session and pulls in the body only when the current task matches. A vague description means the skill silently never fires. Describe the situation to use it in, not just what it does.

6. Step 5 — Build the agent team

A subagent is a specialized Claude instance with its own context window, its own tools, and one job. It runs in isolation and returns only its result, which keeps your main conversation clean. Files live in .claude/agents/ (project) or ~/.claude/agents/ (personal), one file per agent, and each can pin its own model.

.claude/agents/qa-gate.md

---
name: qa-gate
description: Reviews a diff and fails anything below 95/100.
             Use after any code change.
model: sonnet
tools: Read, Grep, Bash
---
You are a strict reviewer. Score the diff out of 100 on
correctness, tests, and clarity. State the score. If below
95, list exactly what must change. Do not soften.

A workable division of labour: heavier models for the roles that analyse and plan, faster models for the roles that execute, and a hard QA gate that fails work below a fixed bar. Match the model to the job instead of paying for the top model on every step. The key constraint is scope — one file, one job. That is what makes the team debuggable.

7. Step 6 — Run on autopilot with Routines

The final step turns your agent team into something that runs without you sitting there. Routines let you schedule work to run on Anthropic’s cloud rather than your laptop — set it once and walk away. Anthropic showcased cloud Routines and dynamic workflows at Code with Claude Tokyo in 2026 as a way to move recurring agent work off the local machine.

Concretely, this is where a scheduled trigger fires a skill or an agent on a cadence — a daily summary at 8am, a weekly report dropped into your docs — on the cloud, not a machine you have to keep awake. This surface is newer and moving fast, so confirm the current syntax and availability in the docs before you wire a production job to it.

8. The four building blocks, compared

Dimension	CLAUDE.md	Auto memory	Skills	Subagents
What it is	Always-on instructions	Claude’s own notes	On-demand workflow	Isolated specialist
Loads when	Every session start	Index at start, rest on demand	When task matches description	When invoked
Who writes it	You	Claude, automatically	You	You
Lives at	./CLAUDE.md, ~/.claude/CLAUDE.md	~/.claude/projects/<project>/memory/	~/.claude/skills/ or .claude/skills/	.claude/agents/ or ~/.claude/agents/
Scope	Project or user	One repository	Project or user	Single task
Best for	Conventions and pitfalls	Learnings you didn’t write down	Repeated multi-step workflows	Parallel or context-heavy jobs
Token cost	Paid every turn — keep lean	Index every session	Near zero until triggered	Separate context — protects main
Version-controlled?	Project copy, yes	No — local, gitignore it	Project copy, yes	Project copy, yes
Failure mode	Bloat taxes every request	Advisory, not enforced	Weak description never fires	Too many tools, wrong pick

9. Common mistakes

1. Putting everything in CLAUDE.md. It is always-on context, so every line is billed on every turn and, past a couple hundred lines, adherence actually drops. Facts Claude can learn from the repo in one session belong in the code or in auto memory — CLAUDE.md is for conventions and pitfalls only.
2. One mega-agent with every tool. Tool-selection accuracy degrades as the tool count climbs; the agent starts confidently picking the wrong one. One file, one job, a narrow tool set. Route between focused subagents instead of overloading a single one.
3. Treating skills as prompts. A skill is on-demand context gated by its description. If the description does not name the situation to use it in, the skill never triggers and you never notice. Write the trigger, then the task.
4. Assuming memory enforces rules. Auto memory is advisory context the model usually follows — not a guarantee. If a rule must hold every time (never touch a directory, never skip a check), use a PreToolUse hook, which actually blocks the action, not a memory line that merely suggests it.
5. Running Routines as fire-and-forget. A scheduled agent with write access and no QA gate scales your mistakes on a timer. Put a review step between the agent and anything it can publish, commit, or send — especially once it runs unattended on the cloud.

10. The Takeaway

The six steps are just files: install the tool, write the context, let it build memory, package your workflows as skills, split the work across scoped subagents, and schedule the whole thing. No orchestration framework, no graph library, no glue.

Be honest about the ten minutes, though: that is the scaffold, not the finished agent. Standing up the structure is genuinely fast now. Making it good — tight CLAUDE.md, skills whose descriptions actually fire, subagents scoped so tool selection stays accurate, a QA gate that holds — is iteration, and that is where the real work lives. The teams that win are not the ones who scaffolded fastest. They are the ones who kept tuning the specs.

About the Author
Atique Ahmed — Principal AI Architect. 7x Microsoft MVP and Guinness World Record holder for Programming Excellence. Founder of Codez Tech.
atiqueahmed.com · LinkedIn · GitHub

This is Day [DAY_NUMBER] of a daily GenAI and agentic AI series on CodezTech.

Read More

MCP vs RAG vs Skills : Complete Guide to AI Agent Architecture

   July 24, 2026       Codez Tech

---

MCP vs RAG vs Skills : Complete Guide to AI Agent Architecture

Everyone building AI agents in 2026 runs into the same three words within the first week — MCP, RAG, and Skills — and almost everyone assumes they have to pick one. They don't. These are three different layers of the same stack, and picking the wrong one is the single most expensive architecture mistake I see on enterprise engagements.

In one line: RAG gives an agent knowledge. MCP gives it access. Skills give it judgment.

4. MCP vs RAG vs Skills — Full Comparison

MCP vs RAG vs Skills — Architectures that power smarter AI agents

The below topics are covered in this blog -

1) What is MCP (Model Context Protocol)?
2) What is RAG (Retrieval Augmented Generation)?
3) What are Agent Skills?
4) MCP vs RAG vs Skills — full comparison table
5) When to use MCP vs RAG vs Skills — the decision rule
6) How the three layers compose in a real agent
7) Building your first Skill — SKILL.md example
8) Common architecture mistakes and how to avoid them

1. What is MCP (Model Context Protocol)?

MCP is an open, JSON-RPC based client-server protocol that lets an AI agent talk to live external systems — a database, a CRM, a ticketing system, Slack, a search API — through one standardized interface. It was created by Anthropic in late 2024 and later donated to the Agentic AI Foundation under the Linux Foundation, and it is now supported across all the major model vendors.

The architecture has three parts:

• MCP Host — the application the user is talking to (Claude Desktop, your own agent app, an IDE).
• MCP Client — lives inside the host, maintains one connection per server, and decides which server to route a request to.
• MCP Server — the service that actually exposes capabilities. It publishes three primitives: Tools (actions the agent can invoke), Resources (data the agent can read), and Prompts (reusable templates).

The important word here is live. An MCP server holds real authentication, real session state, and returns data as it exists right now. That is why order status, inventory counts, and open incidents belong behind MCP and nowhere else.

A minimal MCP server configuration looks like this:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost/orders"]
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_BOT_TOKEN": "xoxb-your-token" }
    }
  }
}

That is it. The agent now has live, authenticated access to two systems it had no idea existed thirty seconds ago.

2. What is RAG (Retrieval Augmented Generation)?

RAG solves a completely different problem: the model was never trained on your documents. Your policy manuals, product specs, past support tickets, and internal wikis are invisible to it.

The pipeline has two phases.

Indexing (offline, runs once and then on a schedule):

1. Load the source documents.
2. Chunk them into passages — typically 300 to 800 tokens with some overlap.
3. Embed each chunk into a vector using an embedding model.
4. Store the vectors in a vector database (pgvector, Pinecone, OpenSearch, Weaviate, Chroma).

Retrieval (online, runs on every query):

1. Embed the user's query with the same model.
2. Search for the nearest chunks — ideally hybrid, combining vector similarity with keyword BM25.
3. Rerank the candidates with a cross-encoder to push the genuinely relevant ones to the top.
4. Augment the prompt with those chunks and generate an answer with citations.

The thing to internalise: a vector index is a photograph, not a window. It is as fresh as your last indexing run and no fresher. If the answer must reflect the world right now, RAG is the wrong tool.

3. What are Agent Skills?

A Skill is the least glamorous and most underrated of the three. It is a folder. Inside it sits a SKILL.md file with YAML frontmatter and a set of instructions, plus optional scripts, templates, and reference documents.

The mechanism that makes it clever is progressive disclosure. The agent only ever holds the skill's name and description in context — a few dozen tokens. When a task matches that description, the full skill body loads on demand. Near-zero context cost until it fires.

---
name: incident-report
description: Writes a post-incident report. Use whenever the user asks
  for an RCA, incident summary, outage write-up, or postmortem.
---

# Incident Report Skill

## Required sections, in order
1. Impact summary (who was affected, for how long, revenue impact)
2. Timeline in UTC, one line per event
3. Root cause - the technical cause, not the human who typed it
4. Detection gap - why did we not know sooner
5. Action items, each with an owner and a date

## Rules
- Never name individuals. Name teams and systems.
- Severity uses our P0-P4 scale, defined in ./reference/severity.md
- Use the template in ./templates/incident.md
- If the timeline has gaps, ask before writing. Do not guess.

That file is roughly thirty lines. It is version controlled in Git, reviewable in a pull request, portable across agent runtimes, and it costs you nothing until the moment somebody says the word "postmortem." Now compare that to embedding your incident-management handbook into a vector store and praying the right paragraph gets retrieved.

4. MCP vs RAG vs Skills — Full Comparison

Dimension	RAG	MCP	Skills
Core problem	Missing knowledge	Missing access	Missing procedure
Nature	Retrieval pipeline	Live protocol, running server	Static portable folder
Data freshness	As fresh as the last index run	Real time, every single call	Stable for weeks or months
State & auth	None	Yes — sessions, tokens, scopes	None
Can take actions?	No, read only	Yes	Only through tools it invokes
Context cost	High — chunks fill the window	Medium — tool schemas occupy context	Very low until triggered
Infrastructure	Embedding model + vector DB + pipeline	A deployed, monitored server process	A file in a repo
Cost driver	Embedding + storage + retrieved tokens	Server hosting + API calls	Effectively zero
Latency added	Retrieval + rerank, typically 100–500ms	Network round trip per tool call	Negligible
Change cost	Re-chunk and re-index everything	Version the server, redeploy	Edit the markdown, commit
Fails when	Chunking is poor, retrieval misses	Server is down, token expired, tool sprawl	Description doesn't match the task
Governance	Index-level ACLs, hard to get right	Strong — real auth, scopes, audit logs	Weak — it's just a file, use Git review

5. When to Use MCP vs RAG vs Skills

Ask these three questions in this exact order about whatever capability you are trying to add:

Question 1 — Does it change between invocations?
If the answer must reflect the world right now — an order status, a live inventory count, an open incident, a current account balance — you need MCP. Nothing else will do. A vector index cannot tell you whether a server is on fire at this moment.

Question 2 — Is it a large, slow-moving body of text the model was never trained on?
Policy documents, product manuals, three years of resolved tickets, research archives. That is RAG. The test is volume plus stability: too big to paste into a prompt, stable enough that a nightly index run is acceptable.

Question 3 — Is it procedure, judgment, formatting, or house style?
"How we write an incident report." "Our SQL naming conventions." "The seven checks before a deployment note ships." That is a Skill — and it is almost always the cheapest thing you have not tried yet.

6. How the Three Layers Compose in a Real Agent

In production this is never a choice. It is a stack. Take a customer support agent for an e-commerce company:

• MCP layer — connects to the order database and the ticketing system. Live account state, live order status, and the ability to actually issue a refund or update a record.
• RAG layer — retrieves from product documentation and the archive of resolved tickets. The slow-moving institutional knowledge.
• Skills layer — encodes the escalation policy. What counts as a P1. The tone for a refund message. Which fields must be filled before a ticket can close. The exact template for the customer summary.

Now remove one layer at a time and watch the failure mode appear:

• No MCP → the agent confidently hallucinates order status. Customer is told their package shipped. It did not.
• No RAG → the agent invents product behaviour that does not exist and creates a support ticket about its own answer.
• No Skills → the agent does technically correct things in a wildly inconsistent way. Every refund email has a different tone. No two tickets close the same. Nothing is auditable.

That third one is the sneaky failure, because nothing visibly breaks. It just quietly becomes unreviewable.

7. Building Your First Skill

Skills are the fastest win, so start there. The folder structure is:

.claude/skills/
  incident-report/
    SKILL.md              # required: frontmatter + instructions
    reference/
      severity.md         # loaded only when SKILL.md points to it
    templates/
      incident.md
    scripts/
      fetch_timeline.py   # optional executable helper

Three rules that decide whether your skill actually works:

1. The description is the entire trigger mechanism. It is the only part the agent sees until the skill fires. Write it as "Use when the user asks for X, Y, or Z" — concrete trigger phrases, not an abstract summary. A vague description means the skill never loads, and you will spend an afternoon debugging a prompt when the actual bug was one sentence of metadata.
2. Keep SKILL.md under roughly 500 lines. Push detail into reference files and link to them. That is what progressive disclosure is for.
3. Write imperatives, not descriptions. "Never name individuals" beats "this report generally avoids naming individuals."

8. Common Architecture Mistakes

Mistake 1 — Reaching for RAG when you needed a Skill. Somebody wants consistent output, so they index the style guide, embed it, retrieve fragments, and hope the right paragraph surfaces. A single skill file would have made it deterministic, free, and reviewable in a pull request. This is the most common one by a distance.

Mistake 2 — Building an MCP server for data that changes once a quarter. That is a maintenance burden wearing an integration costume. Index it or put it in a reference file.

Mistake 3 — Tool sprawl. Connect twelve MCP servers and their tool schemas start eating your context window before the user has typed a single character — and the model gets measurably worse at choosing the right tool. On-demand tool loading has taken the edge off this, but the architectural pressure remains. Curate your tool surface the way you would curate a public API. Fewer tools with better descriptions beat a directory of everything.

Mistake 4 — Believing long context killed RAG. Long context solves small corpora. It does not solve a 40 GB document store, and it does not solve paying for a million input tokens on every single request. RAG is a cost and precision strategy, not just a capability one.

Mistake 5 — Believing Skills replaced MCP. A skill has no auth, no session, and no connection. It cannot fetch anything on its own. What it can do is tell the agent how and when to use the MCP tools that are already wired up. They compose; they do not compete.

9. The Takeaway

Stop asking which one wins. Ask which question you are answering:

• Knowledge the model lacks → RAG
• Systems the model must reach → MCP
• Procedure the model must follow → Skills

And when a capability is genuinely both a system and a way of using that system — which describes most real engineering work — build a small MCP server for the access and a Skill for the workflow that drives it.

The teams shipping reliable agents right now are not the ones who picked the trendiest primitive. They are the ones who matched the primitive to the problem.

---

About the Author
Atique Ahmed — Principal AI Architect. 7x Microsoft MVP and Guinness World Record holder for Programming Excellence. Founder of Codez Tech.
Portfolio  |  LinkedIn  |  GitHub

This is Day 1 of a daily GenAI and agentic AI series on CodezTech. Tomorrow: the next topic.

Read More