The stack has settled. After two years of fragmentation—competing frameworks, overlapping tools, weekly "this changes everything" posts—three layers emerged. Most developers use one. Some use two. The real leverage is in how they compose.

Those layers: an AI-native IDE for reasoning, a capability protocol for discovery, and an execution platform for production work. Each does something the others can't. Each breaks without the others in ways that aren't obvious until you're debugging at 2 AM.

This post is the map. Where each layer starts, where it stops, and what happens when you wire them together.

Layer 1: The AI-Native Development Environment

Cursor, Claude Code, Warp, Windsurf—the specific tool matters less than the category. Some are graphical editors. Some are terminal-first. Claude Code runs entirely in your shell. Warp blends terminal and AI natively. The form factor varies, but the capability converges: an AI reasoning engine with access to your codebase, your conventions, and your intent.

Rules encode your conventions. Skills package portable knowledge. Agents bring specialized expertise. Commands trigger repeatable workflows. The naming differs across tools—Cursor has rules and skills, Claude Code uses CLAUDE.md, Warp has AI commands—but the pattern is the same: structured context that shapes agent behavior beyond raw prompts.

What this layer does well: code generation, refactoring, context-aware reasoning across files, pattern matching against your project's conventions. A well-configured environment feels like pair-programming with someone who's read every file in your repo and remembers all of it.

What it doesn't do: persist state across sessions, reach into external systems natively, manage production workflows, or enforce organizational compliance. Your development environment doesn't know what's running in prod. It can't query your HR system, check whether a workflow passed governance review, or maintain an audit trail.

The context window is both the superpower and the constraint. Feed it your entire project's conventions via well-structured rules and it performs. Starve it of context and it guesses—confidently, plausibly, incorrectly.

Key insight: The development environment is a reasoning engine bounded by what it can see. Expand that boundary and you get dramatically better results. But the boundary still exists, and pretending otherwise is how you end up with hallucinated API calls in production.

Layer 2: The Capability Protocol

MCP bridges the gap between IDE reasoning and the systems that matter.

Enterprise architects have been building abstraction layers between systems and consumers for decades. Most of those layers failed because they tried to be smart—parsing intent, auto-fixing errors, making decisions the consumer should make. MCP inverts this. The layer stays thin: it describes capabilities, validates inputs, enforces guardrails. The consumer brings the reasoning.

What that means in practice: instead of embedding stale documentation into your Cursor rules, you expose your system's capabilities as discoverable MCP tools. The AI assistant connects, queries what's available, reads the schemas, and decides how to use them. When the system changes, the capabilities update automatically. No prompt surgery required.

This matters more than it sounds. Static configuration drifts the moment you commit it. Dynamic discovery stays current. The difference between "it worked when I set it up" and "it works now" is the difference between a snapshot and a live feed.

Good MCP tool design follows the same principle as good API design: clear contracts, typed inputs, meaningful errors. The protocol doesn't need to be clever. It needs to be honest about what it offers and precise about what it expects.

Key insight: MCP turns documentation into runtime-discoverable capabilities. Not semantic search over docs—structured, typed, bounded interfaces that an AI can reason about in real time. It's the design pattern that makes the other two layers composable.

Layer 3: The Enterprise Execution Platform

The IDE reasons. The protocol connects. But neither one runs production workflows.

AI Employees—platform-managed agents with defined roles, permissions, and oversight—handle what the IDE and protocol can't. Workflow orchestration across multiple models. State that persists across conversations and sessions. Human-in-the-loop checkpoints at critical decision points. Audit trails that satisfy compliance teams. Routing logic that sends each task to the right model at the right cost.

This is where agents become workers. Not "AI assistants" that help you write code, but operational actors processing documents, extracting entities, routing support tickets, and managing their own governance. They have job descriptions, escalation paths, and performance metrics. They get reviewed and improved like any employee.

The IDE is where you think. The protocol is how you connect. The platform is where work gets done.

Key insight: The platform handles everything the IDE and protocol can't—state management, compliance enforcement, cost optimization, and scale. Trying to build this in your IDE is like trying to run a factory from a design studio.

How They Compose

The real power isn't in any single layer. It's in the flow between them.

flowchart LR
  D["**Developer**<br/>(Intent)"]:::primary
  C["**Agents**<br/>(reasoning + context)"]:::secondary
  M["**MCP**<br/>(discovery + semantics)"]:::accent
  P["**Platform**<br/>(execution + governance)"]:::highlight

  D <--> C <--> M <--> P

Here's a concrete example. Your task: "Update the onboarding workflow to extract compliance fields from uploaded documents."

Cursor handles the reasoning. It reads your project rules, understands you're working with an AI Employee platform, and identifies that this requires a workflow change—not a code change. It knows to use MCP to interact with the platform rather than generating API calls directly.

MCP handles the discovery. Cursor connects to the platform's MCP server, queries available tools, and finds the workflow management capabilities. It reads the schema, understands the required fields, and discovers the extraction action catalog—all at runtime. No hardcoded API calls. No stale documentation. The protocol bridges the gap between what the IDE knows and what the platform offers.

The platform handles the execution. The workflow update deploys through the platform's governance pipeline—validated, versioned, with human-in-the-loop approval if the compliance policy requires it. The extraction step runs in production with audit logging, model routing, and error handling that no IDE plugin could provide.

Each layer did exactly its job. No layer tried to do another's. That's the composition working.

Decision Framework

When you're deciding where something belongs, this table saves time:

Need Use Because
Code generation, refactoring Cursor rules + agents Reasoning stays local, low latency
External data in the IDE MCP server Dynamic discovery, always current
Production AI workflows AI Employee platform State + compliance + scale
Cross-system integration MCP + platform Protocol bridges, platform executes
Governance and compliance Platform guardrails Audit trails built in
Developer productivity Cursor skills Portable knowledge, shared across projects

The pattern: if it's about how to think, it belongs in the IDE. If it's about what exists, it belongs in the protocol. If it's about getting work done, it belongs in the platform.

Common Mistakes

These patterns keep showing up. Every one of them burns time.

Putting platform logic in Cursor rules. Rules are for conventions and guardrails—not for encoding workflow orchestration, routing logic, or compliance requirements. When you find yourself writing rules that describe how production workflows should behave, you've outgrown the IDE layer. Move that logic to the platform where it can be versioned, governed, and audited.

Hardcoding MCP data into static config. The entire point of MCP is that capabilities are discovered at runtime. The moment you copy an action catalog into a Cursor rule, you've created a maintenance burden that will drift from reality within weeks. Let the protocol stay dynamic. That's its job.

Skipping MCP and calling APIs directly from rules. You know the endpoint, you know the payload—so why add a layer? Because direct API calls in rules bypass discovery, validation, and governance. When the API changes, your rules silently break. MCP servers handle versioning, schema validation, and error semantics. The abstraction earns its keep.

Building production workflows in the IDE. Cursor is for development, not deployment. If you're chaining sub-agents to process documents, route tickets, or extract data in production, you're running a factory on a workbench. Production needs state management, monitoring, HITL checkpoints, and audit trails. Use the platform. That's what it's for.

Where This Is Heading

The three-layer model isn't the end state. It's the foundation.

As interfaces shift from human-mediated to machine-discoverable, the boundaries between these layers will get more interesting. The protocol layer will grow richer semantics. The platform layer will expose more capabilities directly to IDE agents. The IDE layer will get better at orchestrating across both.

But the principle holds: reasoning, discovery, and execution are different problems that need different solutions. Collapsing them into one layer is the mistake that created the fragmentation we just spent two years sorting out.

Start by getting the layers right. The composition follows.