Claude Code Buzzwords Explained: Agentic Loops, MCP, Skills

A flat glossary is hard to remember because terms from different layers sound interchangeable. Agentic loop, context window, permission mode, MCP server, skill, subagent, and cloud session do not compete with one another. They answer different questions about the same system.

Use one running example: a developer asks Claude Code to fix checkout.test.ts, run the test suite, and open a pull request only if the failure is gone. The request passes through five layers: the model reasons, the harness supplies tools, context decides what it can see, permissions decide what it can do, and extensions add extra capabilities.

A practical skim map looks like this:

| Question | Vocabulary layer | Example decision | | --- | --- | --- | | Who reasons? | Model, extended thinking, effort level | Use higher effort for architecture, lower effort for routine edits | | What can it do? | Tool, agentic loop, verification loop | Let it edit only when tests can prove the change | | What can it see? | Context window, compaction, CLAUDE.md, rules, auto memory | Put durable rules on disk, not only in chat | | What may it touch? | Permission mode, permission rule, sandboxing, project trust | Use plan/manual for sensitive work; sandbox risky execution | | How is it extended? | MCP, skills, hooks, plugins, subagents | Use MCP for tools/data, skills for workflows, hooks for deterministic gates |

Vibe coding means building fast by delegating heavily to agents, often with minimal review or ownership guardrails. You point Claude at a problem, it writes code, you ship it. The speed is real—but so is the risk.

Vibe engineering keeps the speed but adds accountability. You still use agents to drive development, but you remain the architect. You review what the agent produces, structure its inputs to be precise, monitor for hallucinations, and take responsibility for the output. The agent is your tool; you are the engineer.

The key difference is you stay in control. The agent amplifies your judgment; it does not replace it. This mindset shapes how you approach every tool—Claude.md files, skills, MCP connections, and automation loops.

Agentic coding means Claude Code can act inside a development environment instead of only writing suggestions. The mechanism is simple: the model chooses a tool, the harness runs it under permissions, the tool result returns to context, and the model chooses the next step.

For the checkout example, the loop might search for checkout.test.ts, read the failing assertion, inspect the implementation, edit either the test or code, run npm test, and repeat if the result still fails. A turn is one complete user-message-to-Claude-response cycle; a single turn can include many tool calls.

The important boundary is that tools are not intelligence. A shell command, file read, MCP call, or subagent launch gives the model evidence. The model still has to interpret that evidence, and your workflow must define a verification loop so the agent does not stop at plausible text.

Every Claude Code session operates within a bounded context window: the current conversation, file contents Claude has read, command output, system instructions, loaded skill bodies, CLAUDE.md, rules, and auto memory. Context is not the whole repository. It is the working memory currently packed into the model request.

CLAUDE.md is a persistent instruction file you write for the project. Put stable conventions there: package manager, architecture rules, test commands, forbidden patterns, and release gates. A root project CLAUDE.md is more durable than a sentence buried early in chat because Claude Code can reload it after compaction.

When the window fills, compaction summarizes older conversation content. That keeps the session alive, but it changes fidelity: recent high-detail evidence may survive as a summary, while path-scoped rules or nested instructions reload only when their matching files are read again. Use /context to see what is consuming space, /compact focus on ... before a long new task, and /clear when switching to unrelated work.

Permission mode controls whether Claude asks before an action. Sandboxing controls what a Bash command can reach after it runs. They are related safety layers, but they are not the same control.

In the checkout example, plan mode can let Claude read and propose a fix before source edits begin. Manual/default mode asks before edits and shell commands. Accept-edits mode reduces prompts for file edits. Auto mode uses a classifier to approve many actions while blocking risky ones. dontAsk is better for locked-down scripts with an allowlist, and bypass permissions belongs only inside an isolated container, VM, or sandbox runtime.

A permission rule is the fine-grained layer on top: allow Bash(npm test), ask for Bash(git push *), deny a destructive pattern. Project trust is earlier in the chain: Claude Code should not load a repository's configuration until you accept the directory, because settings, hooks, skills, and MCP definitions can influence what happens next.

The Ralph Loop (named after Ralph Wiggum from The Simpsons, who famously kept trying the same thing) is a pattern where Claude runs a task, checks progress, and retries—staying autonomous until the goal is achieved. Instead of stopping after one prompt, the agent iterates, learns from failures, and improves.

Ralph Loop in Practice

Instead of: "Write a unit test for the getUserById function"

You use a Ralph loop: "Write unit tests for getUserById. Run npm run test to verify they pass. If tests fail, analyze the error and fix the implementation. Retry until all tests pass."

The agent writes the test, runs it, sees a failure, diagnoses the root cause, fixes the code, re-runs, and repeats until success. You get a complete working solution, not a partial attempt.

Loop Engineering: Designing Better Loops

Not all loops are equal. Good loop design separates concerns:

• Clear goal: "All tests must pass and coverage above 80%" (not "keep working until it seems good")
• Measurable success: Exit criteria that the agent can verify automatically
• Bounded scope: Retries stay within 1–5 iterations; if looping exceeds that, break into smaller loops
• Fallback plan: What happens if the loop fails or gets stuck? (e.g., human review, escalation, rollback)

Loop engineering transforms vague directions into deterministic, verifiable automation. The agent's job is not to be smart; it is to be precise and accountable to the goal you defined.

Claude Code extension terms are easiest to separate by trigger. CLAUDE.md and unscoped rules are persistent context. Skills are reusable markdown workflows or knowledge packages that load when invoked or relevant. Hooks are deterministic handlers at lifecycle events. MCP servers expose external tools, prompts, or resources. Plugins package several of those pieces for installation and distribution.

MCP is not a workflow by itself. It gives Claude a way to call external capabilities such as Jira, Slack, browsers, databases, or internal tools. A skill can then explain when and how to use those capabilities. A hook can enforce a deterministic gate, such as running a formatter after edits or blocking a risky command before it runs.

For a team, start with the smallest extension that solves the real problem. Put always-on conventions in CLAUDE.md; create a skill for a repeatable review/deploy process; add MCP when the agent needs an external system; use a hook when the action must run whether or not the model remembers; package as a plugin when multiple repositories need the same bundle.

Subagents are delegated workers inside a parent session. They can have their own instructions, tool access, permissions, and context window, then return a summary to the main conversation. Use them when a task would flood your main context or when specialized analysis should stay isolated.

Agent teams are multiple independent Claude Code sessions coordinated by a lead agent. They are heavier: each teammate has its own session and can be inspected more directly. Worktree isolation is the Git-side safety mechanism that lets parallel work happen without agents overwriting the same files.

In the checkout example, a subagent might inspect all payment tests and return only the likely failure cause. An agent team might assign one session to the UI flow, one to API tests, and one to security review, each in a separate worktree. The difference matters because isolation changes what history is visible, where edits land, and how conflicts are merged.

A session is the conversation plus tool history tied to a directory. You can resume a session, fork it, rewind to a checkpoint, or move between surfaces. A surface is where you interact with Claude Code: CLI, IDE, Desktop, browser, mobile entry points, or integrations.

Execution location is a separate axis. Local and Remote Control sessions operate against your machine; cloud sessions run in cloud infrastructure from a repository clone; self-hosted environments put that execution under your organization's infrastructure. Teleport pulls a cloud session back into the terminal, while Dispatch starts a Desktop coding session from mobile.

Automation terms live on top of sessions. Non-interactive mode runs one prompt and exits, usually with -p or --print. Routines and scheduled tasks run prompts repeatedly or from triggers. /loop repeats within a CLI session, while /goal needs a verifiable completion condition. The Agent SDK is the programmable version: build your own agent application with streaming input/output, custom tools, structured output, and MCP integration.

Professional Claude Code workflows enforce structure and verification at every step. The goal is not to make the agent sound formal; it is to make the output checkable by a human, a script, or both.

Structured output means the answer must follow a declared shape, such as { bugs: [{ file, line, severity, evidence, proposedFix }] }, rather than free prose. That shape is useful in loops because a script can reject missing evidence, unknown severity values, or empty fixes before the workflow moves on.

Verification is the second half. Claims about code should be checked with rg, type checking, tests, builds, or screenshots. Claims about product behavior should be checked against current official docs. Performance claims need a workload and measurement method, not impressive fixed numbers. In a real checkout workflow, success is not "Claude says it is fixed"; success is npm test -- checkout.test.ts exiting with code 0 and a human-readable diff that matches the intended behavior.

Claude Code is powerful, but it is still one implementation of an agentic coding harness. Alternatives matter when your constraint is provider diversity, local execution, licensing, workflow fit, or integration with an existing editor.

OpenCode-style CLIs, IDE-native agents, local-model harnesses, and multi-provider routers can all support parts of the same loop: read, edit, run, verify. The fair comparison is not brand versus brand; it is which execution boundary, tool set, permission model, context strategy, and verification loop fits your work.

Choose by constraint. If repository data must stay local, prefer a local or self-hosted execution boundary. If the team needs the strongest product integrations and current Claude Code surfaces, use Claude Code. If you need model A/B tests, design your workflow around standard Git/test/build interfaces so you can swap models without rewriting every prompt.

This table compresses the master vocabulary into terms worth learning first:

| Term | Layer | Simple meaning | Failure if misunderstood | | --- | --- | --- | --- | | Agentic loop | Action | Gather context, act, verify, repeat | Agent stops after plausible text | | Tool | Action | A file, shell, search, MCP, or orchestration action | User expects reasoning from a mechanism that only returns evidence | | Context window | Memory | Current working memory of the session | Old instructions crowd out current evidence | | Compaction | Memory | Summarization when context fills | Important details survive only as lossy summaries | | CLAUDE.md | Memory | Persistent project instructions | Rules live in chat and disappear after compaction | | Permission mode | Control | Baseline approval behavior | Agent has too much or too little autonomy | | Sandboxing | Control | OS-level command isolation | Approved command reaches more than intended | | MCP server | Extension | External tools, prompts, or resources | Agent lacks live data or writes to the wrong system | | Skill | Extension | Reusable workflow or knowledge package | Team repeats fragile one-off prompts | | Hook | Extension | Deterministic lifecycle handler | Policy depends on the model remembering it | | Subagent | Delegation | Worker with separate context and tools | Large research floods the main session | | Agent team | Delegation | Multiple independent sessions with coordination | Parallel edits collide without worktrees | | Session | Lifecycle | Saved conversation tied to a directory | User resumes the wrong history or branch context | | Non-interactive mode | Automation | One prompt runs and exits | CI run lacks an allowlist or pass criterion | | Agent SDK | Productization | Build custom agents with code-level control | Interactive habits leak into production automation |

Each concept solves a concrete problem: CLAUDE.md reduces repetition, compaction manages limited working memory, MCP adds external capabilities, hooks enforce deterministic gates, and subagents keep large explorations out of the main context.

To solidify your understanding, set up a small project with vibe engineering discipline:

1# Create a test project2mkdir -p my-claude-project && cd my-claude-project3git init4 5# Write project rules6cat << 'EOF' > CLAUDE.md7# My Claude Code Project8 9## Rules10- Use TypeScript with strict mode11- All functions must have JSDoc comments12- Run `npm run test` before proposing code changes13- No console.log in production—use the logger utility14 15## Success criteria16- Code must pass TypeScript type checking17- All tests must pass with >80% coverage18- No linting errors (run `npm run lint`)19EOF20 21# Initialize Node project with test framework22npm init -y23npm install --save-dev jest typescript ts-node @types/node24 25# Create a simple function26mkdir -p src27cat << 'EOF' > src/math.ts28/**29 * Add two numbers.30 * @param a First number31 * @param b Second number32 * @returns Sum of a and b33 */34export function add(a: number, b: number): number {35  return a + b;36}37EOF38 39# Create a test (intentionally failing)40cat << 'EOF' > src/math.test.ts41import { add } from "./math";42 43describe("add", () => {44  it("should add two numbers", () => {45    expect(add(2, 3)).toBe(5);46  });47 48  it("should handle negative numbers", () => {49    expect(add(-2, 3)).toBe(1);50  });51 52  it("should fail initially (intentional)", () => {53    expect(add(1, 1)).toBe(5); // This will fail54  });55});56EOF57 58npm test

Now prompt Claude Code with a Ralph loop:

"Fix the failing test in src/math.test.ts. The test is intentionally wrong to show that your fix works. Run npm test after fixing. If tests fail, analyze the error and revise. Retry until all tests pass. Success means npm test exits with code 0 and shows 3 passed tests."

Watch Claude: 1. Read the failing test 2. See the expectation (add(1, 1) should equal 5) 3. Realize the test is wrong (add returns 2, not 5) 4. Fix the test to expect(add(1, 1)).toBe(2) 5. Run npm test and confirm success

Intentional failure recovery: Edit the test to break it again, ask Claude to fix it, and verify the loop repeats automatically.