The Three-Layer Architecture

Lesson 1 · Safe Agentic Workflows · ~10 minutes

You already use AI agents to write code. The question isn't whether to use them — it's how to structure their behavior so it's repeatable, safe, and increasingly autonomous.

The answer, emerging across both the SAW harness and GitHub Agentic Workflows, is a three-layer architecture that separates what agents must always do from what you ask them to do from what they figure out on their own.

The Three Layers

YOUR REPOSITORY
LAYER 1: HOOKS
Automatic guardrails
Fire on every action. Agent cannot bypass them.
Think: linters, format checks, permission gates, commit rules.
LAYER 2: COMMANDS
User-invoked workflows
You trigger them explicitly. Structured multi-step processes.
Think: /start-work, /pre-pr, /release, /deploy.
LAYER 3: SKILLS
Model-invoked expertise
Agent activates them when relevant. Domain knowledge that loads on cue.
Think: "I see a migration file, let me load the DB patterns skill."

What Each Layer Does

Layer 1: Hooks — The Guardrails

Hooks fire automatically on specific events — before a file is written, after a command runs, before a commit. The agent doesn't choose whether to follow them. They're enforced.

In Claude Code, these live in .claude/hooks-config.json. In gh-aw, they're the permissions: and safe-outputs: frontmatter. Same concept: what the agent is not allowed to violate.

Examples:

Key insight

Hooks exist because AI agents are eager. Without guardrails, they'll do what seems helpful — which sometimes means reformatting your entire codebase or committing untested code. Hooks make certain mistakes structurally impossible.

Layer 2: Commands — The Workflows

Commands are multi-step processes you invoke explicitly. They encode your team's workflow as executable instructions the agent follows. In Claude Code, these are slash commands (/start-work, /pre-pr). In gh-aw, they're the entire workflow markdown file triggered by events or /slash commands in issues.

A command typically:

  1. Sets up context (reads the ticket, checks the branch)
  2. Executes a sequence of steps
  3. Produces a defined output (a commit, a PR, a report)

The power here is repeatability. Instead of explaining your workflow to the agent each time, you encode it once and invoke it with a word.

Layer 3: Skills — The Expertise

Skills are domain knowledge that the agent loads automatically when relevant. They use frontmatter triggers — file patterns, project conditions — to activate. The agent recognizes "I'm working on a database migration" and loads your migration patterns skill.

Skills don't execute steps. They inform the agent's decision-making. They're the difference between an agent that writes generic code and one that writes code matching your project's patterns.

In Claude Code / Kiro, these are .claude/skills/ or steering files. In SAW, they're the 18 model-invoked skills with Skills 2.0 frontmatter.

How the Layers Interact

The layers aren't independent — they compose:

You type: /start-work TICKET-123
COMMAND 1. Read ticket from project tracker
COMMAND 2. Create feature branch
SKILL 3. Load relevant skills based on ticket type
COMMAND 4. Begin implementation
HOOK Every file write: format check ✓ · import sort ✓ · test exists ✓
COMMAND 5. Produce "Ready for review" state

Notice the layering: the command drives the workflow, skills inform the agent's choices within it, and hooks constrain every action along the way. Process as service, not control.

Where This Maps to Your Tools

Layer Claude Code Kiro Codex CLI gh-aw
Hooks .claude/hooks-config.json Steering files (always-on) config.toml approval policy permissions: + safe-outputs:
Commands .claude/commands/*.md Skills (manual trigger) Natural language (no slash) Workflow markdown files
Skills .claude/skills/*/SKILL.md Steering files (file-matched) .agents/skills/*.md Prompt body + imports
The mental shift

You're already using pieces of this. Every time you set a Kiro steering file or write a Claude Code command, you're building one layer. The three-layer architecture just names the pattern and asks: are all three layers present and working together?

Check Your Understanding

A rule that blocks your agent from committing without running tests first belongs in which layer?
Right — hooks are enforced guardrails. The agent can't bypass them. This is a constraint, not a workflow step.
Not quite. This is a constraint that fires automatically on every commit attempt. That's Layer 1 (Hooks). Commands are user-invoked workflows; skills are domain knowledge.
Your agent notices you're editing a React component and automatically loads your component patterns. Which layer is this?
Correct — skills activate based on context (file patterns, project conditions). The agent decides to load them, and they inform its approach.
This is Layer 3 (Skills). The agent recognized a file pattern and loaded relevant domain knowledge. No one invoked it, and it's not a constraint — it's expertise.
You type /pre-pr and the agent runs linting, checks test coverage, updates the changelog, and opens a PR. Which layer?
Exactly — commands are explicitly invoked multi-step workflows. You triggered it, and it executes a defined sequence.
This is Layer 2 (Commands). You explicitly invoked /pre-pr, and it executed a multi-step workflow. Hooks fire automatically; skills load contextually.

What's Next

Now that you have the mental model, the next lesson will be hands-on: building your first hook. We'll set up a Claude Code hook that enforces a constraint you choose — something you've wished your agent would stop doing wrong.

Recommended Reading

Effective Harnesses for Long-Running Agents — Anthropic Engineering. This is the paper that established the three-layer pattern. ~15 min read. Focus on the "Architecture" section.

Questions? Ask me anything that's unclear. I'm your teacher — I can explain any of these concepts differently, give more examples, or dive deeper into how a specific layer works with your tools.
Next →