Deconstructing Claude Code and Codex: The Six Core Components That Keep Coding Agents Stable

When a CI test fails for a "cross‑month discount" fix, an agent can locate the date boundary, patch the code, and make the test pass, but a later discovery of an uncovered time‑zone scenario shows that fixing a line of code is only part of the work. The article uses this scenario to illustrate why a coding agent must maintain continuous, verifiable progress across versions, facts, actions, and tests.

Six Interlocking Components

Real‑time repository context – collect stable facts before acting, avoiding "naked" operations.

Prompt cache – reuse stable prefixes and handle only incremental changes each round.

Tools & permissions – structured actions with validation, approval, and path constraints; give fewer freedoms but more reliability.

Context governance – trim, deduplicate, and compress based on new‑old differences.

Session memory – a two‑layer record: full transcript for recovery and distilled working memory.

Sub‑agents – parallel exploration bounded by clear limits.

These components appear throughout the execution chain but must converge on three alignment points: task state, action boundary, and completion evidence.

Task as a Controlled State Machine

The coding agent is treated as a controlled task state machine. Each loop consists of observing the site, deciding the next step, executing an action, verifying the result, updating the task state, and either continuing, stopping, or handing off.

Observe → Decide → Execute → Verify
        → Update task state → Continue/Stop/Hand‑off

Mapping the six components onto this loop yields the following alignment:

Observe – repository context, prompts, context governance; risk: wrong branch, missed rules, stale info.

Decide – current work set, task state; risk: treating assumptions as facts, silently expanding scope.

Execute – tools, parameter checks, permissions; risk: path overrun, repeated side effects.

Verify – tests, diffs, logs, business confirmation; risk: partial pass reported as full completion.

Task Card – A Minimal, One‑Sentence Specification

Before work begins, the vague ticket is condensed into a concise task card that records branch, baseline, non‑modifiable files, target test, and stop conditions. Example:

Task: Fix CI failure for cross‑month discount
Goal: Correct discount calculation across month boundary
Non‑Goal: No price‑table changes, no DB migrations, no production refunds
Baseline:
  - Branch: release/2026-08
  - Commit: COMMIT_HASH
  - Worktree: payments/README.md (preserve)
Confirmed:
  - Failure spans July 31 → Aug 1
  - Discount based on order month
Pending:
  - Which timezone (account, store, system) applies?
Completion:
  - Target test passes
  - Type check passes
  - Diff limited to agreed area
  - Uncovered risks noted in hand‑off
Stop:
  - Unclear business definition
  - Requires price‑table or migration changes

After each step, the card is updated, ensuring the current reality is always captured.

Three Record Types for Longer Tasks

When tasks grow or involve multiple participants, records are separated into:

Task state – baseline, current step, blockers, next step; stored with version control so only one authoritative state exists at a time.

Action log – which tool, parameters, action ID, result; appended to avoid overwriting prior actions.

Evidence reference – diffs, test reports, logs, screenshots, approvals; points to verifiable artifacts rather than narrative.

Minimal state example:

run_id: billing-discount-20260801
base_revision: COMMIT_HASH
step: verify-timezone-boundary
step_version: 4
last_action_id: test-017
status: blocked
evidence: target-test.xml, discount.patch
next: confirm business timezone

step_version

prevents concurrent executors from clobbering each other; action_id confirms whether a timed‑out request actually occurred; evidence stores only traceable references. A tool call that succeeds but fails verification should set the status to "executed, not verified" rather than reverting to "not executed".

Context Caching and Validity

Repository context answers "where to start". Files such as AGENTS.md expose stable conventions (test commands, directory responsibilities, forbidden areas). Dynamic facts—current branch, recent failure logs, current diff—must be refreshed each tool run. The Mini Coding Agent example shows that the cache must be invalidated after a write_file or patch_file operation; otherwise the model may read stale content.

if tool_name in {"write_file", "patch_file"}:
    seen_reads.discard(path)

Facts should always carry three pieces: content, source/version, and observation timestamp.

Tools Define Action Boundaries

Tools determine what an agent can change. Actions are classified by risk level and matched with controls:

Observation – read code, search logs, view diff; limit visibility and record source/time.

Local reversible – modify workspace, run tests, generate drafts; restrict directories and commands, retain diff.

External reversible – create issue, draft PR, change test env; require explicit identity, target system, rollback plan.

High‑cost/irreversible – release, delete DB, process payment; enforce separate approval, idempotent keys, post‑action reconciliation.

Permissions should not be so restrictive that every step stops, nor so broad that risk is hidden until a final manual check.

Handling Timeouts in External Actions

When an external call times out, the result is unknown. The safe pattern is:

Before execution : read current state, verify preconditions.

During execution : attach request ID or idempotent key.

After timeout : query the real outcome before retrying.

Partial success : provide compensation, reconciliation, or manual takeover.

This mirrors real‑world checkout or payment flows where a "pending" state must be examined before any retry.

Memory, Checkpoints, and Git

Agent memory stores three kinds of information:

Running state – where the task is, next step; best kept in a task card, workflow state, or checkpoint.

Reusable knowledge – business rules, engineering conventions; store in a knowledge layer with source, version, and expiry.

Change history – which files changed on which baseline; keep in Git, diffs, and build artifacts.

Claude Code’s checkpoints can track direct file edits and survive a session, but they do not capture shell‑generated files, sub‑agent edits, or concurrent external changes. Therefore, checkpoints are suitable for in‑session undo, while Git remains the source of truth for audited code history.

Sub‑Agents for Parallel Exploration

Both Codex and Claude Code allow delegating work to independent sub‑agents (e.g., log analysis, similarity search, diff review). Reading‑heavy tasks fit well; writing‑heavy tasks risk conflicting updates. The recommended hand‑off protocol returns four items: conclusion, evidence, boundary violations, and next‑step recommendation. The main agent reconciles these into a single authoritative task state.

Conclusion: discovered X
Evidence: file, line, log, test
Boundary: missing check Y
Suggestion: next action Z with risk R

Parallel modifications should be isolated by file ownership, branch, or worktree, and merged only after re‑validation.

Layered Validation of Completion

Passing a test only proves the covered slice. Completion is defined in three layers:

Implementation complete – code landed, diff within scope.

Technical verification complete – target test, type check, build pass.

Business acceptance complete – behavior matches real business definition and production constraints.

Tasks can stop after the second layer if business confirmation is pending, provided the hand‑off clearly notes the open items.

Post‑mortem and Guardrails

Drawing on Addy Osmani’s “Agent Harness Engineering”, recurring failure types are mapped to appropriate guardrails:

Goal vs. non‑goal confusion → tighten task card or template.

Missed project commands → keep concise AGENTS.md / CLAUDE.md or skill files.

Dangerous path modifications → enforce parameter validation, hooks, permissions, sandbox.

Premature “done” → add execution gates or independent review.

External timeout replay → require state query, idempotent key, reconciliation.

Repeated same error → add regression test, static rule, or evaluation set.

Guardrails should sit at the layer where the failure originated; low‑risk, reversible actions can stay lightweight, while high‑impact actions demand strict approval and audit.

Incremental Adoption for Teams

Instead of building a full agent platform at once, start with a high‑frequency, low‑risk loop such as “fix failing unit test and generate draft PR”. The four‑step rollout:

Read‑only trial – allow repository read, search, analysis; human decides modifications.

Local modification – limit directories, run designated tests, no external calls.

Draft hand‑off – generate draft PR with diff, test results, and noted risks.

Controlled expansion – after a real failure, evaluate network, release, or other external actions.

During trials, evaluate how many tasks record baselines, how many conclusions are independently verifiable, how much context is needed for resume, whether timeout handling queries state first, and where human intervention occurs.

Conclusion

Raschka’s six components—repository context, prompt cache, tools & permissions, context governance, session memory, and sub‑agents—form the backbone of a reliable coding agent. When wired into a controlled task state machine and aligned on task status, action boundaries, and evidence, the agent’s actions stay grounded in the real engineering site. A concise hand‑off statement captures the outcome: "Target test passes, code change respects scope; cross‑timezone rule pending, so technical fix is done but business acceptance remains open."