The Labs Behind the Frontier: Anthropic, OpenAI, and Perplexity Are Not Interchangeable

TL;DR

In the last 30 days alone, three major frontier labs each shipped something that changes how production deployments work. Anthropic made enterprise-managed authorization generally available for MCP — per-agent tool allowlists, human approval gates, private-server sandboxes. OpenAI continued expanding its forward-deployed relationships, the operator model, and Codex. Perplexity launched Computer, deepened the Implementation Partners program, and is building toward a research/action hybrid unlike anything in the current model landscape.

A Forward Deployed Strategist who treats all three as 'the AI' will build the wrong system. Not a slow one. Not an expensive one. The wrong one — because the lab's theory of production is not a vendor preference. It is the architecture decision underneath everything else you build.

Why the lab matters, not just the model

The practitioner question is not 'which model is best?' — that answer changes weekly and is, in any case, a matter of benchmark selection. The question is: what is each lab's theory of how AI reaches production, and how does it shape what a Forward Deployed Strategist builds on top of it?

Three distinct theories have emerged. Anthropic's theory is governance-first: the model is powerful, but the operator layer — MCP permissions, managed authorization, human-in-the-loop gates — is where production deployments actually live. OpenAI's theory is full-stack ambition: from compute to model to product, OpenAI wants to be the production layer itself. Perplexity's theory is the research/action interface: real-time, web-grounded intelligence as a first-class citizen in the agent loop, layered into automated action.

Each theory produces a different tool surface. Each tool surface produces different architecture decisions. The practitioner who understands all three can route correctly. The one who doesn't defaults to the lab with the best marketing that week — and discovers the mismatch six weeks into a production build.

Anthropic: the governance lab

What Anthropic shipped that Forward Deployed Strategists actually build on: the Model Context Protocol (MCP), which turned from an open standard for tool integration into the de facto agent plumbing layer across the industry. And now, enterprise managed authorization, which went generally available on August 24.

Enterprise managed authorization means per-agent tool allowlists — an agent gets exactly the tools its operator approved, and no others. It means private MCP server sandboxes — client data stays inside the boundary the operator defined. It means mandatory human approval before irreversible actions — the governance gate is architectural, not policy. This is not a safety feature that gets bolted on after the build. It is the answer to the question every enterprise IT and security team asks before approving a new system: 'what exactly can this agent do, and who approved that?'

The FDS practitioner's relationship with Anthropic is specific: you are the operator. The brief, the journey map, the escalation gate — those are operator-level instructions in Claude's trust hierarchy. You write the permission boundary before the build, not after. Anthropic's tooling is designed for that workflow. The system prompt is where the operator sets what the agent may do unattended. The MCP allowlist is where the operator specifies which external systems it may reach. Enterprise managed authorization is where the operator enforces that boundary at runtime, not just at configuration time.

Why this matters disproportionately in regulated industries — pharma, financial services, manufacturing: Anthropic's governance tooling is the reason you can take an agent through a compliance review. You can point to the permission boundary. You can show the audit log. You can demonstrate the human approval gate before the irreversible action. That is not incidental. It is Anthropic's explicit theory of responsible production deployment, and it is why Enso Labs operates Claude as the governance layer in every production build we deliver.

OpenAI: the full-stack operator

OpenAI's theory of production is more direct — and more competitive. It wants to be the production layer itself. GPT-5, Codex, the operator model as a business model, ChatGPT Enterprise, Custom GPTs, and the recent expansion of its forward-deployed engineering relationships are all expressions of the same bet: that the distance between 'model provider' and 'production system' should shrink to zero.

For the FDS practitioner, this creates a specific dynamic. At large enterprise accounts, OpenAI often has its own forward-deployed team already in the room. They go wide — enterprise accounts, Codex, operator-level embedding across the org. You go deep: specific workflow, specific outcome, specific domain. The practitioner who understands both surfaces can arbitrage the gap. Use OpenAI's model power — the reasoning speed of GPT-5, the coding depth of Codex — while building the domain-specific layer OpenAI's FDE team doesn't have time to specialize in.

What makes that possible is the four harness inputs from Part 2. The brief, the journey map, the measurement plan, the segmentation — those are the domain specificity. That is what the OpenAI FDE doesn't write before the build. The practitioner who writes them first has a layer of value OpenAI cannot commoditize by shipping a better model.

The honest risk: OpenAI's full-stack ambition means they can become your client's default vendor for everything above the model. The FDS practitioner's moat is not the technology — it is the domain encoding and the four inputs that no model vendor writes before the build starts.

Perplexity: the research/action interface

Perplexity's theory is the most distinctive of the three, and the least well-understood by practitioners who have not built on it directly. The bet is not 'better search.' The bet is that most production agents are running blind — they have no reliable, real-time, grounded view of what is happening in the world right now. And that gap costs more than people realize, because the actions those agents take are based on the model's training-time knowledge, not on current reality.

What Perplexity has built — Perplexity Computer, the deep web integration, the grounded citation layer — is real-time intelligence as infrastructure. Not a search bar inside an agent. Not a RAG pipeline with a Perplexity API call. The research layer as a first-class agent component: grounded, cited, current, and structured into scored signals the agent can act on.

As a Perplexity Implementation Partner, Enso Labs deploys this layer as infrastructure in production systems. One deployment running now: a signal-monitoring engine that pulls from 200+ sources, scores them for domain relevance, and delivers structured intelligence briefings to domain experts — current as of this morning, grounded in cited sources, structured for action. That is Perplexity as infrastructure, not as a search engine.

The FDS practitioner's relationship with Perplexity: you are the deployment layer above the research layer. Where Anthropic gives you the governance plumbing and OpenAI gives you the reasoning engine, Perplexity gives you the intelligence feed. Your role is to specify what questions to ask of the world, at what cadence, and what to do with the answers. That is a strategy input, not an engineering problem — which is exactly where a Forward Deployed Strategist lives.

The multi-lab practitioner

The Forward Deployed Strategist who wins is not loyal to a single lab. Loyalty to a single lab is a vendor preference masquerading as an architecture decision. The practitioner who understands all three routes work correctly — and tells a client's CTO which governance layer to trust for a given deployment.

The routing logic is not complicated once you know each lab's theory: Anthropic for the governed production layer — the operator permissions, the MCP tooling, the enterprise managed auth that makes the system approvable. OpenAI for the reasoning and coding speed — GPT-5 for synthesis, Codex for build velocity in the components that don't require domain-specific governance. Perplexity for the intelligence feed — real-time, grounded, citable, structured for the domain expert who needs to act on it.

The four harness inputs — brief, journey map, measurement plan, segmentation — do not change by lab. What changes are the architecture decisions they drive: which tools the operator approves, which retrieval strategy the data warrants, which permission boundary the compliance team will sign off on. Those decisions are lab-specific. Making them correctly requires knowing each lab's theory of production, not just its benchmark score this week.

The forward deployment revolution is not 'which model wins.' It is the moment when practitioners understand the labs well enough to route work correctly — and to build systems that survive the first production review rather than collapsing into a proof of concept that never ships.

The Forward Deployed Strategist series: Part 1 — The Agency Lineage · Part 2 — The Agent Harness · Part 3 — The Labs (this piece) · Part 4 — The Practice (coming)

---

Enso Labs is an AI transformation and agentic systems studio. We are a Perplexity Implementation Partner and a Claude-native studio — we build and operate production AI systems for regulated industries, financial services, and commercial organizations. Get in touch →