mitm

Posted on Feb 23 • Edited on Feb 26

Your AI Coding Agent Has a Plan. You Just Can't See It.

#llm #ai #claude #mcp

I've been using Claude Code and Cursor daily for over a year now. They've genuinely changed how I build software. But there's a problem that's been eating at me for months, and once I articulate it, I think you'll realize you've felt it too.

AI coding agents don't let you see, interact with, or control their plan.

You type a prompt. The agent thinks for a moment. Then it starts writing code. Maybe it shows you a numbered list of steps in the terminal. Maybe it doesn't. Either way, that plan is a flat wall of text in a chat window that you have zero control over.

And that is the root cause of almost every frustrating AI coding experience you've had.

I built Overture to fix it. It's an open-source MCP server that intercepts the agent's plan and renders it as an interactive node graph in your browser, before a single line of code is written. This post is a deep dive into the problem, the solution, and why I think this changes how we work with AI agents.

The Problem Is Not That Agents Are Dumb. It's That Plans Are Invisible.

Let me be specific. When I say "the plan is broken," I don't mean agents make bad plans. Modern LLMs are surprisingly good at decomposing complex tasks into logical steps. The problem is how that plan is presented to you and what you can do with it.

Here's what happens today when you ask Claude Code to build a feature:

You type: "Add Stripe payment integration with webhook handling"
Claude Code thinks and maybe shows you a plan in the terminal: "Step 1: Install Stripe SDK. Step 2: Create checkout endpoint. Step 3: Set up webhooks. Step 4: Add error handling. Step 5: Write tests."
It starts coding.
You watch.
You wait.
It finishes, or it doesn't, and you inspect the damage.

That's it. That's the entire interaction model in 2026 for the most powerful coding tools ever built.

Now let me walk you through what's actually wrong with this, because it's not one problem, it's five.

Side by side comparison of Claude code terminal plan and Overture plan viewer

Problem 1: You Can't See Dependencies

A flat list implies that steps happen sequentially, one after another. But real projects aren't sequential. Step 3 might depend on Step 1 but not Step 2. Step 5 and Step 6 might be completely independent and could run in parallel. Step 4 might have two valid approaches, and the right choice depends on a decision the developer needs to make.

None of this is visible in a numbered list. You're looking at a linear representation of a non-linear process, and your brain has to reconstruct the actual dependency graph mentally. For a 5-step plan, that's manageable. For a 30-step feature build, it's impossible.

Problem 2: You Can't Monitor Individual Steps

When the agent starts executing, you get a stream of terminal output. Code being written, files being created, commands being run. It all blends together. If you want to know "did the database migration step succeed?" you have to scroll back through hundreds of lines of output and try to find where that step started and ended.

You can't click on "Database Migration" and see: green checkmark, completed in 45 seconds, created 3 files, here's the output. That level of granularity simply doesn't exist. You're stuck watching a firehose and hoping you catch the important bits.

Problem 3: You Can't Restructure the Plan

What if you look at the agent's plan and think "actually, I want to do the API endpoints before the database schema, because I want to validate the interface first"? In the current world, you type that feedback into the chat, the agent regenerates the plan (maybe), and you've lost 2 minutes to a back-and-forth that should have been a drag-and-drop.

What if you want to add a step the agent missed? Delete one you don't need? Split a large step into smaller ones? All of this requires conversational negotiation with the agent through text. You're describing structural changes in prose, which is inherently imprecise.

Problem 4: You Can't Scope Context to Steps

This is the one that made me start building Overture.

I was working on a project that involved Stripe integration. The agent needed my Stripe API key for one specific step. But when I provided it in the chat, it became part of the entire conversation context. Every subsequent step had access to it, and the agent occasionally referenced it in places it shouldn't have.

Same problem with files. If I attach a design mockup because Step 7 needs to match a specific UI, that mockup is now context for Steps 1 through 30. The agent might reference it when building the database schema, which is irrelevant and wastes tokens.

What I wanted was the ability to say: "This API key belongs to Step 12. This mockup belongs to Step 7. This architecture document belongs to Steps 3 through 5. Nothing else should see them."

That's not possible with a chat interface. Context is global or nothing.

Problem 5: You Can't Route Tools to Steps

This is the one that I think changes the game. Modern AI coding workflows increasingly rely on MCP servers. You might have a Figma MCP for design, a Supabase MCP for database, a Vercel MCP for deployment, a Slack MCP for communication.

But today, if you connect an MCP server to your agent, it's available for the entire session. The agent decides when to use it. You can't say "use the Figma MCP only during the UI component steps" or "use the Supabase MCP only during database steps." You certainly can't say "use the Slack MCP at Step 14 to message the backend team."

The agent has access to everything, all the time, and you have to trust that it uses the right tool at the right time.

What Overture Actually Is

Overture is an open-source MCP server. You install it with a single command, and it works with any MCP-compatible AI coding agent: Claude Code, Cursor, Cline, Codex, and anything else that comes next.

When you start a task, instead of the agent dumping a text plan into your terminal, Overture intercepts the planning phase and opens an interactive canvas in your browser. The agent's plan is rendered as a node graph, think FigJam or Miro, but purpose-built for AI coding workflows.

Each step is a node. Dependencies are edges. Branches are decision points. And every node is interactive.

Here's what you can do:

Click Into Any Node

Every node expands into a detail panel. The agent pre-populates it with a title, description, estimated complexity, expected output, and potential risks. But you can also attach your own context:

Files: Drag a config file, a design mockup, or a code snippet onto a node. That file becomes context for that step only.

Documents: Attach a PRD, API documentation, or a technical spec. Scoped to the steps that need it.

API keys and secrets: The agent can dynamically create typed input fields based on what a step requires. If Step 12 involves Stripe, the agent creates a "Stripe API Key" field with instructions on where to find it. You fill it in during planning, not mid-execution.

MCP servers: Assign a specific MCP server to a specific node. "Use Figma MCP for this step. Use Supabase MCP for that step."

Instructions: Write natural language rules scoped to individual steps. "Use Tailwind, not inline styles." "Follow the existing naming convention in /src/components."

Restructure the Plan Visually

Drag nodes to reorder them. Delete steps you don't need. Add new ones. Split a large node into multiple smaller nodes. Group related nodes into clusters. The agent's plan is a starting point, not a contract.

Choose Between Approaches at Branch Points

When a step can be accomplished multiple ways, Overture renders a decision diamond. The agent populates each branch with a fully detailed alternative.

For example, if the plan includes "Set up payment processing," you might see three branches: Stripe Checkout (fastest, least customizable), Stripe Elements (more control, more work), and LemonSqueezy (simpler API, handles tax automatically). Each branch shows estimated complexity, tradeoffs, and what the code would look like.

You pick one. Or, you can tell Overture to run all branches in parallel, the agent builds each approach separately, and you compare the actual output side-by-side before choosing a winner.

Monitor Execution in Real Time

Once you approve the plan, the canvas becomes a live dashboard. The current step pulses with a progress indicator. Completed nodes turn green, click one to see exactly what it produced: files created, code written, terminal output. Failed nodes turn red with error logs and options to retry, skip, or edit and retry.

You're not watching a terminal scroll anymore. You're watching a mission control screen where every step has its own status, its own output, and its own controls.

Real Use Cases That Made Me Build This

I want to share some specific scenarios where the flat-text plan model completely breaks down and Overture makes the difference between a smooth workflow and a frustrating one.

Use Case 1: Bob Needs to Notify the Backend Team

Bob is building a new ACH transaction module. The backend team needs to know the moment he starts working on it because they need to prepare the sandbox environment and update the API contracts.

Without Overture: Bob is deep in a Claude Code session. He remembers he needs to message the backend team. He has two options: break his flow, open Slack manually, type the message, then return to the terminal. Or install the Slack MCP, then interrupt the agent's execution to say "hey, message the backend team on Slack and tell them I'm starting the ACH module." Either way, his coding flow is broken. The context switch is real and costly.

With Overture: During the planning phase, Bob sees the first node is "Initialize ACH Transaction Module." He clicks on it, attaches the Slack MCP to that node, and adds an instruction: "Send a message to #backend-team: 'Starting ACH transaction module build. Please prepare sandbox env and update API contracts.'" That's it. When execution begins and that node runs, the agent sends the message automatically. Bob never leaves his flow. The notification is part of the plan, not an interruption to it.

Use Case 2: Sarah's Full-Stack Build With Multiple Data Sources

Sarah is building a dashboard that pulls data from three sources: a PostgreSQL database, a third-party REST API, and a Google Sheets document that the marketing team maintains. Each data source requires different credentials, different MCP servers, and different handling.

Without Overture: Sarah dumps all three sets of credentials into the chat context at the beginning. The agent has access to everything simultaneously. When it's building the Google Sheets integration, it also has the PostgreSQL connection string in context, wasting tokens and occasionally causing confusion where the agent tries to query the database when it should be reading the spreadsheet. Sarah has to babysit every step to make sure the right tool is being used.

With Overture: Sarah's plan graph shows three parallel branches: "PostgreSQL Integration," "REST API Integration," and "Google Sheets Integration." She clicks into each branch and attaches only what it needs. The PostgreSQL node gets the database URL and the Supabase MCP. The REST API node gets the API key and endpoint documentation. The Google Sheets node gets the sheet ID and the Google Sheets MCP. Each branch executes with only its own context. Clean, isolated, no cross-contamination.

Use Case 3: Marcus Has Two Valid Architecture Approaches

Marcus is building a real-time notification system. He's torn between using WebSockets (lower latency, more complex) and Server-Sent Events (simpler, but one-directional). He won't know which is right until he sees both implementations working.

Without Overture: Marcus has to pick one upfront, let the agent build it, test it, then if it's not right, tell the agent to scrap everything and try the other approach. That's potentially an hour wasted. Or he runs two separate sessions, manually managing both and trying to compare the output in his head.

With Overture: The plan graph shows a decision diamond at "Implement Real-Time Communication." Two branches extend from it: "WebSocket Approach" and "SSE Approach." Each branch has 4-5 implementation nodes. Marcus clicks "Run in Parallel." The agent builds both approaches simultaneously. When both are complete, Overture shows a side-by-side comparison view. Marcus inspects both implementations, tests both, and picks the one that fits. The losing branch is discarded cleanly.

Use Case 4: Priya Needs a Step the Agent Missed

Priya asks the agent to build an authentication system. The plan includes: set up user model, create login endpoint, create registration endpoint, add JWT token generation, protect routes with middleware. It's a good plan. But Priya knows from experience that her company requires all auth systems to include rate limiting on login attempts and audit logging for compliance.

Without Overture: Priya types "also add rate limiting and audit logging" into the chat. The agent says "sure" and regenerates the plan. But now the rate limiting is shoved in at the end instead of being integrated at the login endpoint level. She corrects it again. Another round trip. Another regenerated plan. Five minutes gone.

With Overture: Priya sees the plan graph. She right-clicks between "Create Login Endpoint" and "Add JWT Token Generation" and inserts a new node: "Add Rate Limiting to Login." She drags it to connect the right dependencies. She adds another node: "Implement Audit Logging" and connects it as a dependency to both the login and registration nodes. She's restructured the plan in 20 seconds, visually, with no ambiguity.

Use Case 5: The Startup CTO Reviewing an Intern's AI-Generated Plan

David is a startup CTO. His intern, Jake, is using Cursor to build a new feature. David wants to review the plan before Jake lets the agent execute. But Jake's plan lives in his terminal, in his Cursor chat window, on his laptop, and there's no way to share it or get approval before execution.

With Overture: Jake's plan renders in the browser. He sends David the localhost URL (or a shareable link in the future). David opens it, sees the full graph, clicks into nodes that concern him, leaves comments: "This node should use the existing auth middleware, don't create a new one." Jake sees the comments, adjusts the plan, and gets the thumbs up. Then he executes. No code is written until the CTO approves the architecture.

How It Works Under the Hood

Overture is an MCP server written in TypeScript. When you install it and connect it to your agent, it provides tools that the agent calls during the planning phase.

Instead of generating a flat text plan, the agent generates a structured plan in XML format. Each step is a <node> element with attributes for title, description, complexity, and expected output. Dependencies are <edge> elements connecting nodes. Decision points are <branch> elements. Dynamic input fields are <field> elements nested within the node that needs them.

<plan>
  <node id="1" title="Initialize Project" complexity="low">
    <description>Set up Next.js project with TypeScript</description>
    <output>Initialized project directory with package.json</output>
  </node>
  <node id="2" title="Stripe Integration" complexity="medium">
    <description>Set up Stripe checkout flow</description>
    <field type="secret" name="stripe_api_key" label="Stripe API Key">
      <instructions>Find this in your Stripe Dashboard under Developers → API Keys</instructions>
    </field>
  </node>
  <edge from="1" to="2" />
</plan>

Overture parses this XML and renders it as the interactive graph in your browser. The communication between the MCP server and the browser UI happens over WebSocket, which is also what enables real-time execution tracking.

The beauty of this being an MCP server is that it's agent-agnostic. Any agent that supports MCP can generate Overture-compatible plans. The agent doesn't need to know anything about graphs or visualization, it just needs to output structured XML instead of flat text.

The Product Roadmap: Where This Is Going

Overture today is the foundation. Here's what's coming:

Now (v1)

Interactive plan canvas with node graph rendering
Node detail panels with context attachment
MCP server assignment per node
Real-time execution tracking
Branch selection at decision points
Support for Claude Code, Cursor, Cline, Codex

Next (v2)

Parallel branch execution with side-by-side comparison
Dynamic agent-generated input fields (API keys, config values)
Plan templates: save and reuse approved plans for common tasks
Export plans as Markdown, JSON, or images

Later (v3)

Multiplayer collaboration: multiple people viewing and editing the same plan
Comment and approval workflows: tech lead signs off before execution
Plan analytics: track which plans succeed, which steps commonly fail, how long things take
Community template library: share plan templates publicly
Checkpoint rollback: if Step 15 fails, roll back to the state after Step 14

Vision

The long-term vision is that Overture becomes the standard interface between humans and AI coding agents. Not a replacement for the terminal or the chat window, but a layer on top that gives you visibility, control, and collaboration. Every AI coding session should start with a visual plan that you can see, interact with, and approve.

Technical Details for Contributors

Overture is fully open source and we need help. Here are the areas where contributions would have the biggest impact:

Graph Rendering & Layout: We're using a combination of automatic layout algorithms and manual positioning. If you have experience with Dagre, ELK, or custom force-directed layouts, we'd love your input on making large graphs (50+ nodes) readable and navigable.

Agent Prompt Engineering: The hardest unsolved problem is getting agents to consistently generate well-structured XML plans. Different agents have different tendencies. Claude Code is great at detailed decomposition. Cursor sometimes collapses steps. We need robust system prompts and fallback parsers for each agent.

UI/UX Polish: We want Overture to look stunning. Think Linear meets FigJam. Dark-first, smooth animations, responsive interactions. If you're a frontend engineer who cares about design, this is a greenfield opportunity.

MCP Server Integration: Building the tooling that lets users attach and configure MCP servers to individual nodes. This involves MCP protocol handling, server lifecycle management, and automatic installation of missing servers.

Testing & Reliability: Execution tracking needs to be rock solid. The agent tells Overture which node it's working on, and Overture needs to correctly reflect that state, handle failures gracefully, and never lose data.

Tech Stack

MCP Server: TypeScript (Node.js)
Frontend: React + TypeScript
Graph Rendering: ReactFlow (evaluating alternatives for performance at scale)
Styling: Tailwind CSS + Framer Motion
State Management: Zustand
Communication: WebSocket
Local Storage: SQLite via better-sqlite3

Install it and try it

npm i overture-mcp

That's it. Everything runs locally. No cloud, no account, no data leaving your machine.

The repo is here: [https://github.com/SixHq/Overture.git]

Star it if you want to follow the progress. Open an issue if something breaks. Submit a PR if you want to help build the future of human-agent collaboration.

Final Thought

We're in this strange moment where AI coding agents are extraordinarily capable but the interface between the human and the agent is still a text box. We can generate entire applications from a prompt, but we can't see the plan, can't shape it, can't monitor it, and can't learn from it.

Overture is my attempt to fix that. Not by making agents smarter, but by making their thinking visible.

If you've ever watched an agent go sideways and thought "I wish I could have caught that before it started coding," this is for you.

Overture is open source and MIT licensed. Built by a developer who was tired of watching agents code blind. Contributions, feedback, and stars are all welcome.

#opensource #ai #webdev #productivity #mcp #vibecoding`