How skills, specs, memory, and agent fleets turn AI models into reliable runtimes

A technical deep dive into the paradigms shaping AI agent development July 2026 · For software engineers, AI/ML engineers, and technical architects

A technical deep dive for engineers who need architecture judgement, not another feature checklist. The centre of the story is loop engineering and graph engineering. Around them sit the runtime practices that make both work: harnesses, skills, parallel agent fleets, execution and memory, and optionally durable specs that keep agent thinking inspectable.

What this article covers

  1. Why prompting stopped being enough
  2. Loop engineering
  3. Graph engineering
  4. How to use both in one system
  5. Shared concepts that sit under both paradigms
  6. High-level design (HLD) and system principles
  7. How to choose

1. The end of prompting as we knew it

In June of 2026, Peter Steinberger put a sentence into the world that stuck:

You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.

Boris Cherny, who leads Claude Code at Anthropic, said essentially the same thing:

he does not prompt Claude anymore; he has loops that prompt Claude and figure out what to do. His job is to write loops.

Addy Osmani crystallised the idea in Loop Engineering. Weeks later, LangChain published 3 Years of Graph Engineering with LangGraph, naming another side of the same hard problem.

They mark a change in how engineers relate to AI systems: from typing every prompt to designing the system that does the prompting. Loop engineering and graph engineering are not competing brands; rather, they are different architectural decisions with different failure modes and trade-offs.

Why these terms exist

LLMs are non-deterministic, non-robust software, so between 2022 and 2026 the development paradigm shifted three times, each time because the previous approach could not ship reliable production results.

A useful mental model stacks four layers. Each wraps the one below it.

You need a harness before a loop can run You often need a graph before many loops can coordinate safely

2. Loop engineering

_Loop engineering replaces you as the person who prompts the agent. _You design the system that finds work, hands it out, checks it, writes down what is done, and decides the next move, and then that system pokes the agents instead of you.

The harness is the factory floor, the loop is the shift schedule and the QA gate.

From native prompting to markdown memory

Early coding assistants were single-turn: editor context in, completion out. Chat made the interaction multi-turn, but the loop was still human-driven. You typed, read, and typed again, but the model could not decide the next step, verify its own work, or continue unattended.

The first structural fix was markdown on disk. Claude Code popularised CLAUDE.md. AGENTS.md spread as an interoperable convention, and teams added progress files, style guides, and skill indexes. The model forgets between runs, but the repository does not.

External memory is the spine of every serious long-running agent.

Agentic skills: methodology as markdown

When products absorbed the pattern

A year ago, a personal loop was a pile of bash, but now the pieces ship inside the products:

  • Claude Code: /goal, /loop, /schedule, hooks, GitHub Actions
  • Codex: /goal with pause/resume, Automations, worktrees, TOML subagents
  • Cursor: local /loop, cloud Automations from Slack, Linear, GitHub, PagerDuty, webhooks
  • Gemini CLI: ReAct loop with GEMINI.md and skill extensions

The ReAct turn loop (foundation)

Every modern coding agent still bottoms out in a reason–act cycle. Loop engineering does not replace this; rather it wraps it with stop conditions and external cadence.

/goal: productised loop engineering

/goal is the form of the loop most people mean. You are not asking for one answer, but rather you are asking the agent to pursue an objective across turns until a condition you wrote is true. After each turn, a separate small model evaluates completion. _In Claude Code this is effectively a session-scoped stop hook with a small grader model. Codex exposes inspect, edit, pause, resume, and clear. _The design invariant is maker–verifier separation: the model that wrote the code is not the one allowed to declare victory.

The evaluator does not run your tools. Goal evaluators judge from transcript evidence. “The database is clean” is not a proof unless a command’s output appears in the thread. Name the proof surface — exit codes, bench scripts, grep results — and always add a turn or time bound.

The same machine shows up under other names: time-based /loop, schedules, event-driven automations, lifecycle hooks, self-verifying sandboxes, CI as an external grader, and adversarial review subagents. If it triggers work, checks a condition, and continues or stops under a budget, it is the same loop.

Scheduled and automation loops

Why naive /goal fails

“Improve the application” has no exit. Improvement is unbounded; the agent can work for days producing marginal churn. Contrast that with “reduce DB write latency under 10 seconds, proven by scripts/bench_writes.sh exiting 0 and reporting p95 below the threshold, without changing public API schemas or stop after 25 turns.” Now the agent has an outcome, a proof, an invariant, and a hard bound.

GOAL.md turns that discipline into a file. Think of CLAUDE.md / AGENTS.md as how to work in the repo and GOAL.md as the _fitness functio_n for what “better” means. Strong contracts usually include:

  • a computable measure
  • an improvement loop: measure → diagnose → act → verify → keep or revert
  • an action catalog so the agent does not thrash
  • iteration logging so failed experiments are not repeated
  • an explicit stop threshold

Read more about /goals here:

The /goal command is the most important agent primitive of 2026

How serious teams use loops

Start with layered context and skills, then promote recurring work into automations. OpenAI’s internal Codex usage looks like daily triage, CI summaries, and bug hunts landing in a triage inbox. Cursor runs security review on push to main, agentic codeowners on PRs; PagerDuty-triggered investigation with Datadog MCP; morning coverage agents; and Slack bug triage — hundreds of automation runs per hour internally. Rippling engineers dump notes into Slack and let cron agents dedupe across GitHub and Jira. Cherny’s version of the job is designing those loops, not babysitting every turn.

From writing every line to designing the next loop and reviewing what it ships. That only works if verification stays yours as an unattended loop; making mistakes unattended is automation of debt.

Comprehension debt grows when you accept code you never read. Cognitive surrender — taking whatever the loop returns because it is convenient — looks like productivity until quality collapses.

3. Graph engineering

Graph engineering makes the workflow topology explicit. You impose how the system should work into constrained paths instead of hoping the model invents the right control flow every time as the name got loud in 2026; the practice is older. LangGraph was built for this roughly three years earlier. LangChain’s essay is clear:

Representing agents as graphs is a reasonable way to harness LLMs when structure is known

From chains to stateful cyclic graphs

Early LangChain centred on chains: one step’s output fed the next. It was fine for summarisation and simple Q&A but inadequate for branching, retries, human approval, multi-agent coordination, and recovery. LangGraph’s answer was a state machine with LLM-powered decision points.

  • Nodes do work: deterministic code, a single model call, a tool call, or a full agent with its own inner loop
  • Edges decide what happens next: deterministic or conditional
  • Shared typed state moves through the graph

Production agents need cycles, retries, clarification, validation, tool loops, and pause-for-human (HITL) are not DAG-shaped. LangChain’s later framing is blunt: loops are simple graphs, and LangChain’s agent loop sits on LangGraph. Dynamic fan-out via Send matters when you know “research then synthesize” but not how many workers you need until runtime.

StateGraph control plane

Production example: docs / support graph

What is actually new

What changed in the “graph engineering” wave is less the abstraction and more what you put inside a node, as early nodes were a function or one LLM call, but now a node can be a full coding or research agent run; you orchestrate agents, not just prompts. Predictability comes from the mix: fixed code for Slack and Linear steps, single model calls for classify and synthesize, open-ended loops for reference-docs and conceptual-docs agents.

Graph engineering inside agent runtimes

Loop engineering went mainstream when coding products shipped /goal and automations, but graph engineering has a quieter parallel story: the same runtimes increasingly expose graph-shaped control — not always as a visual StateGraph editor, but as topology you can author and the runtime enforces.

If loop engineering taught you to put stop conditions on coding agents, graph engineering in runtimes teaches you to put routing and stage ownership around those loops: which specialist runs, when humans interrupt, how fan-out joins, and how a crash resumes without replaying paid tokens.

Internals worth knowing (LangGraph-shaped)

Graphs are no longer only a way to write agents, but they are becoming the control plane that hosts them.

4. Loop vs graph and using both

At root, the difference is what you refuse to leave implicit.

Loop strengths: low barrier, runs inside tools you already use, excellent when a problem collapses to a measurable fitness function. Loop limits: weak at multi-concern coordination; ambiguous goals burn tokens; observability is thinner than framework-native tracing.

Graph strengths: auditable topology, sophisticated coordination, production checkpointing and HITL per-node tracing. Graph limits: easy to over-engineer simple chores; ecosystems are not portable; you still need a good inner loop inside open-ended nodes.

One stack

Layered model: Loops handle repeated act → check → revise_. Graphs encode the_ dependencies, branching, and verification structure that decide where those loops should run.

The graph is the map, and the loop is the engine inside selected stages. Put structure you trust in the graph and put iteration you cannot pre-enumerate inside loop nodes — and give every loop node a local proof plus a budget so a stuck inner loop cannot stall the whole system.

LOOP = act → check → revise until local goal contractMemory = graph checkpoint + goal.md/progress.md + CI

How to choose

Two selection questions stay simple: Can I enumerate the valid paths and gates? Can I name a command that proves done? If neither, tighten the problem before buying autonomy

5. Shared concepts that power both paradigms

Loop and graph answer different control questions. The concepts below sit underneath both, so introduce them after you understand the two paradigms — not instead of them.

Harness engineering

A base model accepts tokens and emits tokens. _It cannot, by itself, read a repository, decide which tool is permitted, preserve a task across restarts, or prove that a test passed. _The agent harness is the runtime wrapper that does those jobs.

The environment and harness are related but NOT identical. The filesystem is part of the environment; the permission rule deciding whether the model may write to it belongs to the harness. A test runner is an environmental capability; the adapter that invokes it, captures its exit code, and feeds the result back into context belongs to the harness.

Mitchell Hashimoto’s practical definition: when an agent makes a recurring mistake, change its instructions or build a tool so the mistake does not recur. That yields two classes of harness work:

  1. Semantic controls — AGENTS.md, CLAUDE.md, skills, examples, architectural rules
  2. Mechanical controls — typed tool schemas, hooks, linters, sandboxes, allowlists, approval gates, rollback paths

A loop is executable only because the harness can act, observe, persist, and stop. A graph is enforceable only because the harness can route state, isolate nodes, checkpoint transitions, and mediate side effects.

Agentic skills

An agentic skill is a reusable package of procedural knowledge that the runtime can discover and load when a task matches

Under the Agent Skills open standard, the package is a directory with a SKILL.mdentry point and optional scripts, references, templates, and assets.

security-review/
├── SKILL.md
├── references/
│   ├── threat-model.md
│   └── severity.md
├── scripts/
│   └── scan.sh
└── templates/
    └── report.md

Skills sit between a goal and a tool:

A TDD skill can say, “write a failing test first.” Only a loop checks that the test fails, implements the behaviour, and reruns it; a hook can reject a commit when no relevant test changed; a graph can route security-sensitive changes to an independent reviewer.

Reliability comes from composing those layers, not from making SKILL.md longer.

Agentmaxxing

‘Agentmaxxing’ is a community term for running many coding agents concurrently, often across Claude Code, Codex, Cursor, Gemini CLI, or a mix – each on a bounded task in an isolated branch or Git worktree. The meme sounds like “use as many agents as possible.” The engineering definition is maximizing useful parallel throughput under integration, review, and spend constraints.

It is not automatically a multi-agent system. Five independent terminals with a human assigning work are five concurrent single-agent loops, as they become an orchestrated multi-agent system only when a runtime owns task claiming, dependencies, routing, shared state, retries, and joining results.

Git worktrees prevent agents from overwriting the same live directory, as they do not remove semantic conflicts; the two branches can independently change an API contract, and both pass local tests. Isolation defers that conflict to the join.

useful throughput
  = parallel completion rate
  × independent-task ratio
  × verification quality
  × integration success rate
  − coordination and review cost

Agentmaxxing without a harness produces chaos; without local loop contracts, it produces unfinished branches; without a graph-shaped integration policy, it produces a pile of diffs nobody can safely compose.

Execution and memory (E/M)

The acronym EM is overloaded. In some workflows it means an engineering manager role system – human as PM and agent as EM that plans, delegates, and gates reviews. Here, E/M means the coupled execution and memory system under the runtime.

  • Execution: What action runs, where, with which permissions, under which timeout, and what happens on failure?
  • Memory: What state survives, who can read it, how is it compacted, and which version is authoritative?

Three memory horizons matter:

  1. Working memory — current context window and tool observations
  2. Episodic memory — run history: checkpoints, attempts, failures, decisions
  3. Semantic / institutional memory — durable playbook: rules, skills, architecture records, learned failure patterns

Loops stress temporal continuity, and graphs stress state consistency. Agentmaxxing stresses namespace isolation and eventual integration, and the harness owns the adapters that make those guarantees real.

Optional extra: SPEC.md / durable plan artifacts

Many loops run fine with a tight GOAL.md and good skills. Specs become useful when work spans sessions, multiple agents, or humans who need to inspect the agent’s thinking later.

A spec / plan artifact SPEC.md, plan.md is not “asking the model to think before coding”; it is an inspectable file that carries intent from exploration into implementation and verification. It helps with:

  • Thinking visibility — decisions, alternatives rejected, and constraints live outside the chat
  • Observability — reviewers and later agents can see what the system was trying to do
  • Cross-agent consistency — parallel workers share one source of truth instead of inventing local interpretations
  • Resume — a fresh session can continue without reconstructing intent from a compacted transcript

The prompt points; the artifact holds decision-rich intent, and the skill loads only the procedure needed for the current stage. HTML is often easier for humans to review than a giant Markdown file because it can hold diagrams, type interfaces, mockups, and expandable details.

In a loop, the optional spec feeds the goal contract and invariants In a graph, it supplies candidate stages and gates In agentmaxxing, it keeps parallel workers aligned

Skip it for small, local work and only add it when you need to track thinking and keep multi-agent or multi-session work observable.

Read more about spec-driven development here:

The Spec-Driven Development Pattern And How To Use It Correctly

Adjacent disciplines

These are separable concerns inside one agent-systems architecture, not seven new job titles

6. HLD and system principles

A system is the complete behaviour-producing assembly: model, harness, tools, execution environment, memory, policies, control flow, persistence, observability, and human operators. The model is a component of the system, not the system itself. Also, the same model can look reliable in one harness and unsafe in another. HLD means architecture above class and function detail.

Unified runtime HLD

This prevents common category errors, as an optional spec is not the control plane; it is intent consumed by the control plane. Agentmaxxing is not a new model capability; it is concurrent scheduling across isolated workers. A loop is not durable merely because it repeats; durability comes from the E/M layer. A graph is not safe merely because paths are explicit; safety comes from policy at action boundaries and evidence at transition boundaries.

Shared reliability principles

  1. Separation of maker and checker — the producer of an artifact is never the sole authority on “done”
  2. Externalized state — anything that must survive a context window lives outside the model
  3. Bounded autonomy — turn, time, token, and blast-radius budgets are hard constraints
  4. Evidence over belief — completion is an observable proof, not fluent prose
  5. Idempotent stages where possible — retries should not double-charge side effects
  6. Observable control flow — you must answer where the system is, why it branched, and what it will do next without reading the model’s mind

Loop HLD

Loop failure modes: ambiguous contracts, evaluator false positives, permission stalls, resume resetting budgets, token spirals, comprehension debt.

Graph HLD

Graph failure modes: over-graphing open-ended work, state bloat, missing reducers, framework lock-in, treating the graph as a substitute for a good inner verifier.

Principle map

Harness supplies tools, sandbox, permissions, and memory APIs and model supplies local decisions inside a turn or node.

7. Counterarguments worth taking seriously

Terminology inflation has become real in recent years: ‘prompt’, ‘context’, ‘harness’, ‘loop’, and ‘graph’ – each name is a genuine challenge, and each can become a distraction.

Most tasks will never need a full graph, so if the work fits a single loop, topology is overhead. Symmetrically, many one-off tasks do not need a standing loop — an interactive session with a strong agent is faster apart from that, even SPEC is also overhead for small changes. Investment should match expected lifetime and complexity.

Both paradigms still sit on model capability, and a perfect loop or graph with a weak decision-maker inside still fails, so as models improve, some scaffolding may shrink — but stop conditions, budgets, and auditability do not become optional just because the model got smarter.

Conclusion

Agent engineering has moved beyond prompting. Harnesses define the operating envelope, skills carry reusable methods, loops turn goals into verified progress, and graphs coordinate those loops across explicit paths. Agentmaxxing, E/M systems, and optional specs strengthen the stack — but none can repair a weak contract or missing proof.

Loops and graphs are not competing camps; they are different altitudes of one runtime. Use a bounded loop for a measurable goal. Only use a graph when work needs routing, approvals, coordination, or recovery — then place loops where agency earns its keep.

The engineer’s role is to design, verify, and remain accountable for the system, not merely press go.