Part 5 of Building My Agentic Workflow in Public, and the open end of it. Part 4 got me an autonomous build loop. This one is about a fork I am standing at right now, with no final answer yet.
The last four parts had endings. This one has one, but a provisional one. I am still in the middle of it, and the whole reason I write these in public is to think out loud while the question is still live.
Here is the fork. I have a loop that can build a batch of features mostly on its own. There are two very different ways to run that loop, and they pull in opposite directions.
The portable way
The first is what I built in Part 4: a loop made of plain commands, a skill that orchestrates, and a few sub-agents one level deep. Its best quality is that it is boring, in the good way. The instructions are just text. Nothing about them is welded to one specific tool, and in principle the same approach could run on a different model entirely. It is steady, it is simple to reason about, and it goes almost anywhere.
Because the instructions are just text, I can show you the shape of one without giving anything private away. Here is the orchestrator, sanitized:
The skill that runs the loop (sanitized /ship-features)
Plain instructions, no code. It reads a range of features and walks each one through the same cycle. The try-limits live in a tiny separate script so the model cannot talk past them.
---
description: Ship a batch of features on their own. For each one, vet the
ticket, build only a clean ticket, then review the result. Stop and ask
me after a few failed tries.
argument-hint: <feature range, e.g. F1.1-F1.8>
---
For each feature in $ARGUMENTS:
1. Evaluate the ticket. If it has blocking gaps, fix them, up to 3 tries.
2. Only a clean ticket gets built. Hand it to the implementer.
3. Evaluate the result the same way, up to 3 tries.
4. Keep the try-counters in a small script, not in your own head, so the
limit cannot be negotiated.
Never auto-commit. On any hard limit, stop the whole batch and ask me.flowchart TB S["A skill orchestrator<br/>(plain instructions, portable)"] S --> A["A few sub-agents,<br/>one level deep"] A --> R["Steady and simple,<br/>runs almost anywhere"]
The cost is ceiling. One level of sub-agents and a mostly sequential loop will only go so fast and so wide. For the work I have thrown at it, that has been fine. For bigger ambitions, I can feel the limit.
The powerful way
The second is a dynamic workflow. This one is not something I built. It is a feature built into Claude Code itself, which Anthropic shipped on May 28, 2026, still as a research preview. Instead of a fixed set of commands, it generates code, JavaScript, on the fly to drive the loop, and that unlocks a different scale: many agents running in parallel, a process that can churn for hours, far more happening at once than I would ever orchestrate by hand.
flowchart TB W["A dynamic workflow<br/>(generates code to drive the loop)"] W --> P["Many agents in parallel,<br/>running for hours"] P --> R2["More raw power,<br/>tied to one platform"]
The cost here is the mirror image of the other one. All that power is tightly coupled to a single platform. The portability I liked so much in the first approach is mostly gone. I would be trading “runs anywhere” for “runs hard, here.”
What happened when I ran both
So I stopped guessing and ran the same batch through both, on real work. The dynamic workflow won, and not by a little. It needed about five times fewer interruptions, it ran in the background while I did other things, and the code came out at least as good on every axis that mattered. On one feature it even caught a runtime bug that my portable skill had shipped without noticing. On my scorecard it came out ahead, 25 to 21.
The portable skill only beat it in two places: it kept an on-disk record of what happened, and it could resume across sessions. Both real, both mine, and both small next to everything the workflow did better.
So I did the obvious thing. I took those two strengths from my own skill, the on-disk audit trail and the cross-session resume, and I built them into the dynamic workflow. The gap that made me hesitate is mostly closed now, and it is closed on the more powerful side.
Why portability keeps winning my attention
There is a reason I keep leaning toward the portable side, and it is bigger than this one decision. Every piece of this series has been quietly pointed at the same goal: a personal system I actually own, that runs on my terms, that I can move and keep and understand. I have been thinking of that direction less as a product and more as a principle. My process and my skills, packaged so they move with me across any model or machine, instead of living inside one vendor’s walls. That is where I want all of this to land.
Something you can pick up and run on a different model next year fits that goal. Something welded to one vendor’s platform fights it, no matter how powerful it is on a good day. So when I weigh power against portability, I am not weighing them evenly. I am weighing them against where I am trying to go.
Where the series lands
That is the whole arc, at least so far. It started in Part 0 with a problem: the tools got faster and my brain did not. Everything since has been one answer to that, built in layers. A process so I stop starting from scratch. Handoffs and sub-agents so the work survives the context window. A contract so many agents can build without diverging. A loop that runs within limits I set. And now a choice about how to run that loop, which is really a choice about how much I am willing to depend on any one tool.
So here is where I have actually landed, for now. I am using the dynamic workflow, because today it gets me where I need to go, and I have taught it the two tricks my portable version did better. But I am not done with the portable one. I keep sharpening it on the side, because the one thing I will not give up is portability, not being locked to a single vendor. The day my own portable setup scores better than the workflow is the day I move back to it. That is the real finish line, and I am not there yet.
I do not have the final ending yet, only that provisional one. That is the honest part, and it is also the point. I am building this in the open, one layer at a time, and the next post in the series will exist because I built the next thing, not because a calendar told me to. If any of this is useful to you, or if you have walked a version of this road yourself, I would genuinely like to hear how it went.