Golden Circle 4: From Playbook to Execution — Plans Change, That's the Point

In the previous article, we operationalized the methodology into a Playbook [4], worked through the three catalysts of Facts, Scenarios, and Tools that transform a methodology into a Playbook, and watched a 490-line mixed document get split into three. Are we done?

Almost. A Playbook is a set of generic patterns — no timeline, no assignment of who does what, no discussion of resource constraints. It’s a menu and a recipe book. So we still need a Plan.

An Execution Plan is tonight’s prep list and step-by-step procedure. The recipe tells you how to make kung pao chicken; the prep list tells you “have the chicken diced by 6:00, go buy peanuts at 5:30, the right burner is broken so use the left one.”

Contextualized Decision-Making — What Does It Take to Go From Playbook to Plan?

Going from Playbook to Execution Plan requires contextualized decision-making, which involves three things:

Situation Assessment

The Playbook might have ten scenarios, but which one are you currently facing? How severe is it? What constraints exist?

In my case, the plan’s first step wasn’t to jump straight into running detection loops, but “preliminary research”: measuring the actual current baseline. The key word here is actual — values measured by actually running the system, not estimates the Agent calculated by reading the code. Knowing which metrics are measured versus which are estimated matters a great deal. Only by clearly labeling them can you turn a Playbook from “generic” into “relevant to me.”

Prioritization & Trade-offs

The Playbook tells you how to handle each scenario, but it won’t tell you which one to tackle first when multiple scenarios hit at the same time — because that’s a judgment call shaped by the people involved, the plan, and the business environment.

This requires ranking by impact and urgency [2], an explicit “not doing” list, and dependency analysis. In my case, for example, the preliminary research had to be completed first before we could know which detection loop improvements would deliver the most value — you can’t skip the research and jump straight into fixing checks.

Commitment

The most critical step: turning “should do” into “who will finish what by when” [1] — assigning owners, timelines, resource allocation, and success criteria.

Plans Change — That’s the Point

Something happened in my case that perfectly illustrates why plans need to be managed separately from methodology and Playbook.

The first version of the plan was a four-phase sequential approach: Phase 1 Establish Ground Truth, Phase 2 Improve Detection, Phase 3 Launch Discovery Loop, Phase 4 Continuous Evolution. Very formal, very thorough.

But once we actually started executing, the CEO reviewed the plan and felt it was too theoretical, too ambitious. He directed us to switch to a PR-driven model: each check improvement becomes a PR, no need to wait for an entire Phase to complete before moving forward.

So we did something: methodology untouched, Playbook slightly adjusted, plan massively overhauled.

The methodology’s three-loop closure, three cores, and vulnerability protection [3] — these principles didn’t change at all, because the CEO’s decision still fell perfectly within the methodology’s direction. The Playbook’s operational procedures got some adjustments (from formal closed-loop cycles to a PR-driven workflow), but the core concepts were preserved. The plan, however, was almost entirely rewritten: four phases became a PR checklist, the formal Ground Truth registry was dropped, and metrics were simplified from systematic tracking to “violation count before and after improvement + false positive rate.” This turned the entire plan into an MVP-driven model, streamlined enough to be implemented and validated in a very short timeframe. We could then adjust based on actual results going forward — potentially even growing back into the original plan over time.

This is why the three levels need to be managed separately. If you write methodology and plan in the same document, when the plan changes, you’ll accidentally change the methodology too. But methodology is the stable “why,” while the plan is the shifting “what we’re doing now” — mixing them together only makes both lose clarity.

And most importantly: plans changing is normal. Beyond the “what,” we also added “where are we now?” to the plan. This “where” is tied to progress, timing, and current context — so when the plan changes, it doesn’t mean the previous version was wrong; the context simply shifted. A good plan isn’t one that never changes, but one where you know where you stand, which layer to change, and which layer not to touch when things shift.

Back to Agents — Why This Matters Especially for AI Collaboration

You might be thinking: isn’t this just traditional project management? Theory to Methodology to Playbook to Plan — isn’t this common knowledge in software engineering?

The difference is this: in traditional project management, the executors are humans. Humans have tacit knowledge. Even if the plan isn’t fully detailed, experienced people will automatically fill in the gaps. Judgments not written into the SOP? A senior colleague just knows what to do.

But Agents have no tacit knowledge.

An Agent only knows what you tell it. If you only give it method-level instructions (“do A then do B”), it’ll get stuck when it encounters a situation that falls between A and B — or worse, it’ll quietly guess a solution and execute it, just like we saw in the timezone blind spot article [5].

But if you also give it Playbook-level guidance (“all judgments must be based on factual signal sources,” “when a contradiction is detected, investigate one round independently before escalating”), it has a judgment framework to rely on when facing new situations. If even the judgment framework can’t resolve the issue, it escalates to the methodology for guidance. Without any of this, you’re gambling — betting that what the AI constructs matches what you had in mind, or even that the AI’s guess is what you’d want. This is why this chain matters even more when collaborating with Agents than with humans:

Methodology is what upgrades an Agent from “following instructions” to “understanding why it’s doing things this way.” The Playbook then upgrades it from “asking you every time” to “handling common scenarios independently.” And the plan lets the Agent know “what we’re working on now, what’s next, and what’s the priority.”

The Complete Chain

Each layer down is a journey from “generic” to “specific,” from “possible” to “certain.” The further down you go, the less flexibility — but the higher the executability.

And most importantly: this chain isn’t one-directional. When an execution plan hits a wall in practice, it feeds back into the Playbook. If the Playbook changes touch the principle level, they feed back into the methodology. And if methodology updates challenge the original theoretical foundation, that’s a new discovery.

In my case, the v1 plan hit a wall (too ambitious), which fed back into a simplified Playbook (PR-driven). But the methodology’s three-loop closure and three cores didn’t budge at all — because the problem was at the operational level, not the principle level.

My Observation

After walking this entire path, I feel the most important thing to remember isn’t what each layer is — it’s which layer most people skip.

If your experience collaborating with Agents is “it can follow instructions, but falls apart on exceptions,” the problem likely isn’t that the Agent isn’t smart enough — it’s that you only gave it method-level (Playbook) material and it’s missing a methodology-level judgment framework.

If your experience is “the Agent’s Playbook looks great but is unusable,” the problem might be in the three operationalization gaps: did you first establish your Facts? Did you list the Scenarios you’ll actually encounter? Did you pair them with corresponding Tools?

If your experience is “the plan is outdated the moment it’s finished,” that’s not a problem with planning — it’s that you mixed the plan with the methodology, so when the plan changes, everything falls apart.

Perhaps the most practical advice is this: next time you give an Agent a new task, ask yourself three questions first:

1. Have I told it “why” to do things this way? (Methodology)
2. Have I told it how to handle common scenarios? (Playbook)
3. Have I told it the current situation, priorities, and constraints? (Plan)

If you have all three, the Agent has enough Context to make reasonable judgments when facing new situations. If you only have the third, you’re just giving it orders, not collaborating with it.

Perhaps this is the line between “using an Agent” and “working with an Agent”: whether you’re willing to spend the time teaching it the “why” that’s in your head.

References:

[1] Project Execution Plan vs Project Management Plan — 123Worx https://123worx.com/blog/differences-between-project-execution-plan-and-project-management-plan/

[2] Prioritization Matrix — Atlassian https://www.atlassian.com/team-playbook/plays/prioritization-matrix

[3] Mindset 5: From Theory to Methodology — previous article in this series /en/articles/17-mindset-theory-vs-methodology

[4] Mindset 7: From Methodology to Playbook — previous article in this series /en/articles/19-mindset-methodology-to-playbook

[5] Tips 4: Agent’s Timezone Blind Spot — implicit assumption case study /en/articles/16-tips-agent-timezone-blind-spot