Skip to main content

​
Building a Strategy, from inside the coding tool

​
The old way to plan

In the old world, planning happens in a separate universe from implementation. Someone opens a Google Doc, writes a spec, shares it in Slack, people comment, it goes through a review cycle, and eventually an engineer reads a half-stale document and starts coding from an incomplete understanding of the intent. The plan and the code never live in the same context. In an AI-native team, this separation is the root cause of most failures. The agent that implements the work has never seen the conversation that shaped it. The decisions that constrain the implementation are buried in a document the agent can’t access. The codebase context that should inform the strategy is invisible to the person writing it.
Memex AI eliminates this gap. A strategy is built inside the development environment, through conversation, grounded in the actual codebase.

​
The round-trip

You’re in your coding tool (Claude Code, Cursor, whatever your team uses). You have an idea, a problem, a direction. You start talking:
“I want to add proactive role discovery, help me think through this.”
The agent calls create_strategy_draft() on the Memex AI MCP server. What follows isn’t document generation. It’s a collaborative design session where you and the agent build the strategy together, iteratively, with the codebase as shared context.

Problem framing

The agent asks you to articulate the problem. What’s broken? Who’s affected? What does success look like? As you talk, the agent reads relevant code to understand the current state of the system. It drafts the purpose statement. You read it back, right there in your terminal, and push back. “No, the problem isn’t X, it’s Y.” The agent updates. You go around again. The purpose sharpens with each pass.

Decision surfacing

As the conversation moves to approach, the agent starts recognising non-obvious design choices. “Should matching run server-side or client-side? There are trade-offs here.” It creates a draft decision with options and trade-offs. You might say “that’s not a decision, that’s obvious, go with server-side” and the agent resolves it immediately. Or you might say “add an option C, hybrid approach” and the decision stays open for further research.The decisions emerge from the conversation. They’re not invented in a vacuum or listed speculatively. They surface because the agent is reasoning about the strategy against the actual architecture.

Work item scoping

With the purpose clear and the initial decisions logged, the agent proposes work items. It reads the codebase to understand what exists, what needs changing, and what the dependency order should be. It drafts WI-1 through WI-N with goals, acceptance criteria, and dependencies, including dependencies on the unresolved decisions from the previous step.You review. “WI-3 is too big, split it.” “WI-5 depends on WI-2, not WI-1.” “Add a work item for the migration, you missed that.” The agent updates the draft in real time.

Blueprint linking

The agent identifies which existing blueprints are relevant to the work items and whether any new ones are needed. “WI-4 will touch the deployment pipeline, the deployment blueprint should be loaded when that work starts. There’s no matching-engine blueprint yet, we’ll need to create one after WI-1 is implemented.”

​
Reading it back

At any point, you say “let me see where we are” and the agent calls get_strategy_draft(). The server returns the current state (purpose, decisions, work items, linked blueprints) as formatted text, right in your terminal. You read it in context, in the same environment where you’ll implement it. No context switch. No browser tab. No separate app. 
$ memex get_strategy_draft S3

# S3: Proactive Role Discovery [DRAFT]

## Purpose
Address the horizontal skills mismatch: 34% of graduates work in
the wrong field. Build a system that helps candidates discover
non-obvious role matches based on transferable capabilities.

## Decisions (3 open, 2 resolved)
  D1  How many discovery occupations per candidate    [OPEN]
  D2  Auto-create catchments or require confirmation  [OPEN]
  D3  Profile completeness threshold                  [RESOLVED → extraction utility opines]
  D4  Location-aware matching                         [RESOLVED → yes, using TTWA data]
  D6  Server-side vs client-side matching             [OPEN]

## Work Items (5 scoped)
  WI-1  Discovery matching engine        [depends: strat-002 WI-7]
  WI-2  Profile schema redesign          [no dependencies]
  WI-3  Agent conversation flow          [depends: WI-2, D1, D6]
  WI-4  Discovery tools + integration    [depends: WI-1, WI-2, WI-3]
  WI-5  Outcome tracking                 [depends: WI-4]

## Linked Blueprints
  deployment    [existing, relevant to WI-4]
  testing       [existing, relevant to all WIs]
  matching      [to be created after WI-1]
You scan it, spot a gap, say “we need a decision about how to handle candidates with thin profiles”, the agent adds D7, links it as a blocker on WI-3, and the draft updates.

​
Publishing

When the strategy is solid (purpose is clear, key decisions are logged, work items are scoped with dependencies), you publish it:
“This looks good. Publish it.”
The agent calls publish_strategy("S3"). The draft becomes an active strategy. Decisions become blockable. Work items become claimable. The system starts tracking what’s ready and what’s blocked.
The agent that helped you write the strategy is the same agent (or at least, an agent with access to the same MCP server) that will pick up WI-1 and start implementing. It already understands the purpose, the constraints, and the decisions. There is no handoff. The spec was built together.

​
Why this matters

No context switch

The strategy is built where the code lives. The agent reads the codebase while helping you plan. You never leave your development environment.

No handoff

The agent that co-authored the strategy has full access to the same strategy when it implements. Decisions and constraints don’t get lost in translation.

Incremental, not waterfall

You don’t write a complete strategy document and hand it over. You build it through conversation. Problem first, then decisions, then work items. Each round refines the previous. You can publish with three work items and add more later.

Grounded in reality

Because the agent reads the codebase during planning, the strategy reflects what actually exists, not what someone remembered from last quarter. Work items reference real files and real dependencies, not abstract components.

Multiplayer

The draft lives on the Memex AI server, not in a local file. Another team member can open their own coding tool, connect to the same MCP server, read the draft, and contribute their own decisions or work items. Two people can shape a strategy concurrently from different environments.