Google software engineer Addy Osmani defined “Loop Engineering” in a June 7 post as a way to replace engineers’ manual prompt-based AI agent design methods with automated systems. It is built from five modular blocks: Automations, Worktrees, Skills, Plugins/Connectors, and Sub-agents.
Definitions and functions of the five blocks
According to Addy Osmani’s framework:
Automations: Scheduled tasks that handle automatically running “Discovery” and “Triage.” Osmani explains that Automations are the core mechanism that makes the loop a real cycle rather than a “one-time execution.” Codex app uses Automations for pagination and provides a /goal command (run until the condition is met); Claude Code achieves the same functionality through scheduled tasks, cron, /loop, /goal, and GitHub Actions.
Worktrees: Uses the git worktree mechanism to create separate working directories for parallel-running agents, preventing conflicts caused by multiple agents modifying the same file simultaneously. Codex app provides a built-in worktree for each thread; Claude Code provides the same isolation through git worktree and the --worktree flag.
Skills: Writes project knowledge, conventions, and build steps into external documentation in the SKILL.md format, so the agent doesn’t have to re-infer project context on each run. Both tools use the same SKILL.md format, and Osmani says that precise descriptions are better than vague ones.
Plugins / Connectors: Built on MCP (Model Context Protocol), enabling agents to access external systems such as issue trackers, databases, API endpoints, and communication tools. Both Codex app and Claude Code support MCP, and Osmani confirms that the same connector is usually directly usable in both tools.
Sub-agents: Splits “execution agents” and “verification agents” into separate roles, with cross-review done via different instructions and even different models, preventing an agent from being too lenient in its own self-evaluation. Codex app defines this in .codex/agents/ in TOML format; Claude Code defines Task subagents and agent teams in .claude/agents/.
External memory (State): definition and purpose of the sixth component
Osmani defines external memory as “anything that exists outside a single conversation and is used to record what was done and what the next step is,” such as Markdown files or a Linear board. The reason it’s necessary is that large language models do not retain memory between runs, so progress must be stored externally rather than in the model’s context window.
Both tools support this mechanism: Codex app links Linear via Markdown or a Connector; Claude Code links Linear via AGENTS.md, progress files, or MCP.
Frequently asked questions
What are the core differences between Loop Engineering and traditional Prompt Engineering?
Based on Addy Osmani’s framework, traditional Prompt Engineering has engineers manually write prompts and interact with the agent in iterative rounds; Loop Engineering designs a complete system where Automations automatically trigger, Worktrees isolate parallel execution, Skills provide knowledge, Connectors connect tools, and Sub-agents separate execution from verification. The engineer’s role shifts from “directly operating the agent” to “designing the system that runs the agent.”
What blocks do Codex app and Claude Code currently support?
According to Osmani’s comparison analysis, as of the time his article was published, both tools fully support the five blocks and the external memory mechanism. The main differences are in naming and specific paths: Automations has corresponding functions in both; Worktrees are based on git worktree in both; Skills use the SKILL.md format in both; Plugins/Connectors are based on MCP in both; and Sub-agents use configuration files under the .agents/ directory.
How is “execution and verification separation” for Sub-agents implemented?
According to Osmani, the design of Sub-agents sets “code-writing agents” and “code-review agents” as two independent roles, which can use different instructions and even different models. Claude Code’s /goal command follows the same principle: a brand-new model determines whether the task is complete, rather than the execution-task model self-assessing. Osmani calls this applying “doer vs checker” to the stopping condition itself.
