Examples — Building Agentic Flows with Claude Code

1. Meeting Notes Formatter

Very Simple 3 entities · PM / Any role

After a meeting, the user invokes /format-notes and pastes raw notes. The Command produces a structured summary with decisions, action items, owners, and deadlines. This is the minimum viable system — no Agents, no Workflows. A Command is a saved prompt: deterministic, user-triggered, same behavior every time.

Workflow

Figure 1 — User invokes the Command. The Command applies the formatting Rule and consults the team Knowledge Base. No Agents, no Workflow — just a saved prompt with constraints.

Entities

Entity	Type	Purpose
com-format-notes	Command	User-invoked saved prompt. Receives raw meeting notes, applies the Rule for consistent structure, and consults the KB to match action items to team members. Deterministic — same format every time.
rul-output-format	Rule	Enforces output structure: Decisions, Action Items (with owner and deadline), Open Questions, and Next Steps. Applied automatically — the user never has to ask for the format.
kno-team-roster	Knowledge Base	Team members' names, roles, and responsibilities. The Command consults this to assign action items to the correct people and fill ownership gaps from raw notes.

Why a Command and not an Agent? A Command is a single, deterministic action — a saved prompt that always produces the same base behavior. An Agent would make sense if the system needed to make decisions, adapt to context, or operate autonomously. Here, the task is always the same: format notes. Command is the right fit.

2. PR Review Assistant

Simple 4 entities · Developer

A developer invokes the code-reviewer Agent directly. The Agent analyzes the current diff for bugs, style violations, and security issues. Unlike Example 1's Command, this Agent adapts its behavior to context — different diffs produce different analysis strategies. It uses a Skill for structured formatting and consults the team's style guide. No Workflow needed: there is only one Agent, and a single Agent does not require orchestration.

Workflow

Figure 2 — User invokes the Agent directly. The Agent uses a Skill for formatting and consults the KB. The Rule constrains all output. No Workflow — single Agent, no coordination needed.

Entities

Entity	Type	Purpose
age-spe-code-reviewer	Agent	Specialized worker with one domain: code review. Has its own identity and makes decisions during execution (what to focus on, severity assessment). Runs in an isolated context window. Invoked directly by the user or by description match.
ski-format-report	Skill	Reusable formatting procedure — no own identity, no decisions. Structures the Agent's raw findings into a clean report with sections by severity. Could be reused by other Agents in different workflows.
rul-review-standards	Rule	Constrains every review: findings must have a severity (critical / warning / info), a specific line reference, and an actionable suggestion. Prohibits cosmetic nitpicks and vague feedback.
kno-style-guide	Knowledge Base	Team coding conventions: naming patterns, error handling, test expectations, architectural boundaries. The Agent consults it to calibrate findings against team-specific standards.

Why an Agent and not a Command? The code-reviewer adapts to context — different diffs trigger different analysis strategies. A Command always produces the same base behavior. The Agent makes decisions: where to look deeper, how severe an issue is, what to prioritize. That contextual reasoning is what distinguishes an Agent from a Command.

3. Customer Support Triage

Normal 6 entities · Operations / PM

The user invokes the support-triage Workflow with an incoming ticket. The Workflow coordinates two Agents: a classifier that determines urgency and department, and a draft-responder that generates replies for urgent cases. This is the first example with a Workflow — because two Agents with different responsibilities need coordination and output transfer between them. The Workflow decides the sequence and makes routing decisions.

Workflow

Figure 3 — First Workflow: coordinates two Agents with different responsibilities. The classifier runs first; if urgent, the draft-responder runs next. Both use the shared sentiment-check Skill. The SLA Rule constrains timing.

Entities

Entity	Type	Purpose
wor-support-triage	Workflow	Coordinates execution: launches classifier first, reads its output to determine urgency, then conditionally launches draft-responder for urgent tickets. Does not execute tasks directly — only coordinates and transfers outputs between Agents.
age-spe-classifier	Agent	Determines urgency (critical, high, normal, low) and department (billing, technical, account, general). Uses the sentiment-check Skill to detect frustrated or escalation-prone language. Returns a structured classification.
age-spe-draft-responder	Agent	Only invoked for urgent tickets. Consults the Product FAQ to draft an accurate, empathetic response. Runs the sentiment-check Skill to validate the tone before returning the draft.
ski-sentiment-check	Skill	Reusable by both Agents. Analyzes text for emotional tone, frustration signals, and escalation risk. No own identity — a generic technical capability that any Agent can use.
rul-sla-compliance	Rule	Enforces response time thresholds: critical tickets within 1 hour, standard within 24 hours. The Workflow checks SLA windows before scheduling the response.
kno-product-faq	Knowledge Base	Common questions, known issues, and resolution steps. The draft-responder consults this to generate accurate responses instead of hallucinating solutions.

Why a Workflow and not just two Agents? Because an Agent cannot invoke another Agent — that is an anti-pattern. When two or more Agents need coordination and output transfer between them, a Workflow is the correct entity. The Workflow decides the sequence (classify first), makes routing decisions (is it urgent?), and transfers the classifier's output to the draft-responder.

4. Campaign Brief Generator

Normal 6 entities · Marketing

A marketing lead invokes the campaign-brief Workflow with campaign goals and target audience. The Workflow coordinates a strategist Agent and a content-planner Agent to produce a complete brief. This example adds a Command (/export-brief) as an independent user action — it does not go through the Workflow, because a Command is always triggered manually by the user and makes no sense as a step that another entity would invoke.

Workflow

Figure 4 — Workflow coordinates two Agents (strategist → content-planner); both consult the brand KB. The Command is a separate user action — it does not pass through the Workflow.

Entities

Entity	Type	Purpose
wor-campaign-brief	Workflow	Coordinates two Agents in sequence: first the strategist (messaging + channels), then the content-planner (calendar). Transfers the strategist's output to the content-planner. Does not execute tasks directly.
age-spe-strategist	Agent	Develops key messaging, value propositions, and channel recommendations. Uses the competitor-scan Skill to validate differentiation. Consults brand guidelines for voice consistency.
age-spe-content-planner	Agent	Creates a content calendar with dates, channels, content types, and themes. Receives the strategist's output to ensure alignment. Consults brand guidelines for consistency.
ski-competitor-scan	Skill	Reusable procedure — analyzes competitor positioning. No own identity. Returns differentiation gaps and messaging opportunities. Could be used by any Agent in any Workflow.
com-export-brief	Command	User-invoked deterministic action. Formats the generated brief into a clean deliverable. Always triggered manually — no Workflow or Agent would invoke this. A saved prompt for export.
kno-brand-guidelines	Knowledge Base	Tone of voice, visual identity, approved messaging frameworks, competitor positioning. Both Agents consult it to keep the brief on-brand.

5. Sprint Planning Pipeline

Complex 9 entities · PM / Engineering Lead

The user invokes the sprint-pipeline Workflow at the end of a sprint. The Workflow coordinates three Agents in sequence: retrospective analysis, velocity estimation, and sprint planning. This example uses every entity type: a Workflow orchestrates, three Agents execute, two Skills provide reusable capabilities, a Rule constrains, a Knowledge Base informs, a Command exports, and a Hook enables automatic triggering as an alternative to manual invocation.

Workflow

Figure 5 — Full pipeline: User (or Hook) invokes the Workflow, which coordinates 3 Agents in sequence (1st → 2nd → 3rd). The sprint-planner uses 2 shared Skills. All Agents consult the KB. A Command handles publishing. The Rule constrains capacity.

Entities

Entity	Type	Purpose
wor-sprint-pipeline	Workflow	Coordinates three Agents in sequence: retro-analyst → velocity-calculator → sprint-planner. Transfers outputs between them (retro feeds into velocity, velocity feeds into planner). Does not execute tasks directly.
age-spe-retro-analyst	Agent	Reviews completed tickets, identifies what went well, what didn't, and recurring blockers. Consults Team KB for responsibilities and OKR alignment. Returns structured retrospective.
age-spe-velocity-calculator	Agent	Analyzes story points completed vs. planned across the last 3 sprints. Computes rolling velocity and availability-adjusted capacity. Consults Team KB for headcount and time-off data.
age-spe-sprint-planner	Agent	Takes velocity estimate and backlog, uses backlog-scorer Skill to prioritize items and risk-assessment Skill to flag high-risk ones. Drafts the sprint plan within capacity constraints. Consults Team KB for OKR alignment.
ski-backlog-scorer	Skill	Reusable procedure — scores backlog items by business value, effort, and OKR alignment. No own identity. Returns a ranked list. Could be used by any planning Agent.
ski-risk-assessment	Skill	Reusable procedure — evaluates technical risk, dependency risk, and knowledge-gap risk. Flags items that need mitigation. No own identity — a generic capability.
rul-capacity-constraints	Rule	Two hard limits: total sprint points cannot exceed velocity-adjusted capacity, and no more than 2 high-risk items per sprint. Constrains behavior — does not execute.
kno-team-okrs	Knowledge Base	Team members, roles, skillsets, availability, and current OKRs. Static reference consulted by all three Agents for ownership, capacity, and alignment.
hok-sprint-close	Hook	Event-driven trigger that fires automatically when the sprint is marked as closed. Invokes the Workflow without user intervention. An alternative to manual invocation — the user can still invoke the Workflow directly.

Two invocation paths. The user can invoke the Workflow manually, or the Hook can trigger it automatically on sprint close. Both paths lead to the same Workflow. The Command (/publish-plan) is always user-invoked — it is a separate action for exporting the final plan after the user reviews it.

What makes this complex? Nine entities across every type in the system. Sequential dependencies between Agents (each needs the previous one's output). Two shared Skills reusable across workflows. A Hook for automation. A Command for the user-facing action. A Workflow that coordinates it all. This is what a production-grade agentic system looks like.

← Previous Part 4 — Advanced Back to → Home