Layered Agentic Architecture

An opinionated stack of composable agentic primitives, deliberately layered so each level adds one capability the layer below lacks. IndyDevDan's "Bowser" system names four:

Skill = capability. The raw, low-level ability (e.g. drive the Playwright CLI, .claude/skills/playwright-bowser). The foundation, activated in a sub-agent's front-matter (skills: [playwright-bowser]). It is not the whole solution — "everyone's obsessed with skills," but a skill alone under-uses the agent.
Sub-agent = scale. A specialized agent that wraps the skill so it can be spun up over and over, in parallel, on its own context window (.claude/agents/bowser-qa-agent.md, model: opus). Different sub-agents can carry the same or different skills. This is where you specialize — turning raw capability into a concrete, repeatable workflow.
Command / prompt = orchestration. A custom slash command (a reusable prompt, the "API layer") that spawns and coordinates a team of sub-agents toward a goal — e.g. /ui-review fires parallel story-validation agents and merges their reports. This is the orchestrator-workers layer (Agentic Workflow Patterns).
Task runner = reusability. A single top-level surface (just / a justfile, aliased j) that catalogs every command and its parameter permutations, so you, your team, and your agents have one place to discover and invoke all of it.

The point is not any one layer but the discipline of building each one so you can enter at any altitude — kick off a bare skill, a sub-agent, a command, or a task-runner recipe — which lets you test and scale "one layer at a time." The stack is a mold: a consistent structure you drop into any codebase and specialize, so you solve a class of problem once (browser automation, UI testing) rather than re-solving it per project.

Claims

Layer agentic primitives — capability (skill) → scale (sub-agent) → orchestration (command) → reusability (task runner) — rather than relying on any single layer. best practice — context: building repeatable agent systems you deploy across codebases; each layer earns its place by adding what the one below lacks, and a skill-only or agent-only setup leaves leverage on the table. Contingent on the work recurring — a genuine one-off doesn't need the full stack.
A skill is raw capability; a sub-agent is where you specialize and scale it into a concrete workflow. principle — durable: capability and its specialized application are distinct concerns, and conflating them ("just install a skill") caps what the agent can do.
Build each layer so you can enter the stack at any altitude, and add layers one at a time. best practice — context: developing and debugging an agentic system incrementally; being able to run a bare skill vs. the full orchestration is what makes it testable and scalable step by step.
Structure the stack as a reusable "mold" and apply it to solve a whole class of problems, not one codebase. principle — durable: templating your engineering into a repeat, specializable structure is the move that turns per-project labor into a deployable system.
Code is commoditized; the advantage is your specific, opinionated solution — which lives in how you write your skills, agents, and commands. observation — the operator's framing for why the stack matters: differentiation is in the composition, not the generated code.
Treat skills/agents/prompts as distinct primitives — skill = raw capability, agent = scale/parallelism, prompt = orchestration, justfile on top — rather than "overkilling skills" by stuffing everything into one layer. best practice — context: a second independent source (IndyDevDan's "library" video) restates the same four-layer stack under the umbrella term "agentics" (prompts + agents + skills) and warns that "a lot of people are overkilling skills, doing everything inside the skill." Corroborates the stack from the distribution angle. See Agentic Distribution.

Reusable Workflow Library — the top layer (commands cataloged by a task runner) is a personal reusable-workflow library; "solve a class of problems once" is the same thesis.
CLI Tools over MCP Servers — the capability layer is built on CLI tools, not MCP servers, precisely so it can be wrapped and extended at every layer above.
Agentic UI Testing — the concrete workflow this stack is demonstrated on (alongside browser automation).
Meta-Prompt — the orchestration layer's commands are often meta-prompts (incl. higher-order prompts) that generate and staff the sub-agent team.
Agentic Workflow Patterns — the command layer is orchestrator-workers / parallelization given a reusable front door.
Workflows vs Agents — the stack mixes both: deterministic task-runner recipes wrapping model-driven sub-agents.
Agentic Distribution — once you have the stack, the library meta-skill is how you distribute and sync those primitives ("agentics") across devices, teams, and agents.
Distillate: My 4-Layer Claude Code + Playwright CLI Skill (Agentic Browser Automation & UI Testing)
Distillate: Claude Code Task System: Orchestrating a Team of Agents Through a Task Graph — the same author's team-orchestration layer, one altitude in.
Distillate: The Library Meta-Skill: How I Distribute Private Skills, Agents and Prompts — the same four-layer stack restated ("skills=capability, agents=scale, prompts=orchestrate, justfile on top") as the payload of a distribution system.

Layered Agentic Architecture

Claims

Related

Linked from