Monday, November 11, I was building workers for the first workflow. Each worker needed context – what patterns to look for, what correct output looked like, why these rules mattered.
So I wrote it all in the worker files. Context, examples, rules, execution steps, all together.
It was a mess. But a familiar mess.
Recognition
Worker files were impossible to follow. Steps drowning in context. Explanations interrupting execution flow. Examples scattered throughout instructions.
I’d seen this pattern before. Not in prompts – in code.
Functions that do too much. Classes with multiple responsibilities. Business logic mixed with presentation logic. The symptoms are always the same: hard to read, hard to maintain, hard to change.
The solution is always the same too.
Engineering Principles Apply
I’m a principal software engineer. I think in systems. Single Responsibility Principle. DRY. Separation of concerns. These aren’t just academic concepts – they’re how I naturally think about architecture.
Looking at these worker files, the pattern was obvious.
Workers were violating Single Responsibility Principle. They had two jobs:
- Understand requirements (context)
- Execute steps (actions)
Two responsibilities, one file. That’s the violation.
Workers were violating DRY. Same context appearing in multiple files. Same pattern definitions duplicated across workers.
The fix was obvious. Same fix I’d apply to code.
Separate the Concerns
Context and execution are different concerns. Different responsibilities. They belong in different places.
Workers: Execution responsibility
- Read inputs
- Apply rules
- Write outputs
Standards: Requirements responsibility
- Define patterns
- Provide examples
- Specify rules
This wasn’t a novel insight. This was basic software engineering applied to prompts.
The Architecture
I created standards/ directories alongside workers.
workers/
analysis/
analysis-worker.md
standards/
pattern-definitions.md
migration/
migration-worker.md
Workers became thin executors:
- Read source files
- Read standards/pattern-definitions.md
- Apply standards
- Output results
Standards files held the context. All of it. Detailed, with examples, with edge cases.
When multiple workers needed the same context, they read the same standards file. DRY principle. Don’t repeat yourself.
Systems Thinking
This wasn’t just about making one file cleaner. It was about building a maintainable system.
Maintainability: Change requirements once (in standards), all workers using it get the update.
Consistency: Workers can’t have conflicting instructions if they read from the same source.
Scalability: Adding new workers doesn’t mean duplicating context. Reference existing standards.
Readability: Thin workers are easy to scan. Dense standards are easy to reference.
The same benefits I’d get from good software architecture.
Prompts Are Code
That was the real insight. Not separation of concerns – I already knew that. The insight was recognizing that prompts have the same architectural needs as code.
Prompts can violate Single Responsibility Principle.
Prompts can violate DRY.
Prompts benefit from separation of concerns.
And prompts respond to the same solutions.
The principles I’d been using for years in software engineering applied directly to prompt engineering. I just had to see the pattern.
Monday Evening
By Monday evening, November 11, I had the architecture:
- Workers stayed thin (Single Responsibility)
- Standards files held shared context (DRY)
- Clean separation of concerns
- Maintainable, consistent, scalable system
This wasn’t innovation. This was application of known principles to a new domain.
I’m an engineer. I see systems. I spot patterns. When I saw workers cluttered with context and duplicating information across files, I saw the same architectural problems I’d solved in code.
The solution was the same too.
The Pattern Continues
Over the next few weeks, I’d keep applying engineering principles to prompts:
- Discovering agents could run in parallel (like concurrent processes)
- Building batch execution infrastructure (like CI/CD pipelines)
- Creating quality frameworks (like code review standards)
Every time, the same pattern: See the architectural problem, apply known engineering principles, build the solution.
Prompts aren’t magic. They’re instructions. And instructions benefit from good architecture.
Workers were now thin and focused, delegating to standards files for context. Clean separation of concerns. The architecture felt right.
But as I watched the workflows run, I noticed the coordinator doing an enormous amount of repetitive parsing work. Loop after loop, the same 11 steps: parse, categorize, group, sort, decide. There had to be a better way.