
Do not index
Do not index
DRY, or “Don’t Repeat Yourself,” is a common principle in software development. It encourages you to avoid duplicating logic across a system and instead extract reusable components. I’ve started applying that same mindset to how I work with agents. The context you provide is what powers them. And when you’re dealing with a swarm of agents, it’s easy to end up repeating that context across tasks. But over time, I’ve found that the more I can extract scalability into tools and structure, the better the system works. One area where that has really paid off is in how I manage agent instructions.
When I first started using AI agents, I wrote a single instruction file that included everything. It covered how to write content, how to generate code, naming conventions, test coverage expectations, and more. It worked well in the beginning, but as the number of tasks and domains grew, maintaining that one file got harder. I found myself repeating information and updating the same concepts in multiple places. It slowed things down and introduced errors.
One File Wasn’t Built to Scale
As I added more responsibilities to agents, the all-in-one instruction file became a liability. Updating one part would often have side effects somewhere else. Instructions for code could accidentally overwrite important notes for content. Sometimes small edits would break parts of the workflow that weren’t even related. The more I tried to keep everything centralized, the more fragile the system became.
So I Broke It Up
I started organizing my agent instructions into smaller, modular files by domain. One for code. One for content. One for operations. Each file was focused and easier to reason about. If I needed to update something, I could do it in one place without worrying about side effects elsewhere. When I launched a new task or agent workflow, I could copy the most relevant file, tweak a few lines, and get moving quickly. It saved time, reduced errors, and made the entire system easier to maintain.
DRY Isn’t Just for Code
The shift to modular files helped me apply the same thinking we use when we write software. Don’t repeat yourself. Don’t couple everything in one place. Create components that can be reused and swapped without breaking the whole system. It made my agent workflows feel lighter and more flexible, and it helped me delegate more confidently.
Where I’m Headed
I still use this modular system for most of my agent instructions. It’s been reliable and easy to scale. But lately I’ve been exploring another direction: lightweight graph-based workflows that route agents through connected instruction nodes instead of standalone files. It’s still a work in progress, but I think it will let me build even more flexible systems that can adapt as needs change. I’ll share more about that soon.
TLDR
Modular instructions helped me scale my agent workflows and reduce the overhead of managing tasks. If you’re repeating yourself or worried about breaking things with each change, try splitting your instruction files by domain. It’s a small shift that makes a big difference when you want to move quickly and keep things reliable.
And that’s it! What do you think? I would love to hear your thoughts. For more insights like this, subscribe to my newsletter: https://thebuildingblocks.substack.com/