Agents that Design Agents: Start with the Idea
The fastest way to build a working AI solution is to get the idea right first. An "idea brief" agent helped me do that in a matter of minutes.
Last week I wrote about catching myself holding onto manual steps in my own work — steps I'd kept doing by hand out of habit, long after AI could carry more of them. Here's what letting go of one looked like.
Monday morning I had my first call with a prospect: a bank, exploring whether a small AI agent could take some load off its internal-comms team. By the end of that morning I had a written idea brief, a design, and a work plan. By the next morning — about a day after that first call — I had a working prototype ready to demo.
But the speed isn't really the interesting part.
Keep the judgment. Compress the work around it.
When I sit down to design an AI solution, there are decisions I still want to make myself. What problem are we actually solving? For whom? What would a useful solution look like, and how would we know if it worked? Is this the right shape, or just the first shape that came to mind?
That's the judgment, and it stays mine.
Around those decisions there's a lot of work — framing the idea, drafting the UX, writing stories, documenting the architecture, organizing the work plan. All of that design work used to take me a day or more before I could start building anything. I still own and steer the judgment. The work around those decisions is what I can compress.
I've built three small agents for the three stages I move through before I build: idea, design, and architecture. Agents that help design agents. This post is about the first one.
The temptation is to start building
The idea step sounds simple enough that it's easy to rush through. We know roughly what we want, so we start building the thing.
That's also where a lot goes wrong. We skip over the actual problem, don't get specific enough about who we're solving for, and start from a picture of what the solution should be and work backward.
The idea-brief agent is meant to make that part intentional. It runs a short interview, one question at a time, and it's quietly stubborn about vague answers. Tell it a solution will "save time" and it wants to know what actually goes wrong today. Describe something too broad and it checks whether you're really talking about one agent or a whole system you've folded in under one name.
What comes out is a written brief — what the idea is and why it matters, who it's for, the problem underneath it, what "done" looks like, what's out of scope, and what's still unresolved.
For the bank, I started with one sentence: monitor an internal-comms request inbox, turn each request into a structured record, and — depending on how complete it is — either draft a brief or draft a reply asking for the missing details, with a person reviewing every output before anything goes out.
The idea-brief agent, starting its intake from a single-sentence idea.
The interview forced specificity around the problems underneath that sentence. Requests were arriving informal and incomplete. The manager was personally chasing people across the department for what was missing. And there was no simple way to see what was sitting in the queue. None of that was in my one sentence, and all of it mattered.
A target we can both work from
The bigger benefit is that the brief gives me and my AI collaborator the same target: one written understanding of the goal, the audience, the problem, and what success looks like. Something we both work from, and both adjust from when new information shows up along the way.
That's what makes it more useful than a good mental model I keep in my own head. Once the target is written down, the next agent can use it, and then the next one.
That Monday morning, the idea brief was done at 9:38, the design at 9:48, the architecture at 9:57 — the full idea-to-design-to-architecture pass in under twenty minutes, after the call. Another half hour or so went into putting the epic and stories into Jira, but the substance was already there. What matters about those timestamps is how far the planning work compressed once the judgment was explicit.
The prototype itself took longer — roughly a day, loosely tracked, for something I'd never built before. I was still making the decisions throughout. The agents carried much of the framing, drafting, and planning around those decisions.
That left a solid baseline to build from, and enough clarity to keep improving as I went. A dashboard that wasn't part of the original request became an obvious addition once the rest of the experience was taking shape.
Before you build
Understanding the progress someone wants to make, how they work today, and where AI can make things easier doesn't always have to take days or weeks before you can start building. With the right discipline, that work can happen in under an hour. Not because you skipped the thinking, but because you optimized for where your judgment mattered most while using AI to compress other steps.
The idea brief is the first shared target. The next one is the design — what the experience should actually be, once you know what you're solving and who you're solving it for. That's where the next post picks up.