Are you tying your agents in knots?
I've been spending a lot of time lately experimenting with agents and building multi-agent harnesses. My focus has been on product development using Domain Driven Design (DDD) with strong specifications. I'm on about the fifth rebuild and I've learned a bunch of things along the way and I thought I'd share. One lesson I've learned is finding the right level of specification.
I started on this path about 8 months ago in Feb 2026. Something to keep in mind is that the models and agent systems have changed significantly and keep moving fast.
As a first round of the system, I created a very simplistic set of prompts and subagents to manage projects. There was very little structure and I gave high level requirements. At some point the system became so inefficient that it would chew through tokens very quickly and at the same time produce work that wasn't particularly good. Under-specification.
"Turns out in 2026 BDD scenarios are a fantastic way of specifying code implementation!"
The next iteration, I tried putting together some principles for the system to use when operating and I agreed on a system of proposals, ADRs and implementation. Part way through I was reminded of Behavioral Driven Development (BDD). I had tried BDD early on with llms and it was a miserable failure, so I had forgotten about them. Turns out in 2026 BDD scenarios are a fantastic way of specifying code implementation! Unfortunately, between technical issues and adopting BDD part way through, this iteration hit a dead end. Under specification.
One of the things I found lacking was the architecture specification. BDD was proving to be good for implementation agents, but there needed to be some form of product management and architecture to keep everything in sync. This is where I started out with BDD up front and some DDD for breaking out bounded contexts. I also created a product owner function that helped formulate requests for the system. And I tightened down the principles to be diligent about how the BDD implementation was followed and scrupulously accounting for prior decisions. This system got really far. I had multi-agent orchestration with message passing and a lead coordination agent. I would ask for functionality and it was doing a great job of delivering improvements.
"It was editing a six thousand line module."
But then it broke down. I had not paid close attention to the implementer prompts. I kept thinking, "I should work on those prompts", but the features kept coming out right, so why go too deep? Well, at some point I noticed a relatively simple feature was taking a really long time to implement. Why is that? Because it was editing a six thousand line module. The more I dug in, the more rot I found. The large files were due to principles I had specified that pushed the implementers in this direction. This coincided with a breaking point in the design of the system: the decision context got too large. Whenever I tried to correct problems, existing behaviors and decisions were being missed. I realized, too late, that I needed a progressive disclosure system for the design artifacts, but the weight of the context problems crushed any of my efforts to dig out. Over-specification and under-specification.
"I'll make a new system, with a new set of principles!"
Well, I know how to fix this! I'll make a new system, with a new set of principles! Define what good looks like up front (make sure those implementer prompts are good). Use existing best practices for product management and architecture (don't invent new stuff - what the heck is a PDR?). Good strong artifact schemas with front-matter to help support progressive disclosure. And a strong process specification system with review stages to keep the quality up to par.
"It was a disaster."
It was a disaster. I never really made it anywhere between the heavyweight product operating model and the many review cycles that "define quality up front" led to. The system got so bogged down in building the basic framework that I had to cut my losses before making much progress, which was disappointing given the previous iteration had been able to get at least some work done. This was massive over-specification. It started from the very beginning of drafting principles and the system deciding early on that everything needed many, many quality reviews. The Product Operating Model was completely overblown and just getting work into the system was a trial (not to mention new terminology like bets or appetite).
"The key is to sample their work."
So, are you over or under-specifying work for your agents? The key is to sample their work. I don't try to look at the code too often and certainly don't do PRs for everything. But I do peek at the code from time to time to see how things are being built. Having a strong specification system will at least have a better chance of getting what you want out of the system.
Things to look out for:
Requests that seem to take much longer than they should.
- Over-specification with a heavyweight process
- Under-specification on code quality that has created an unmanageable system.
- Recommendations:
- Have the agent analyze its own work and show you where the inefficiencies are.
- Review your implementer prompts and look at using skill plugins like superpowers with tdd.
Requests that seem to get lost or forget prior decisions.
- Over-specification with too many decisions or decisions with too much content
- Over-specification with retired decisions getting pulled into context.
- Recommendations:
- Keep decisions short and to the point. A full ADR is good for the record but a waste of context and potentially confusing for an agent.
- Remove old decisions or put decisions reading behind commands that will filter. Agents love scanning files and don't always ignore what they should
"An agent will tie itself in knots if you give it too many complex rules to follow and it tries to resolve everything."
Requests that come back with lots of clarification questions or use odd language.
- Over-specification with too many principles and instructions. An agent will tie itself in knots if you give it too many complex rules to follow and it tries to resolve everything.
- Under-specification of vocabulary. We all know that agents have their favorite words and phrases, and they will frequently re-use terms for different meanings.
- Recommendations:
- Principles seem like a great idea, but they should be simple and easy to follow without contradicting each other.
- Create a glossary and hold your agents to using it to keep conversations and artifacts clear and concise.
Is there a middle ground? Probably. The next iteration is under way and looks promising. I'm trying to find that sweet spot where the system is specified just enough that it is sustainable without collapsing under its own weight while still giving good results. More on that later.
