Better workflows for exponentially better agents
Agents have context windows. So do we.
When managing several agents at once, human context becomes precious. Remembering why a decision was made, what remains unresolved and where each task stopped can become more work than writing the code.
The bottleneck is moving to us. Agents can carry more of the execution, but someone still has to decide what matters. Constantly switching between their questions, reviews and unfinished work is exhausting.
I use four workflows to reduce that overhead:
- Proposal
- Challenge
- Implementation
- AI Code Review
They turn goals into repeatable cycles, preserve the reasoning behind decisions and let agents handle routine work without needing my next prompt.
The good news is that part of this is a skill issue. We can learn to delegate better.
Preserve context and executive decision making
Context is not just attention. It is the working understanding behind a task: the problem and its constraints. It also includes the decisions already made and the reasons for them.
Returning to a task means recovering that understanding. Doing it once is manageable. Doing it repeatedly across several agents gets tiring, especially when each conversation leaves the next step for me to figure out.
Consider a billing change. An agent finishes the implementation and reports a review finding. I reconstruct the context, explain the fix, then try to remember what I was doing before the interruption.
Congratulations. I have automated the coding and promoted myself to clipboard.
A useful workflow carries that context forward instead. The review names the violated rule, points to the code and explains how to verify the correction. The implementation pass fixes it and returns the evidence. The original constraint stays attached to the work.
I still review the result. What disappears is the repeated work of translating, remembering and reconnecting the steps.
That leaves more room for executive decision making: should this feature exist, which trade-off is acceptable, and what must not change? Those are the decisions I want to spend my energy on.
Build cycles that get better as agents improve
Giving an agent a goal is not the same as defining it.
Without a Proposal and Challenge cycle, how do we know which constraints are real invariants and which are variables we can change? An agent can finish a task while solving a different problem from the one we intended.
These four workflows make the reasoning explicit.
Proposal
Make a first-principles proposal: define the problem, the business rules and the smallest sufficient solution. Separate invariants, which must remain true, from variables we can choose or change. Define the evidence that will show the work is complete.
The agent can do most of this investigation. My job is to understand the consequential choices and decide which trade-offs to accept.
Challenge
Question the proposal from first principles. Is this invariant really an invariant? Is the requirement necessary? Could the same goal be reached with less code, configuration or state?
I bound Challenge to two passes. Otherwise, agents can keep designing indefinitely. The purpose is to improve the plan enough to build it, not to pretend every uncertainty can be resolved in advance.
Some design choices only become clear during implementation. Call them out explicitly, including what evidence will be needed to decide them.
Implementation
Build the agreed solution and verify it. The initial pass follows the proposal. The review_fix pass addresses concrete findings from review.
Routine corrections stay inside the cycle. If implementation exposes a new edge case that changes an invariant, scope or accepted trade-off, bring that decision back to the human.
AI Code Review
Use a first-principles review to check the result against the problem and its invariants, not merely whether the code runs. Check what is unnecessary, what could fail and whether the evidence actually supports completion.
Write findings so they are actionable:
- The location
- The problem
- Why it matters
- How to verify the correction
A vague review just creates another translation job for the human.
I have found that the same agent can review its own code surprisingly well. My rough estimate is that it catches around 90% of the mistakes I would otherwise need to address. That is my experience, not a benchmark, and it does not replace human review.
Let the cycle carry the work
The four workflows form two different cycles. One helps me decide what matters. The other carries that decision through to working code. Both save context, but they remove different kinds of work from my head.
Proposal → Challenge: settle the decisions
Before implementation, I want a first-principles account of the problem. What must remain true? What can change? Which tradeoffs actually need my judgment?
The proposal makes those distinctions explicit. The challenge questions them. Is this really an invariant, or just something we inherited from the current design? Does the requirement justify the complexity it introduces?
Consider a failed subscription payment. Whether a customer gets a grace period is a product decision. Once we agree on that policy, the agent can work out how to enforce it. I want to own the tradeoff, not personally design every branch of the implementation.
I bound the challenge to two passes. Otherwise, an agent can keep designing forever. Choices that cannot be resolved until implementation should be called out explicitly, not hidden behind a confident proposal.
The result is a decision with its reasoning written down. I no longer have to remember every rejected alternative or explain the same constraint in each session. The context survives outside my head.
Implementation → AI code review: carry the decision through
Once the direction is approved, I do not want to become the messenger between a review finding and its fix.
Implementation produces the code. First-principles AI code review checks whether it actually satisfies the agreed requirements. Findings must be actionable: what is wrong, why it matters, and how to verify the correction.
Those findings feed directly into implementation(review_fix), followed by another review. The next instruction is already defined. I do not need to compose another prompt just to say, “Fix what the review found.”
In the billing example, a bug that leaves access enabled beyond the agreed grace period belongs inside this cycle. Fix it and verify the result. But if implementation reveals that the policy cannot be honoured without changing another customer promise, that comes back to me.
A defect is work for the cycle. A new tradeoff is a decision for the human.
The cycle ends when the agreed work is verified and review findings are resolved. It pauses when it reaches a decision or permission outside its scope. I still review the result; passing checks is evidence, not a guarantee.
This is why we need both cycles. Proposal/challenge saves me from repeatedly reconstructing why we chose a direction. Implementation/review saves me from repeatedly re-entering the details just to move the work along.
I can return to a clear result or a specific decision, rather than spend the afternoon asking, where were we again?
For the companion developer article: How to get the most out of your coding agent.
Make it easy to pick up where I left off
Stepping away should not mean starting over. A useful workflow records what was decided, why it was decided, and what remains open. The implementation and its verification evidence sit alongside that record.
I should not need to reread an entire conversation to understand whether a finding was fixed or merely discussed. An unresolved question should still look unresolved tomorrow. A decision should come with enough reasoning that I do not have to make it again.
That is the difference between saving a conversation and preserving context. One records everything that happened. The other makes it clear where to continue.
Better agents should mean less to carry
If every improvement in agent capability leaves me supervising more work, I have moved the bottleneck rather than removed it. The agents are doing more, but I am still carrying the project in my head.
The good news is that delegation is a skill. We can learn to define consistent goals and recognise which tradeoffs need our judgment. That instinct takes practice, but it is not reserved for experts. These four workflows give beginners and experienced developers a structure to practise it.
I want better agents to carry more of the work inside those boundaries, not make more of my decisions by accident. The point is not to keep up with everything the agents do. It is to preserve enough context to decide what matters.