There's a better way — and it starts with sequential derivation.
Happy to be here writing this on a day off. Sometimes the best thinking happens when you're not under pressure. This is one of those thoughts that's been sitting in the back of my head for a while, and I think it's worth sharing with anyone building real products with agentic AI right now.
The Two Camps
If you've been in developer spaces lately — Discord servers, Twitter threads, Reddit arguments — you've noticed that the dev community has split into two very vocal camps when it comes to agentic AI.
Camp One: The Deity Worshippers.
These are the devs who hand the AI a vague idea and expect a production-ready app. "Build me a SaaS." They treat the agent like an omniscient oracle. When it fails (and it will), they rage-quit and write a hot take about how AI is overhyped.
Camp Two: The Micromanagers.
These are the devs who've been burned before. They spoon-feed every line, double-check every output, and end up doing more work than if they'd just written the code themselves. The AI becomes a glorified autocomplete, and they wonder why they're paying $20/month for it.
Here's the thing: both camps are wrong. about the workflow.
The Problem Is the Handoff.
Every time I've seen agentic AI fail spectacularly, the root cause isn't the model. It's that the human didn't set the stage properly. We either gave it too much freedom with too little context, or we gave it so much rigid instruction that we killed its ability to be useful.
The real skill is sequencing.
Agentic AI is not a search engine you query once. It's a collaborator you build with — step by step, output feeding the next input, each artifact narrowing the possibility space for the next agent in the chain.
When I figured this out, my development velocity changed. Dramatically.
The Derivation Chain: How I Actually Build Now
Here's my workflow, distilled. I call it the Derivation Chain — every artifact you produce becomes the foundation for the next one. Nothing is created in a vacuum.
Phase 1 — The Foundation (Identity Layer)
It always starts with an idea and a name. But most of us stop there and jump straight to code. That's the mistake.
Instead, I let the name derive everything else:
Name
└─► Vision & Mission
└─► Core Values
└─► Brand Guidelines + Copy Tone & Language
└─► Color Palette + Style Guide
└─► Component Guide
└─► Framework-Specific Best Practices
Every step is a sequential prompt to an agentic AI, and every output becomes the context document for the next step. The AI doesn't guess. It derives.
By the time I'm done with Phase 1, I have a living design system that's coherent from the name all the way down to the button radius. Not because I manually crafted it — because I sequentially derived it.
This is the part most devs skip. And it's the part that saves you the most time later.
Phase 2 — The Problem (Product Layer)
Once the foundation is set, I turn my idea into a Problem Statements file. Not a feature list. Not a backlog. A structured document that clearly articulates:
- Who is suffering?
- What are they suffering from?
- Why do existing solutions fail them?
- What would a meaningful resolution look like?
The agentic AI helps me write this, but I drive the content. The AI's job here is to help me think clearly, not to invent problems I don't have.
Phase 3 — The Architect (Solution Layer)
Here's where it gets interesting — and counterintuitive.
Once I have the Problem Statements, I bring in what I call the Unbiased Architect.
The rule is strict: the Architect sees zero existing code.
Why? Because existing code carries compounding mistakes. If your codebase started with a bad architectural decision six months ago, and you show it to an AI and ask "how do we build on this?" — you get solutions built on top of flawed foundations. The AI inherits your tech debt intellectually.
The Unbiased Architect reads only the Problem Statements. From there, it defines the ideal solution architecture: bounded contexts, data contracts, state machines, service boundaries — without being anchored to what you've already built.
The Architect's deliverables:
Problem Statements
└─► Ideal Solution Architecture
└─► Domain Models & Data Contracts
└─► Service Boundaries & Bounded Contexts
└─► Agent Bill of Materials
Phase 4 — The Agent Bill of Materials
The last output from the Architect is what I call the Agent Bill of Materials (or Agent Bill Request): a document that defines:
- How many agents are needed
- The scope and responsibility of each agent
- The handoff contracts between agents
- The individual guide each agent should operate under
Think of it like a staffing plan — but for AI agents that will execute work in parallel, each with their own bounded domain and clear success criteria.
From this point, the execution phase begins. Each agent gets its own brief and works within its lane. The chaos of "just ask the AI" is replaced by structured, accountable parallel delivery.
Why This Works
The magic of this approach is that it solves three fundamental problems with agentic AI development:
1. Context Coherence
Every document feeds the next. By the time you're writing code, the AI has absorbed your brand, your values, your problem space, and your architecture. It's not guessing your intent — it's operating from a rich, layered context.
2. Architectural Integrity
By separating the Architect from the Builder, you prevent the AI from inheriting and amplifying your existing mistakes. The ideal solution exists independently of the messy reality of your current codebase.
3. Parallel Execution Without Chaos
The Agent Bill of Materials gives each agent a clear scope. Parallel execution becomes possible without agents stepping on each other's work, because boundaries are defined upfront.
The Mindset Shift
The real unlock is this:
You are the Director. The AI is the department.
You don't tell a department head every keystroke to make (micromanagement). You also don't hand them a napkin sketch and say "build the company" (deity worship).
You give them:
- Clear context
- A defined scope
- Outputs from the previous phase as their input
- Freedom to operate within those constraints
That's it. That's the workflow.
Practical Checklist
If you want to try this yourself, here's the order of operations:
- [ ] Start with a name and idea
- [ ] Derive: Vision & Mission → Core Values
- [ ] Derive: Brand Guidelines → Copy Tone → Color Palette → Style Guide
- [ ] Derive: Component Guide → Framework-Specific Best Practices
- [ ] Write Problem Statements (AI-assisted, human-driven)
- [ ] Engage the Unbiased Architect (no code access, problem-only context)
- [ ] Generate the Agent Bill of Materials
- [ ] Execute with scoped agents
Closing Thought
We're in a weird transitional moment. The tools are powerful enough to genuinely accelerate professional development — but most developers are either over-trusting them or under-utilizing them.
The devs who win in this environment won't be the ones who master prompt engineering. They'll be the ones who master workflow design — who understand that agentic AI is most powerful when it operates inside a well-designed sequential system, not as a standalone oracle.
Build the system. Let the AI fill it.
The best ideas don't always come during sprints. Sometimes clarity arrives when you step back.
If this resonated, drop a comment — I'm genuinely curious how others are structuring their agentic workflows.
Tags: agentic-ai devworkflow productivity aitools softwaredevelopment
Top comments (0)