Strategic Planning is Context Engineering, Part II

My first essay made the case that strategic planning is evolving into context engineering. That the right output of annual, quarterly, and real-time planning isn't a deck or a Google doc, it's a shared, versioned, continuously refreshed context layer that humans and agents can both operate against.

The reaction I got was: "Makes sense in theory. But how does it work in practice?"

So part II is designed to answer that. This is how I actually built one at Twindo, the wrong turns, the shape it settled into, and the open-source template I'm releasing so anyone else can fork it and see it in action.

This is a working artifact, not a finished product. I expect it to evolve quite a bit over the next 6 months. The point isn't that this specific structure is correct for everyone. The point is that something like this is necessary, and most companies don't use something like it yet. It’s inspired by business’s most successful AI use case to date - using context engineering in AI coding systems to ship faster, and more reliably.

The starting point

When I started thinking about this seriously, the state of strategic context at most businesses was: a 2026 planning deck, a Linear instance that was the truth for product and engineering work, a HubSpot instance that was the truth for sales motion, and a Slack archive that quietly held about 60% of the actual decisions that had been made.

As CPTO, I need an up-to-date version of our business strategy at my fingertips to make decisions and steer product development. I found myself bouncing between different channels, always hunting for the latest info. The knowledge base was in constant flux, with no single source of truth for the current version.

This is not a Twindo problem. It's just how every company I've worked with actually operates. The information is all there, scattered across tools and channels, but it's clunky to get to and most of its value sits untapped.

The first attempt was one big file

My first move was the most obvious one. I created a file called STRATEGY.md and started populating it with our strategic artifacts.

It worked for about a week. It became very large and violated the principles of progressive disclosure that prevents you from burning tokens and filling up context windows. It also became difficult to reference for specific answers to my questions. It improved the AI’s generic output, but only slightly.

Here’s the key learning: long files lose to short files in an agent-readable world. A 200-line file with a clear name is more useful than a 2,000-line file that contains the same information mixed in with other unrelated information.

The second attempt was over-organized

I overcorrected. I drew a sprawling tree:

strategy/
├── annual/
│   ├── bets/
│   │   ├── bet-1/
│   │   ├── bet-2/
│   │   └── ...
│   ├── targets/
│   ├── learnings/
│   └── ...
├── quarterly/
│   ├── 2026-Q1/
│   ├── 2026-Q2/
│   │   ├── product/
│   │   │   ├── roadmap/
│   │   │   ├── discovery/
│   │   │   └── ...
│   │   └── ...

Root and scoped context files - this is progressive disclosure in action. Better organization. Less useful in practice. The agent had multiple plausible candidates for any given question.

The thing I had failed to see is that the file structure has to mirror how a human would describe the question to themselves. "What's our 90-day product roadmap?" should map to one obvious location. "Who are our customers?" should map to one obvious file.

The shape that works

After two more iterations, the structure settled here:

context/
├── company/                # Slow-changing identity
│   ├── identity.md
│   ├── customers.md
│   ├── market.md
│   ├── competitive-landscape.md
│   └── domain-concepts.md
├── strategy/2026/
│   ├── annual-plan.md
│   ├── annual-learnings.md
│   └── Q2/
│       ├── quarterly-plan.md
│       ├── Q1-review.md
│       ├── commercial/    # Revenue, GTM, positioning
│       ├── product/       # Roadmap, discovery, customer signals
│       └── engineering/   # Architecture, capacity
├── decisions/              # Records that don't disappear into Slack
├── signals/                # Competitive + market intel logs
└── meta/                   # The system's own changelog and health

Each file has one obvious owner ("who would I ask if I needed this updated?"), one clear scope, and one place an agent will reliably look. There's a context file at the root that tells any agent - or any new human - which file owns which question.

That index (think CLAUDE.md) is one of the highest-leverage files in the entire system. Without it, agents (and humans) flail. With it, everyone goes to the right place on the first try.

The three things I underestimated

Decisions

I had not planned to build a decisions folder. It emerged after I caught myself trying to remember why we'd made a particular pricing call and finding only fragments in Slack.

A decision record costs five minutes to write and saves hours of "wait, why did we…" later. The format I converged on:

• Context: what made this necessary now

• Options considered: what else was on the table

• Rationale: why this option, what tradeoffs we accepted

• Impact: what changes for commercial / product / engineering

• Outcome: left blank initially, filled in weeks later

The Outcome section is what makes the decisions folder a learning system rather than just a paper trail. Without it you accumulate decisions but never validate them, and you get to the end of the year unable to say which of your bets were right.

I now suggest people start a /decision workflow within the first week of adopting this structure. It's the single artifact that compounds the most.

Customer signals (with PII discipline)

Twindo runs a high-volume support channel that produces something like 500 signals a week. I tried to write a workflow that synthesized them into the context layer.

Two things I implemented immediately: First, raw support data contains customer names, emails, account IDs, and a lot of identifiable detail. Stuffing that into a context file accessible to every agent in the company is an obvious privacy disaster. Second, individual customer anecdotes are noise. The same customer complaining three times is one signal, not three.

What worked: an agent that reads the support channel, anonymizes everything, applies an aggregation threshold (3+ distinct customers before a pattern gets logged), and writes counts and patterns - never names. PII rules live in .claude/rules/context-usage.md and the agent runs a self-check before every write.

The result is a customer-signals file that is useful. It tells you which patterns are growing in volume, which are escalating in severity, which represent emerging use cases. And it never names a customer.

The scheduled refresh loop

The whole system would fall over if nobody refreshed it. Files become stale, contradictions creep in, and the intelligence layer drifts from reality. The exact failure mode I’m trying to prevent.

The fix is not "remind humans to update the docs." That has never worked at any company in history. The fix is scheduled tasks - small, focused agents that pull from the systems of record on a cadence and update one file each.

Update mechanism:

• Linear initiatives + cycles are updated in product/roadmap.md on a bi-weekly cadence

• CRM + finance are updated in commercial/revenue-plan.md on a weekly cadence

• Sales pipeline notes are updated in commercial/gtm-plan.md on a weekly cadence

• Support channel signals are updated in product/customer-signals.md on a weekly cadence

• So forth and so on…

Each refresh writes a one-line entry to meta/evolution-log.md describing what changed. Humans still own the narrative, agent-refreshes update facts, not the strategy.

The day I got these running on a schedule was the day the system started feeling alive instead of like another documentation burden.

The things that haven't worked yet

I want to be honest about the failures, because this is where the evolution of the system is going.

Finance is still mostly outside the layer. Things like real-time revenue performance, cash position, burn rate - these live in our finance system and in board materials, and I haven't found a clean way to surface a usefully-summarized version into the context layer without either oversharing (giving every agent access to specific numbers I'm not comfortable broadcasting) or undersharing (so high-level it's useless). Working on it.

Enabling non-technical teammates via GitHub. I alpha-tested this with a few non-technical teammates. Giving them write access to the repo was fine, but asking folks who don't live in git to adopt a git workflow is a non-starter. The point is, the adoption gap isn't about technical skill, it's about expecting people to use tools that don't fit their day-to-day. That's on me, not them. For a real cross-functional context layer, you eventually need a better surface than git push. (More on this below.)

Decision velocity > decision recording. Decisions get made faster than I record them. The /decision workflow helps, but it requires the discipline to use it in the moment. Building that habit is harder than building the workflow. Automating this is challenging to find the signal through the noise. Automation with human-in-the-loop quality control is ultimately the right pattern.

Cross-file consistency drifts. When I update revenue-plan.md to reflect a new pricing tier, I should also update identity.md, gtm-plan.md, and possibly positioning.md. The /health workflow logs these gaps, but it doesn't automatically fix them. I end up with brief inconsistency windows that I'd rather avoid. Again, agent orchestration to automate this is likely the path.

The "right tool" doesn't exist yet. I said this in the first essay and I'll say it again here: GitHub is a viable substrate for a first version, but it is not the right home for a real cross-functional company context layer. The Google Drive connector doesn’t seem to love markdown files. Someone will build the right thing, or several someones will. Until then, this is what works.

What it changed about how I work

I delegate strategic questions to agents and trust the answers. When someone asks me "what's our positioning vs. [competitor name]," I don't dig through Slack - I ask Claude, which reads competitive-landscape.md and positioning.md and answers similarly to how I would have. The trust is real because the source files are short, current, and unambiguous. Answers are grounded in Twindo facts, not generic AI output.

Status updates take about a third of the time they used to. Most of the time it takes me to produce updates was spent manually pulling from every system of record, then filtering and organizing the information into a logical narrative. Now the context is already there. Producing the update now is mostly fact-checking and telling the story; no longer data entry. It’s also slick that the context layer dials in the language our team is familiar with, rather than basic industry speak or hallucinations of what AI thinks we meant in Linear ticket.

Bonus: New employee onboarding. I created an onboarding guide for a new hire using the context layer. It got some things wrong, but it was because the source data was outdated; not that the system was faulty. I gave it clear directions: logical steps for learning the business, grounded in our own context layer. The AI took those and filled out an onboarding guide that actually made sense to a newcomer. Without it, I think they would have experienced the same information fatigue we all experience when we’re starting a new job.

The most surprising one is that none of this turned out to be especially time-consuming once the structure was in place. The maintenance load is real but bounded - maybe 30 minutes a week for me, plus the scheduled refreshes. That's a small price for a strategic operating system.

The open-source template

I swapped in a fictional B2B SaaS company called Northwind (a workflow-automation platform for revenue ops teams) so the example content is realistic, and put the whole thing on GitHub.

github.com/brianbouquet/context-layer-template

It includes:

• The full folder structure with every file populated as an example

• The CLAUDE.md entry-point pattern

• .claude/rules/ for context usage and PII protection

• .claude/commands/ for /decision, /health, and /context-refresh

• A decision template plus two worked example decisions (a pricing overhaul and a sequencing decision) that show the format

• Meta files (evolution log, gaps, health report) that demonstrate how the system audits itself

It's MIT-licensed. Fork it, strip the Northwind content, drop in yours. Or just read it as a reference for how the pieces fit together - sometimes that's enough.

The bigger point

I wrote the first essay because I believe that the "AI-native organization" thinking is missing a critical component. Org chart redesigns and small, flat companies are interesting but secondary. The actual constraint is whether the company has a shared, usable context layer that humans and agents can both operate against.

Building that layer is a real piece of work. It is not a single document, it is not a single workflow, it is not a single agent. It is the small, consistent practice of making context first-class - versioned, sourced, refreshed, owned.

The companies that figure this out in 2026 will run differently from the ones that don't. Annual planning will get sharper because the inputs are real. Quarterly planning will get faster because the context is already there. Real-time planning will become possible because the layer stays in sync with reality.

That is the practical promise of context engineering. The structure in this repo is one shape it can take. There will be others. The shape is less important than putting it to practice.

If you build something in this direction, I'd love to hear how you adapted it.