The Code That Ships. The Models That Run It. What Forward Deployment Actually Looks Like Inside Motion, Anthropic, OpenAI, and Perplexity.

There is a version of forward deployment that lives in slide decks. It has architecture diagrams, arrows between boxes labeled "LLM" and "database," and a section called "future state." It gets approved in steering committees. It almost never ships.

Then there is the version that runs in production. That version has a `.env` file, a context window budget, an eval suite somebody wrote at 11pm, and a Slack channel where an engineer just posted "model started hallucinating on edge case 14 — rolling back." These are not the same thing. The Forward Deployed Strategist has to live in the second version, or they are useless.

This piece is about the second version. Four companies. Four deployment patterns. The models, the code architecture, the engineering choices that separate a demo from a production system — and what the strategist needs to understand at each layer.

Motion: the startup pattern — iterate or die

Motion is an AI-native scheduling and productivity tool that uses Claude as its core reasoning engine. At the startup scale, forward deployment is not about governance or managed authorization. It is about iteration velocity. Motion's engineering pattern is representative of the leading AI-native startups: the model is the product, context management is the hardest engineering problem, and evals are how you find out you broke something before your users do.

The core technical challenge Motion solves is what every AI-native startup faces: the model knows nothing about the user's specific context — their calendar, their task priority logic, their personal constraints — so the deployment code has to handle all the retrieval, ranking, and injection into the context window before a single token is generated. The engineering pattern looks like this: `user_context = retrieve_and_rank(tasks, calendar, preferences)` → `prompt = build_prompt(system, user_context, request)` → `response = claude.messages.create(model, prompt, tools)` → `action = parse_and_validate(response)`. That four-step loop is the heartbeat of every AI-native startup deployment. The strategist's job is to define what goes into `user_context` and what the `action` should do in the real world.

What Motion gets right that most startups miss: they treat evals as a first-class engineering artifact, not an afterthought. Every time the model's behavior changes in a meaningful way — a new prompt version, a new context injection, a new tool — there is an eval suite that runs against 200 real user scenarios. The eval output is not "it passed" or "it failed." It is a delta: "behavior changed on 14 of 200 cases, here is the breakdown." The strategist reads that delta and decides whether the change ships.

Perplexity: the research-to-action pattern

Perplexity's deployment architecture is different from every other frontier model company in one critical way: the model's outputs are grounded in real-time web retrieval before they are shown to the user. This is not RAG in the traditional sense — it is not retrieval from a static knowledge base. It is live search synthesis at query time. The engineering implication is significant: every response is a pipeline, not a single model call.

The Perplexity deployment pattern that the Implementation Partners program enables is this: take a business workflow that currently requires a human to research, synthesize, and act — then replace the research and synthesis layer with Perplexity's grounded intelligence API, and wire the output to an action layer (a form submission, a CRM update, a draft document, a notification). The code surface the forward-deployed team owns is the action layer and the workflow orchestration. The grounding is Perplexity's. This is why the Implementation Partners program matters: it is not a reseller arrangement. It is a deployment architecture where the partner owns the last mile.

The Computer use product changes this further. Perplexity Computer extends the research-to-action pattern to the full desktop — the model can navigate, read, and interact with any application the user can see. For the Forward Deployed Strategist, this means the "action layer" is now the entire operating system. The engineering pattern becomes: `query = structure_task(user_intent)` → `result = perplexity.research(query)` → `computer.execute(result, target_application)`. The strategist's job is to define the task structure and the target application mapping. The model handles the rest.

OpenAI: the full-stack operator pattern

OpenAI's deployment architecture is best understood through the products that sit on top of it: Cursor, GitHub Copilot, and the GPT-4o integrations that power dozens of enterprise workflows. The pattern is a full-stack operator model — OpenAI provides the model, the fine-tuning infrastructure, the function calling interface, and increasingly the distribution. The forward-deployed team's job is to define the tools the model can call, the schema for those tools, and the business logic that runs when the model calls them.

The technical core of OpenAI's deployment pattern is function calling. A tool definition looks like this: `{"name": "update_crm_record", "description": "Updates a customer record with the provided fields", "parameters": {"type": "object", "properties": {"customer_id": {"type": "string"}, "fields": {"type": "object"}}}}`. The model reads that schema, decides when to call it, and fills in the parameters. The forward-deployed team writes the schema and the function that handles the call. The strategist's job is to define which tools exist, what they do, and what the model is and is not allowed to trigger autonomously. That is a business decision, not an engineering decision. It belongs to the strategist.

OpenAI's Codex product adds a code execution layer. The model does not just call predefined functions — it can write and run arbitrary code in a sandboxed environment. This changes the deployment pattern significantly: instead of pre-defining every tool the model might need, the team defines the sandbox (what packages are available, what APIs can be called, what files can be read) and lets the model write its own tools at runtime. For startups, this is enormously powerful. For regulated enterprises, it requires a governance framework the strategist has to design before the first line of code runs.

Anthropic: the governance-first pattern

Anthropic's deployment architecture is built around a concept the other frontier labs have not fully systematized: the operator layer. In Anthropic's model, there are three principals — Anthropic (sets the absolute limits via training), the operator (the company deploying Claude, sets system prompt and tool access), and the user (the end person interacting with the deployment). The code that runs between these layers is not just prompt engineering. It is access control.

The Model Context Protocol (MCP) is Anthropic's open standard for wiring tools to models. An MCP server exposes capabilities — a database query, a file read, a calendar update — and the model calls them through a standardized interface. The engineering pattern is: define MCP servers for each capability your system needs → configure the operator system prompt to give the model context and constraints → wire in Enterprise Managed Authorization so that certain tool calls require user approval or are blocked for non-authorized users entirely. The strategist's job is to design the permission model: what can the model do on its own, what requires a human in the loop, and what is never allowed regardless of context.

The Enterprise Managed Authorization layer is where Anthropic's governance-first architecture diverges most sharply from the other frontier labs. It is not enough to tell the model "don't do X." The authorization layer enforces it at the infrastructure level — if the operator has not granted a permission, the tool call fails, full stop. For regulated industries — financial services, healthcare, pharma, legal — this is not a nice-to-have. It is the difference between a system that can be deployed and one that cannot.

The pattern underneath the pattern

The pattern that runs across all four companies is the same at its core: a model, a set of tools, a context window, and a loop. What differs is who controls the tool definitions, how strictly the authorization is enforced, and what the strategist's role is in each layer. At Motion, the strategist defines the context injection logic. At Perplexity, the strategist designs the action layer and the workflow orchestration. At OpenAI, the strategist writes the tool schemas and the permission model. At Anthropic, the strategist designs the operator configuration and the authorization architecture. The code changes by company. The judgment does not. That is the work.

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

---

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 →