Most agent goals fail before the agent starts. The instruction is vague, the background lives in five different places, and “done” means whatever looked acceptable at the end of a long session.
I fixed that by separating the finish line from the map. The goal stays short and testable. A companion rider carries the background, decisions, sources, and constraints. Here is the seven-step workflow I use.
1. Dump your brain into one messy file
Before I open an agent, I write rough notes under three headings:
- Benefit: what I actually want to change.
- Background: what I already know, including previous decisions.
- Sources: the documentation, examples, or research the work should follow.
This is not the moment for polished prose. Bullet points are fine. Dictation is fine. The goal is to get hidden assumptions out of my head and into a file the next step can challenge.
2. Let the AI interview you
I hand over the notes and ask: “What is unclear?” A useful interview finds vague requirements, missing choices, incompatible constraints, and words like “better” that have no measurable meaning.
I answer one question at a time. The agent updates the requirements after each answer. That loop usually exposes the work I thought was obvious but never actually defined.
3. Brainstorm before committing
Next I run a structured challenge session. The point is not to produce more ideas forever. It is to compare real approaches, name the tradeoffs, and decide.
The result should be a design I trust, including what is deliberately out of scope. If a consequential choice is still open, the build is not ready to delegate.
4. Spend the strongest reasoning where it matters
Model names and rankings change. The durable rule is to reserve the most capable reasoning you have available for requirements, architecture, risk, and review. Routine implementation can move to another agent once the decisions are explicit.
This separation also makes review easier. If the implementation goes sideways, I can ask whether the build violated an approved decision instead of reopening the entire strategy.
5. Hand off the building
The implementation agent gets the approved design, the repository rules, and an atomic plan. It does not get permission to invent a different product.
I ask it to work in small commits, test behavior before and after each change, and report evidence instead of confidence. For larger projects, fresh review agents check specification compliance and code quality between tasks.
6. Package the goal with a rider
The goal contains the objective, non-negotiable constraints, required proof, and stop condition. The rider contains everything that would make the goal unreadable: research, file maps, edge cases, examples, and operational context.
The exact command syntax and size limits vary by agent product and version, so I do not build the workflow around a magic command. The pattern works anywhere an agent can read two files.
7. Define done, then walk away
My last section is always verification. Not “make it look good.” Specific checks: tests pass, routes render, prohibited inputs are rejected, the diff contains only intended files, and the output can be inspected.
That is the system: think hard up front, keep the goal bounded, give the agent enough context, and make completion observable. The better the finish line, the less supervision the middle needs.