# Core Concepts of Agentic Coding Agents: Beyond the Model Lies the Harness
A Coding Agent isn't a chatbot that's better at writing code — reliability comes from the Harness: Instructions, Tools, Memory, Permissions, and the Verification Loop working together.
An Agentic Coding Agent is not “a chatbot that’s better at writing code.” It is a software engineering participant that reads context, calls tools, modifies files, runs verification, receives feedback, and keeps iterating inside a controlled engineering environment.
The direction of mature usage is clear: moving from vibe coding into agentic engineering — designing stable instructions, tools, permissions, context, and verification loops for the agent.
Definition
Agentic Coding Agent = Model + Instructions + Tools + Memory/Context + Permissions + Workflow Loop
The model is just the source of capability; reliability comes mainly from the surrounding Harness. In one line: the model gives you possibility, the Harness gives you reliability. See Harness Engineering for more.
A Shared Abstraction Across Three CLIs
Claude Code, Codex CLI, and Gemini CLI are different products, but their abstraction layers align closely:
| Concept layer | Claude Code | Codex CLI | Gemini CLI |
|---|---|---|---|
| Persistent instructions | CLAUDE.md, .claude/rules/ | AGENTS.md | GEMINI.md |
| Session commands | .claude/commands/*.md | Built-in /plan, /review, etc. | .gemini/commands/*.toml |
| Skills | .claude/skills/ | .agents/skills/ | .gemini/skills/ |
| Subagents | .claude/agents/ | .codex/agents/ | .gemini/agents/ |
| External tools | .mcp.json | config.toml MCP | mcpServers |
| Safety boundary | permissions, sandbox, hooks | sandbox, rules, hooks | allowlists, checkpointing |
Orchestration pattern: Claude/Gemini emphasize Command → Agent → Skill; Codex currently leans more toward Agent → Skill + slash/session controls.
Ten Core Concepts
1. Agent vs. Chatbot
A chatbot generates answers; an agent calls tools and keeps acting based on its observations. The human’s role shifts from “writing code line by line” to “setting goals, designing boundaries, reviewing evidence, and taking accountability.”
2. Persistent Instructions
CLAUDE.md / AGENTS.md / GEMINI.md load project conventions into every session.
Good fit: repo structure, build/test commands, architectural conventions, the definition of done. Poor fit: long prose, one-off tasks, complex procedural detail (which should be broken out into skills/docs instead).
3. Commands — Stable Workflow Entry Points
Commands are not magic incantations — they turn high-frequency workflows into entry points, parameters, and constraints. Codex’s /plan, /review, and /permissions are session controls; Claude/Gemini’s custom commands behave more like prompt templates.
4. Skills — Reusable Packages of Procedural Knowledge
Progressive disclosure: at the start of a session, only the name and description are exposed; the full SKILL.md is read only when a task matches.
Commands trigger workflows; Skills carry the reusable know-how. See Nine Types of Claude Code Skills.
5. Subagents — Context Partitioning
Subagents move noisy intermediate output out of the main session, reducing context pollution. Good fit for read-heavy, parallelizable, and summarizable tasks; parallel write operations require caution.
Subagents aren’t “more AI” — they’re context partitioning and separation of responsibility.
6. MCP — The External Tool Bus
Give the agent the right tool for the task: documentation lookup, web UI debugging, GitHub/Linear workflows. It’s not “the more MCPs you connect, the better.” See The MCP Protocol.
7. Config — A Deterministic Control Plane
Put stable behavior into config rather than repeating reminders in the prompt: model, sandbox, approval, MCP, hooks. The prompt is a request; config is the boundary.
8. Safety Boundary
Sandbox, approval policy, tool allowlist, hooks, checkpointing. Permissions don’t get in the way of efficiency — they’re what makes efficiency trustworthy.
9. Memory vs. Instructions vs. Context
| Layer | Purpose | Risk |
|---|---|---|
| Current context | Current task, files, errors | Can bloat and become polluted |
| Persistent instructions | Project/team rules | Too long dilutes attention |
| Memory | User preferences, habits | Shouldn’t replace checked-in rules |
| External knowledge | Documentation, codebase facts | May go stale, needs dynamic verification |
10. Verification Loop
Research → Plan → Execute → Review → Ship
An agent’s deliverable isn’t code — it’s a change accompanied by evidence: test output, diff review, screenshots, reproduction records.
Four Layers of Extension Capability
| Layer | Question it answers | Representative examples |
|---|---|---|
| Governance | What can be done, and when to check | Settings, Rules, Hooks, Permissions |
| Extension | How to package and distribute | Plugins, Extensions, Marketplace |
| Orchestration | How multi-step work is organized | Workflows, Commands, Agent Teams |
| Observability | How to recover and audit | Sessions, Checkpointing, Telemetry |
Accountability Architecture
Human intent and accountability
|
v
+----------------------------------------------------------+
| Agentic Coding Agent Harness |
| Instructions + Tools/MCP + Memory + Permissions |
| Research -> Plan -> Execute -> Review |
+----------------------------------------------------------+
|
v
Evidence: tests, diff, logs, screenshotsTypical Anti-Patterns
- A mega instruction file that dilutes the rules
- A subagent holding full shell/MCP/write permissions
- Prompt-only governance with no sandbox/hooks
- Changing code without a baseline test suite
- Context hoarding — never cleaning up long sessions
- The agent declares “done” with no evidence
- Handing an unreviewed PR straight to a colleague