By the end of the first week of a two-week MVP build for the Tech Council of Australia, I had a fully configured technology stack, more than 150 well-structured GitHub issues, and almost nothing a user could touch.
The agentic workflow was producing plenty of output. It just wasn’t moving the product towards release.
We recovered and shipped the MVP on time. But that first week exposed an easy trap. An agent can keep making a plan more complete long after the plan has stopped helping you ship.
The plan and week one’s reality
The Tech Council of Australia needed something real. Members logging in and using it, ready to put in front of their team within two weeks.
The budget ruled out the team size and runway a project like this would usually get. We knew we’d need to move fast, decide early, and keep scope tight.
My goal for week one was a rough skeleton. It didn’t need to be finished, but a user should have been able to click through the main journey and see the shape of what we were building.
Instead, week one ended with a thoroughly configured stack but little of the product itself.
This particular engagement gave us room to explore how agent-led delivery worked on a real project. That first week showed us that the agents were completing plenty of work, but the product wasn’t moving forward
When planning became the work
Wayfinder is an agent skill that takes a rough problem and helps explore the decisions inside it. I pointed it at the full MVP scope, running on Opus 5, and gave it too much room to run.
By the middle of week one, it had generated more than 150 GitHub issues. Structured, detailed, covering nearly every corner of the problem. Also almost entirely disconnected from what we needed to ship next.
The backlog compounded. One issue would spawn four more, and each of those spawned more again. Each individual output looked useful, so it was easy to mistake all that activity for progress. The plan kept getting more complete while the product lagged behind.
Restoring a critical path
Using an agent to plan the project was fine. The mistake was letting one planning loop take responsibility for the whole problem.
I stopped, cleaned up the issue backlog, and rebuilt a critical path around the smallest usable version of the product. I also moved from Opus 5 to Opus 4.8. Opus 5 kept finding opportunity in every issue, spinning off more issues and chasing problems nobody had asked it to solve. Opus 4.8 was more literal. It avoided new scope rather than hunting for it, and within the first hour I felt a sense of control and structure I hadn’t had all week.
The real change was separating the jobs I’d asked the agent to do.
Wayfinder helped explore the problem and make decisions. Once those decisions existed, we moved them through to-spec and to-tickets, then into implementation. I stopped asking the planning process to keep solving every new problem it uncovered. That gave each agent a more bounded job, and gave me back control of the sequence.
Planning and implementation are different jobs. An agent can help with both, but someone still needs to decide when enough planning has happened and what ships next.
Where the workflow accelerated us
Once the critical path was back, the same tools became genuinely useful.
We’d planned to deploy on AWS. I knew it well, which would have saved us time on a two-week build. Partway through the project, constraints outside our control took AWS off the table.
We moved to Cloudflare Workers instead, a stack I'd never used in production and little room for a normal learning curve.
AI helped translate the architecture we’d already designed into a Cloudflare equivalent, and configure the Terraform setup around it. It also cut down the research needed to compare Cloudflare against Vercel, Netlify, Railway, and AWS for this workload.
By the time I spoke with the Thinkmill team members who had actually run production workloads on Workers, I wasn’t starting from zero. I had enough understanding to ask useful questions. They helped steer real decisions. They ruled out Keystone CMS, which couldn’t deploy on Workers in the time we had, and mapped the AWS services we knew onto Cloudflare’s equivalents, R2 for S3 and D1 for Aurora.
The same pattern showed up in authentication, the Zoho CRM integration, and the private document library. Each meant getting up to speed on something unfamiliar fast enough to pick an approach that fit the timeframe.
AI shortened the distance between hitting something unfamiliar and being able to make a reasonable engineering call about it.
It didn’t make the decisions for me. I still had to work out what belonged in the MVP, where the risk sat, and when an answer was good enough to ship.
What shipped
Two weeks after starting, the MVP was live.
Members could log in with OTP and passkeys, access their profile through the Zoho CRM integration, and use a private document library, running on infrastructure I hadn’t expected to touch when the project began.
The workflow lesson here is more general than Wayfinder.
The agent produced a thorough plan. The mistake was confusing that growing body of planning work with progress towards a usable product.
Planning is where a workflow decides what matters, and that’s exactly the decision you don’t want to hand over completely. Give a planning phase full autonomy, and everything downstream, the specs, the tickets, the implementation, inherits whatever it decided to chase. Spend less time automating that phase, not more. The rest of the workflow can move fast precisely because that one decision was made carefully.
