How to make an agentic workflow!

Kazi Rahman — Mon, 20 Jul 2026 17:32:02 +0000

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.

DEV Community: Kazi Rahman

How to make an agentic workflow!

The Problem

Sample Flow

How I Scored Each Workflow

The Three Workflows

Workflow 1 — The Software Factory

Workflow 2 — Softcery (Dual-Tool, Persistent Memory)

Workflow 3 — Deschryver (Keep It Simple)

What I'm Doing For My Next Project

My Agentic Setup Going Forward

TLDR