Orchestration Is All You Need: The Claude Code Leak Confirms It

What the Claude Code leak tells us about the future of AI business infrastructure

Note: While writing this article, Claude Code's entire source code was leaked via a source map file in their npm registry. I had to add an entirely new section because what was found in the codebase directly confirms the thesis laid out here. Sometimes the proof shows up while you are still writing the argument.

Right now, there is a war being waged between Anthropic and OpenAI to become the de facto orchestrator. On February 15, 2026, Sam Altman announced on X that Peter Steinberger, the creator of OpenClaw, was joining OpenAI to "drive the next generation of personal agents." OpenAI did not acquire a product with paying customers. They acquired proven workflow infrastructure with community adoption and a clear strategic thesis: the value of AI agents lies in cross-platform orchestration, not in single-application features. A month earlier, Anthropic had released Claude Cowork. The signal from both sides is unmistakable. This is a race for the orchestration layer.

This starts with small businesses, as they are the ones who can adapt and build a centralized orchestration hub. Think of it as a command center for all of your business operations. Every contact, every Telegram message, every email, every call transcript piped into a single ecosystem that the orchestrator can reason across. The industry is moving away from dashboards and towards API-first infrastructure where agents pull data on demand. The format will likely be something like Claude Cowork, Claude Code, or Codex/ OpenClaw. There are a few different entry points where people can participate and subscribe to an orchestration framework.

The strategic question is not which orchestrator to pick, because the best orchestrator can change. The place where value accrues is not the compute and not the models, since those could get commoditized. The frontier models keep getting better, but the marginal gap between the best model and the open source version keeps shrinking. There will come a point where the free version running on your laptop gets the job done. The defensible layer is your structured data and MCP pipelines, and building on open standards, while staying flexible across whichever frontier model wins becomes key. Teams that lock in data infrastructure now can adopt any orchestrator without starting over.

For businesses, the framework that I see as most fit, while still allowing innovation to progress, is setting up everything as MCP (Model Context Protocol) context connectors. Whether it is the CRM, the pipeline management services, or a system to format messages and calls, everything needs to ingest into this orchestration system.

Once all inputs are flowing into this orchestration system, the key element becomes structured data. Without canonical people, companies, deal stages, or product development status, the LLM burns tokens trying to piece together structure on its own, and the results suffer. Hook up a raw Twitter feed to an agent and you are just going to burn credits. The whole game is turning everything into structured data that can be reasoned about. Filter down the noise, classify by entity, and structure it so the agent can do smart retrieval instead of brute force context assembly. Simply put, if the data isn’t structured and clean, then the agent spins its wheels on piecing it together or worse conflating context, people, priorities etc.

How do you prepare for Enterprise AI without an AI plan?

Structure your data so agents can reason on top of it. Obsidian is a clean example: its vault structure makes every note agent-readable by default. CRM tools like Attio and project management tools like Linear already have MCPs with full tool-calling capabilities. The infrastructure exists. The question is whether your data inside these tools is canonical, consistent, and connected.

Beyond the standard connectors, the game becomes building specialized ontologies that suit your particular business. These ontologies are how agents reason across highly dense information very quickly and cheaply, usually in the form of some type of graph.

Custom Connectors: Custom MCPs

The key innovation here is that you can deploy your own custom data connectors. For instance, I have a data connector that represents my thesis on where I think the space is going. My custom connector is deployed and connected to Claude with authentication, so I have access into my own custom mental model graph I can update via prompt which connects to my orchestrator.

MCP Second Brain

The reason for a graph is that I can express my thesis about where the landscape is heading and have Claude update the graph based on that thesis, while also building out the schema in real time. I can do two things simultaneously. I can express my belief, with a graph being the best structure for me to express that, while also building out and adjusting the schema with full read and write access from Claude.

Previously, I would do something like this from Claude Code as a static process, then build a repository to define the schema. Using this method instead, I get real-time updates. I have particularly noticed that the reasoning within the Claude chat application is better than the reasoning on Claude Code. These things change, but I have found that all these MCP connectors can not only connect to Claude Code, but also to the chat application. This gives me flexibility across both interfaces.

The Small Business Advantage

What is particularly interesting is that enterprise adoption is basically giving people a frontend chat box on a couple of business items. The percentage of context that lives outside of those business connectors, however, is massive. For a small business, the founder alone has enough context about the business to create up to 80% of the context about the customers, the business, and the protocol for the agent to reason across.

This is the Jarvis moment.

At that point, you can set up cron jobs asking your business questions. Anthropic has already made this concrete. On February 25, 2026, @claudeai announced on X: "New in Cowork: scheduled tasks. Claude can now complete recurring tasks at specific times automatically." This came alongside 13 new enterprise plugins including Google Workspace, Apollo, Clay, and Outreach, announced at their "Briefing: Enterprise Agents" event. You describe a task once, pick a cadence, daily, weekly, hourly, or on demand, and Cowork runs it automatically. Each scheduled task spins up its own session with access to every tool, plugin, and MCP server you have connected. This is the beginning of their orchestration stack. You can now have Claude check your email every morning, pull metrics from a dashboard, compile weekly reports, or run a competitive research sweep on a recurring basis. The /schedule command inside any Cowork task is all it takes.

It then becomes your business telling you what to do, what it needs, and what human input is required to become a more successful business. You, as the founder, engineer, or developer, need to write and steer the system to reach those goals.

Teams should focus and deploy heavy resources into orchestration frameworks and how they are going to build orchestration across the business. Nothing actually needs to be automated, the core breakthrough is reasoning across every corner of the business with the entire context. That is the role of a founder, if you can have an agent reason across the context of the business, then you can increase throughput, understand nuances that might not have been useful to spend time on, and stay on top of executive debt where you literally do not have the capacity to reason across all of the edge cases in strategy, product development, or marketing.

This is not just accessible to founders, but anyone with meaningful access to context around company operations.

Executive Debt

Every founder carries executive debt, which is the accumulation of every edge case you know exists but have not had time to reason through. Every strategic question you have been deferring, every product decision you have been making on instinct because you cannot afford the time to think it through properly, every marketing angle you know you should explore but keep pushing to next week. Many times, these things don't even have a clean place to store, and executive debt compounds. The longer you defer reasoning about a problem, the more downstream decisions get made on top of incomplete thinking. You end up building on assumptions you never had time to validate.

This is different from technical debt, which is about code quality. Executive debt is about the quality of your thinking across the business. A founder with high executive debt knows the problems exist, can feel them in the business, but cannot allocate the mental bandwidth to define them clearly enough to prescribe solutions. The business moves forward anyway, and each deferred decision narrows the path.

Full orchestration across the business is how you pay down executive debt.

I use the term executive debt consciously. Cognitive debt already has a meaning in the research literature. A 2025 MIT Media Lab study found that repeated reliance on LLMs like ChatGPT weakens neural connectivity, reduces memory retention, and erodes critical thinking over time. That is cognitive debt: the cost of outsourcing your reasoning to AI. Executive debt is the opposite problem, it is the cost of not having enough reasoning capacity to cover your business in the first place. When an agent can reason across the CRM, the product tickets, the emails, the calls, and the structured ontologies simultaneously, it can surface the patterns you do not have time to find. It can define the problems you know exist but cannot articulate. The immediate solution is not for the agent to solve them for you, but gives you the clarity to solve them yourself, or to hire the right person to solve them, because now the problem is defined for a solution.

The Stack: A Working Example

What this looks like in practice is the orchestrator sits in the middle while everything else is a spoke connected via MCP, feeding context into the system. The CRM layer is where every contact, company, deal stage, and relationship lives as structured, canonical data. An MCP with full tool-calling capabilities lets the orchestrator read and write across the entire sales pipeline, marketing plan, or product development.

The product ticketing layer is something like linear. Every task, sprint, and status update feeds into the orchestrator through Linear's MCP. The agent can reason about what is being built, what is blocked, and what is shipping this week. The communication layers are email and call notes or slack messages for context. These are the raw signal inputs, conversations, follow-ups, introductions, and meeting transcripts all pipe into the system as structured data.

Underneath all of this sits the structured data layer, which is where canonical people, companies, deal stages, and product statuses are resolved and stored. The ontologies live here too, whether that is a custom graph expressing a market thesis or a knowledge base in Notion tracking goals and strategy. The key insight is that none of these tools are new, and every business already uses some combination of CRM, ticketing, email, and messaging. The difference is connecting them to a single orchestrator through existing or custom piping so that an agent can reason across all of them at once, instead of each tool being a silo that only a human can cross-reference.

The most important architectural concept in this framework is the feedback loop. Outputs from the orchestrator flow back into the context layer as new inputs. A drafted message becomes a sent message, which becomes a thread, which becomes context for the next decision. A deal that moves stages in the CRM updates the pipeline data that the agent reasons over tomorrow. Actions become context. The system compounds on itself, and every cycle makes the orchestrator smarter about your business because it is reasoning on top of its own previous outputs alongside everything else, creating a flywheel.

The takeaway for teams is to be heavily focused right now on structuring their internal data to be agent-readable and connecting it in some way, including via MCP. That means canonical records in the CRM, structured tickets in the project management tool, searchable call transcripts, and organized knowledge bases. Teams that treat this as a priority will be ready when the orchestrators reach full capability. Teams that do not will spend months retrofitting their data while competitors are already running autonomous operations from a cell phone.

While Writing This, the Thesis is Further Validated

While writing this paper, Chaofan Shou (@fried_rice on X) discovered that Anthropic's entire Claude Code source code had been leaked via a source map file left in their npm registry. Over 512,000 lines of TypeScript, feature flags, internal roadmaps, and unreleased capabilities became public. What was inside the codebase confirmed everything above.

The most referenced feature flag is called KAIROS, appearing 154 times. Based on the code, this is an autonomous daemon mode that turns Claude Code into an always-on agent. It includes background sessions, something called "dream" memory consolidation that runs nightly, GitHub webhook subscriptions, push notifications, and channel-based communication. KAIROS maintains append-only daily log files, writing observations, decisions, and actions throughout the day. It does not wait for you to type. It watches, logs, and proactively acts on things it notices.

There is also PROACTIVE mode with 37 references, which lets Claude work independently between user messages. The system sends "tick" prompts to keep the agent alive, and Claude decides what to do on each wake-up. The prompt literally instructs the model to "look for useful work" and "act on your best judgment rather than asking for confirmation." This is the scheduled tasks concept taken to its logical conclusion.

COORDINATOR_MODE with 32 references transforms Claude into an orchestrator that spawns and manages parallel worker agents. The coordinator handles research, implementation, and verification by delegating to specialized workers. The system prompt includes detailed instructions on how to write prompts for workers, when to continue versus spawn fresh agents, and how to handle worker failures.

There is also ULTRAPLAN, a mode where Claude Code offloads complex planning to a remote cloud session running Opus 4.6, gives it up to 30 minutes to think, and lets you approve the result from your browser before teleporting it back to your local terminal.

All of it is production code behind feature flags, gated and waiting to ship. Everything I describe in this paper about structured data, MCP connectors, ontologies, and scheduled tasks is the infrastructure that these systems will consume. The teams and founders who have this infrastructure in place when KAIROS, COORDINATOR_MODE, and PROACTIVE go live will have an enormous advantage over those who do not.

Defining the Problem

For most teams tackling this problem the question is "how do I get a jarvis to answer all my questions and socratically prompt me into decisions". This is indeed possible but without the breadth company context the agent is biased in the end reasoning, and to achieve this requires the full orchestration of the business functions.

The starting point is how do we feed our own structured data our orchestration stack.

With agent context and full orchestration across the breadth of the business, teams can spend less time managing context for decisions and more time deploying the solutions. The goal is to augment each human in a way that they can increase their throughput in a meaningful fashion. If you can double your capacity even without full blown automation, what is the value of that?

Build on MCP, structure your data while the orchestrators evolve. Your connectivity is what makes you defensible.