The Layers That Make an Agent Workflow
Everything Claude Code (ECC) is the subject here, but the specific question is architectural: when a coding agent needs knowledge, execution, policy, and automation, which layer should own each responsibility? Answering that question helps a reader choose the right ECC surface for a task instead of loading a large bundle and hoping the model notices everything. The distinction also explains why ECC can travel between harnesses without promising that every host enforces the same behavior.
The useful way to read ECC is as a set of boundaries. Some components tell an agent how to think about a task. Some give a worker a narrow job. Some provide a user-facing entry point. Some are always present as standards. Others run when the harness emits an event. The boundaries are valuable only if they change what is loaded, who can act, or when a check occurs.
One request, several kinds of responsibility
Imagine a developer asks an agent to add an authentication change. The agent needs more than a code snippet. It may need a testing workflow, the project's security standards, a plan, a reviewer, and checks that run after a file is edited. Those needs look similar when expressed as prose, but they have different lifecycles. ECC separates them so the system does not solve every problem by adding more text to the same context window.
A skill is a reusable knowledge or workflow module. It can explain a framework pattern, define a test-first process, or provide a security checklist. The skill-development guide describes skills as passive knowledge that can be referenced when the task matches their domain, when a command points to them, or when an agent needs them. In the authentication example, a TDD or security-review skill supplies the method and the questions to ask. It does not become a new process with its own operating-system identity.
An agent is a scoped worker. ECC's planner, TDD guide, code reviewer, and security reviewer have different jobs, tool access, and model assignments. A planner can investigate and produce a structured implementation plan without editing code. A reviewer can inspect a diff and its surrounding call sites from a fresh context. The point is not that a second model is automatically wiser. The point is that role, context, and permissions can be separated so the same reasoning thread is not the sole witness for its own work.
A command is an entry point a person or host invokes. /plan can start the planning path; a review command can route work to a reviewer; a build-fix command can select a repair workflow. ECC increasingly treats skills as the canonical workflow surface while retaining commands for convenience and compatibility. This distinction matters during migration: a command can remain familiar without becoming the authoritative copy of every instruction it invokes.
A rule is a durable standard that the host may load continuously. Common security or coding rules are not tied to one particular request. They describe conditions that should hold across many tasks. That persistence is also their cost. If every possible language, framework, and operational preference is installed as an always-loaded rule, the agent receives a noisy system prompt before it knows what the task is. ECC therefore recommends selective rule installation: keep durable standards narrow enough to be relevant to the projects that load them.
The difference between a skill and a rule is not simply that one is longer. It is a difference in activation. A skill is a candidate source of knowledge when a task calls for it. A rule is part of the standing environment. A developer deciding whether to add a new standard should ask whether it must shape every action or only a recognizable class of work. If the answer is the latter, a skill or scoped workflow is less likely to burden unrelated tasks.
The difference between a skill and an agent is equally practical. A skill explains a pattern; an agent owns a bounded piece of work. A skill can tell a reviewer what to look for, but it does not by itself create a separate review context or restrict the reviewer's tools. An agent can use several skills while keeping its objective and permissions narrow. Treating the two as interchangeable would either turn every reference document into an active worker or give every worker an undifferentiated library of instructions.
Take the authentication change one step further. The developer can invoke a planning command, but the planner agent owns the investigation and returns requirements, affected interfaces, risks, and a test strategy. The plan can point the later TDD worker toward a failing regression test without giving the planner permission to edit. A security skill can supply the checks for token handling and input validation, while a common security rule keeps baseline constraints visible across unrelated work. The code reviewer then receives the changed files and surrounding context as a distinct task. This arrangement does not eliminate judgment; it makes the handoffs and permissions visible. If the plan is wrong, it can be corrected before code changes. If the reviewer finds a concrete defect, the work returns to the implementation loop rather than being silently accepted because one conversation reached a confident conclusion.
This separation also gives ECC a way to preserve a plan. The plan is not merely another message asking the model to remember its intentions. It is an artifact with requirements, architecture changes, phases, risks, testing strategy, and success criteria. A command may initiate it, an agent may write it, and a TDD skill may consume it, but those are different roles. The plan remains available when the work moves from one role or session to another.
Hooks turn time into a boundary
Hooks add a dimension the other components do not have: timing. A prompt or skill can tell an agent what a good action looks like. A hook can run before or after the harness attempts the action. In ECC's model, a PreToolUse hook can warn or block before a tool runs; a PostToolUse hook can analyze, format, or type-check after the tool returns; lifecycle hooks can load context at session start, save state before compaction, or record a session-ending summary.
That timing changes the control point from “the model remembers to do this” to “the harness observed this event.” For example, a pre-action check can block a development server launched outside the environment where its logs can be inspected. A post-edit check can format a file or report a TypeScript error. A stop hook can audit edited files after a response. These checks do not make the model irrelevant; they constrain the space in which a mistaken or forgotten instruction can become an unnoticed change.
The boundary has precise limits. A PostToolUse check cannot prevent the tool call that has already finished. An asynchronous hook can provide background analysis, but it cannot block the action it observes. A harness that does not expose a relevant event cannot receive a hook with the same enforcement behavior. Hooks are also executable configuration. They can run scripts, inspect inputs, and interact with the local environment, so adding a hook expands both the quality surface and the security surface.
The event itself also determines who owns state. A PreToolUse hook sees a proposed action and can decide whether the action should proceed. A PostToolUse hook sees the result and can record or diagnose it, but it cannot retroactively make the action safe. A SessionStart hook can load a bounded context, while a PreCompact hook can preserve state before the host discards part of the conversation. These are not interchangeable moments. Moving a check from before a tool to after it may preserve visibility while losing prevention; moving it into a prompt may preserve portability while losing deterministic execution.
ECC's hook design tries to make that surface maintainable. The executable hook graph is paired with metadata containing stable identifiers and fingerprints. If a hook is reordered or its command changes without the matching metadata update, validation should catch the mismatch rather than silently assign one identity to another command. Runtime profiles allow a minimal, standard, or stricter set of checks, and individual hooks can be disabled when a known conflict or recovery task requires it. These controls make the system adjustable, but adjustment is not the same as safety: disabling a guard removes a layer and should be treated as an explicit operational decision.
The same shared-source principle applies here. ECC keeps common hook logic in shared scripts and lets a harness adapter translate the host's event shape at the edge. Cursor and OpenCode expose event systems that do not use Claude Code's names or payloads. An adapter can map a file-edit or tool-execution event into the format expected by a shared check. This avoids maintaining a separate quality rule in every platform directory, but it does not make the events identical. The adapter must preserve the meaning of the event, and the support matrix must say what is lost.
That is why cross-harness support should be read as a contract with conditions. Claude Code has a native plugin surface and native hook loading. Codex can carry shared skills and configuration but does not provide the same Claude-style hook execution semantics. OpenCode can reuse logic through its plugin events. Cursor can translate its event stream to shared scripts. A host with only instruction files can still receive the workflow's guidance, but it cannot claim the same runtime enforcement. In each case, the portable part is the behavior's source; the non-portable part is how the host loads, triggers, and authorizes it.
For a developer, this model gives a practical classification test. If a new idea is a framework pattern or a repeatable process, start with a skill. If it needs a separate objective and bounded tools, make it an agent. If a person needs a convenient way to invoke it, add a command that points to the canonical workflow. If it must apply across every relevant task, consider a rule, but account for its permanent context cost. If the check depends on a tool or session event, use a hook and specify whether it can block, warn, or only observe. If it coordinates installation, ownership, or persistence, keep that state in the operational scripts and contracts rather than hiding it in prose.
The payoff is not organizational neatness. It is controlled composition. A feature request can call a skill without installing every domain guide. A planner can produce an artifact without editing. A reviewer can see the result from a different context. A hook can catch a class of mistake at the moment it becomes actionable. An adapter can preserve the same workflow across hosts while admitting where runtime control differs.
But every layer also competes for attention or maintenance. Skills consume context when loaded. Rules consume it continuously. Agents consume another context window and may lack the orchestrator's purpose. Hooks consume runtime time and trust. Adapters consume maintenance effort whenever a host changes its event model. The next problem is therefore not how to add another component. It is how to decide what deserves context, what belongs outside the model, and what can be safely left out.