No matter how experienced of a developer you are, whichever subset of computer science you are dedicated to, the days of traditional coding are in the past.
Learning to develop using agentic workflows have become a key requirement now days.
To properly learn this skill, I decided to find three popular agent-based workflows and pit them against each other.
The goal is to find a workflow that makes sense to me and my development philosophy!
Let's begin!
The Problem
A connection of mine needed a CRM/order management solution for their business. The core features required:
- A front end with a design already established
- Being able to submit a form using natural language
- Record info such as name and contact info
- An admin panel that lets you view all the client submissions
- Turn the natural language form submission into structured data
- Being able to update, edit, and delete a submission from the admin panel
- Being able to export all the data as a CSV
- Admin being able to update the list of items available to order
Nice to have: an email confirmation sent to the client.
Sample Flow
Client side:
Lands on the page → looks at a list of items → goes to the menu section → types in structured info such as name and contact → types in their order via natural language -> clicks submit
Admin side:
Accesses the admin side via auth → loads all orders → parses natural language orders into structured data → a high-level table showing everything that was ordered
How I Scored Each Workflow
It's really hard to say that an LLM does task X perfectly. Give an LLM the same task five times and it will produce two or three different results each time. Coming up with a way to score a collection of these tools in a way that makes sense is genuinely difficult.
My initial hunch was: once the workflow says a certain feature is done and I try to test it and record how many bugs I see. How many prompts does it take to either fully fix that bug or finish the feature properly? So below I have a table comparing total prompts, bugs raised, and fix prompts needed.
Does this give you a sure-fire way to say "workflow A is X% more reliable than workflow B"? Probably not. So I think a more realistic thing to look at is which of the workflows is the most maintainable. All of them will give you a similar level of accuracy on the objective — but what's more important is: can this workflow be used day to day?
| Workflow | Prompts to build | Defects on test | Fix prompts after "done" | Score |
|---|---|---|---|---|
| Wf1 — Factory | 25 | 3 | 2 | 55% |
| Wf2 — Softcery | 7 | 1 | 1 | 90% |
| Wf3 — Deschryver | 7 | 1 | 1 | 86% |
Score = clean-delivery rating (100 = shipped with nothing to fix). Wf2 edges Wf3 because its one issue was a missing feature, while Wf3's was a visual regression.
The Three Workflows
Workflow 1 — The Software Factory
Philosophy: Decompose the work across a pipeline of specialized subagents — research, write story, write spec, build, test, validate — so each step runs in a narrow, single-responsibility context.
Origin: The freeCodeCamp "Software Factory" pattern.
Architecture
CLAUDE.md (always loaded)
.claude/
├── agents/
│ ├── codebase-researcher.md
│ ├── story-writer.md
│ ├── spec-writer.md
│ ├── backend-builder.md
│ ├── frontend-builder.md
│ ├── test-verifier.md
│ └── implementation-validator.md
├── skills/
│ ├── build-feature/SKILL.md ← orchestrator (auto-routed)
│ └── order-parsing/SKILL.md ← domain contract
├── hooks/pre-commit-safety.sh ← blocks secrets, float-money, failing tests
└── settings.json
docs/{specs,stories}/ ← generated artifacts
Flow
plain-language request
│
▼
build-feature skill (orchestrator)
│
codebase-researcher → story-writer → spec-writer
│
[pause on open questions] ──► human decides
│
backend-builder → frontend-builder → test-verifier → implementation-validator
│
pre-commit hook gate ──► commit
One request fans out into the whole pipeline automatically. Trivial changes bypass it. Most automation, most moving parts — specialization comes from subagents.
Raw notes while using it:
- A lot of bloat still — the pipeline feels heavy for smaller tasks
- The skills are a little reassuring though
- Opened one gigantic PR (not ideal)
- A lot of "migration" work that felt over-complicated
- Had to give a few rounds of feedback once it declared itself done
- It was very aligned with the spec when it worked
- The hooks are a genuinely good idea
Workflow 2 — Softcery (Dual-Tool, Persistent Memory)
Philosophy: No subagents. One continuous session driven by a modular, pointer-based context layer and a persistent memory protocol, so a new session resumes instead of re-deriving context. Plan first, then execute.
Origin: The Softcery-style setup — dual-tool (Claude Code + Cursor), persistent memory.
Architecture
CLAUDE.md (thin — mostly @file pointers)
.ai/
├── project-brief.md
├── engineering.md ← standards + non-negotiables
├── memory.md ← session-logging protocol
├── order-parsing.md ← domain contract
├── tools/
│ ├── task-preparation-workflow.md ← phase 1: plan
│ └── implementation-workflow.md ← phase 2: execute
└── sessions/ ← dated decision logs accumulate here
.cursor/rules/{core,backend,frontend}.mdc
{api,web}/.ai-knowledge/
knowledge/<feature>/
├── trd.md
├── implementation-strategy.md
└── progress.md
.claude/settings.json
Flow
"Prepare the task: <feature>"
│
▼
task-preparation ──► knowledge/<feature>/{trd.md, implementation-strategy.md}
│
human reviews strategy ← checkpoint before any code is written
│
"Implement the <feature> task"
│
▼
implementation ──► works through progress.md checklist (may span sessions)
│
non-trivial decisions ──► appended to .ai/sessions/
Two-phase, explicitly invoked. Context is split across .ai/*.md files referenced from both CLAUDE.md and Cursor .mdc rules, so the same knowledge serves both tools. Memory lives in files, not chat history.
Raw notes while using it:
- No clarifying questions upfront — not sure if that's because it built on top of the first workflow's context
- No bugs on delivery, similar to the first
- I like the ID it assigns for each order
- The "LLM needs review" flag on parsed orders is a nice touch
- The delivery date in the customer card is a good detail
- CSV works but should surface in the UI, not just as a download
- Can't add an order from the admin panel — missing feature
- The two-step plan/execute flow is interesting but the narrow-scoped MD file per feature takes some getting used to
Workflow 3 — Deschryver (Keep It Simple)
Philosophy: The minimum that works. One lean AGENTS.md, one skill for the problem, one spec per feature. You are the team leader; the agent is the domestique.
Origin: The Deschryver-style "keep it simple" setup.
Architecture
AGENTS.md ← the only always-loaded file (lean)
CLAUDE.md ← one line: @AGENTS.md
.claude/skills/order-parsing/SKILL.md ← loaded only when relevant
specs/
├── _TEMPLATE.md
└── <feature>.md
No subagents. No orchestrator. No memory protocol. No hooks. The file count is the point.
Flow
copy _TEMPLATE.md ──► specs/<feature>.md (you write it, or agent drafts → you edit)
│
"Implement specs/<feature>.md"
│
▼
single continuous session implements it
│
human reviews output against the spec's acceptance criteria
│
agent repeats a mistake? ──► add one line to AGENTS.md, same session
The spec replaces both the subagent pipeline (it constrains scope) and the memory protocol (it's the persisted record of what was decided). All judgment — review, validation — is done by the human, by design.
Raw notes while using it:
- Each feature is pretty nicely scoped with success criteria and natural handoffs to the next feature
- The front end styling broke at one point — one prompt fixed it
- Phone and email combined in one field is a quirky call
- A lot of admin design decisions landed well: auto-parses, assigns an ID, clean all-orders table
- Delivery date can only be assigned by admin — might be intentional
- Can't add orders manually from the admin panel either
- The UI needs work
What I'm Doing For My Next Project
I think going forward I'll definitely adopt an agentic workflow setup. It's becoming similar to setting up your vim environment or a new venv when starting a project — a first step you just do automatically.
What I fundamentally liked across these three workflows:
- Hooks — turning conventions into enforcement rather than suggestions
- Connecting session notes to git commits — a nice way to see the full journey of an implementation
- Skills — but only when actually needed (like a QA skill), not as a default layer of complexity
My Agentic Setup Going Forward
After testing all three, I synthesized my own workflow. Here's how it's structured:
PROJECT.md is a high-level overview of the product — who the users are, what done looks like, and what's explicitly out of scope. First thing a new session (or collaborator) reads.
FEATURES.md is the master list of everything to build, with a status for each one (planned, in-progress, complete, deferred). No ticket system, no Jira — just a flat list that stays honest.
AGENTS.md grounds the agent on how it should work: your stack, your conventions, your non-negotiables. Always loaded into context. Keep it lean — a wrong instruction is worse than no instruction.
IP.md per feature is written before any code is touched. Copy the template into features/<feature-slug>/IP.md and fill in the goal, data model, API contract, UI states, acceptance criteria, and any open questions. When scope changes or an approach doesn't work, you append a changelog entry at the bottom — you don't rewrite the IP.
Session summaries are written at the end of every Claude Code session — what was worked on, what was decided, what didn't work, what's next. Each is a dated markdown file in sessions/ committed alongside the code. A post-commit hook writes the real git hash back into the session file, linking the session log and git history permanently.
Hooks turn the above from suggestions into enforcement. A pre-commit hook blocks secrets, API keys, failing tests, and project-specific anti-patterns. A post-commit hook handles the session-to-commit link. An environment-aware run script (APP_ENV=development|test|production) runs the right checks depending on where you are.
One skill: QA — loaded only when the session shifts to testing. Its job is to make sure tests are written against the IP's acceptance criteria, not the implementation, so a feature can't be marked complete just because unit tests pass.
╔══════════════════════════════════════════════════════════════════╗
║ THE SIX COMPONENTS ║
╠══════════════════════╦═══════════════════════════════════════════╣
║ PROJECT.md ║ high-level overview — users, goals, ║
║ ║ what's out of scope ║
╠══════════════════════╬═══════════════════════════════════════════╣
║ FEATURES.md ║ master list + status per feature ║
╠══════════════════════╬═══════════════════════════════════════════╣
║ AGENTS.md ║ always loaded — stack, conventions, ║
║ (CLAUDE.md→@AGENTS) ║ non-negotiables; keep it lean ║
╠══════════════════════╬═══════════════════════════════════════════╣
║ features/<slug>/ ║ per-feature plan written before code ║
║ IP.md ║ is touched; changelog at the bottom ║
╠══════════════════════╬═══════════════════════════════════════════╣
║ sessions/<date>.md ║ written at end of every session; ║
║ ║ committed with code; linked to hash ║
╠══════════════════════╬═══════════════════════════════════════════╣
║ hooks ║ pre-commit: blocks bad patterns ║
║ + QA skill ║ post-commit: writes hash to session ║
║ ║ run-checks: env-aware (dev/test/prod) ║
╚══════════════════════╩═══════════════════════════════════════════╝
HOW A FEATURE GETS BUILT
─────────────────────────
┌─────────────────────────────────────────────────┐
│ PROJECT.md + FEATURES.md + AGENTS.md │
│ loaded automatically at session start │
└──────────────────────┬──────────────────────────┘
│
┌───────────────▼────────────────────────────┐
│ copy features/_template/IP.md │
│ → features/<slug>/IP.md │
│ │
│ · Goal (from the user's point of view) │
│ · Data model changes │
│ · API contract │
│ · UI states (loading, empty, error, done) │
│ · Acceptance criteria (testable) │
│ · Open questions — flag, don't assume │
└───────────────┬────────────────────────────┘
│
┌───────────────▼────────────────────────────┐
│ "Implement features/<slug>/IP.md" │
│ (+ load QA skill if focus is on tests) │
│ │
│ single session works from IP.md │
│ as the contract │
└───────────────┬────────────────────────────┘
│
┌───────────────▼────────────────────────────┐
│ you review against IP.md criteria │
│ │
│ agent made a mistake? │
│ → add one line to AGENTS.md │
│ │
│ scope changed? │
│ → append changelog to IP.md, don't rewrite│
└───────────────┬────────────────────────────┘
│
┌───────────────▼────────────────────────────┐
│ "write a session summary" │
│ → sessions/YYYY-MM-DD-<slug>.md │
│ │
│ covers: what was done, decisions made, │
│ what didn't work, what's next │
└───────────────┬────────────────────────────┘
│
┌───────────────▼────────────────────────────┐
│ git commit (session file + code together) │
│ │
│ pre-commit hook: │
│ · blocks secrets / API keys │
│ · blocks failing tests │
│ · blocks project-specific anti-patterns │
│ · warns if no session file is staged │
│ │
│ post-commit hook: │
│ · writes commit hash → session file │
└───────────────┬────────────────────────────┘
│
┌───────────────▼────────────────────────────┐
│ next session opens and immediately knows: │
│ │
│ sessions/<last>.md → what's next │
│ features/<slug>/IP.md → what's left │
│ AGENTS.md → any new rules added │
└────────────────────────────────────────────┘
You can find the full setup and all the files here: https://github.com/kf-rahman/Agentic-Workflow
TLDR
Agentic workflows are the new wave. The key is to build a setup that is comfortable to you and one you can actually use every day.
Hooks are pretty cool.
Connecting a session summary to git commits is a nice way to see the full journey of an implementation.
Next up: I'm applying this workflow to an iMessage agent project. Follow along to see how it holds up on a real agentic product build.
Top comments (0)