How DeployCos Work: The Forward Deployed AI Playbook

AI deployment companies (DeployCos) follow a recognizably similar delivery model regardless of who backs them. Forward deployed engineers embed with a customer, pick a small number of high-value workflows whose outputs can be checked, wire a model into the customer's data and systems through an "agent harness," build evaluations, iterate until a quality bar is met, deploy, and keep improving the system in production ¹. This page describes that playbook step by step, using the public descriptions published by the OpenAI Deployment Company, Ode with Anthropic, AWS and independent practitioners.

For the definition of the category see What Is a DeployCo?. For the people who do this work see Forward Deployed Engineers.

The four-step model

1. Enterprise workflow discovery

   Identify expensive, repetitive, bounded processes whose outputs can be verified.

   Typical artifacts: Diagnostic report, ranked list of candidate workflows, baseline metrics.

2. Embedded AI engineering

   Integrate models, data, APIs, tools and agents inside the customer's environment.

   Typical artifacts: Agent harness, integrations, prompts and tool definitions, test data.

3. Production validation

   Establish evals, security review, human approval gates and reliability targets.

   Typical artifacts: Eval suite, red-team findings, approval policy, SLOs.

4. Operational deployment

   Monitor, optimize and iterate on the live workflow.

   Typical artifacts: Dashboards, drift alerts, retraining or re-prompting cadence, ROI report.

Outcome: a measured business result. Deployment is the beginning of the engagement, not the end of it. Source for the structure: synthesized from ¹²³.

Step 1: Workflow discovery and the diagnostic

OpenAI describes its Deployment Company engagements as starting with a diagnostic, after which the team "focuses on a small number of priority workflows" ². AWS frames the same idea as its "AI 45" method: roughly 45 minutes to an idea, 45 hours to a prototype and 45 days per customer engagement, with timing varying by use case ³. Independent practitioners recommend that the diagnostic be paid, scoped in writing and short (two to four weeks is a common range) ⁴.

The selection criteria that recur across these descriptions:

• The workflow is expensive or high-volume enough that automation moves a number the CFO tracks.
• The task is bounded: inputs and outputs are well defined, and a human can check the output.
• The data and systems are reachable: the engineers can get credentials, APIs or exports in weeks, not quarters.
• There is an owner on the customer side who can approve process changes.

Step 2: Embedded engineering and the agent harness

An agent harness is the software that sits around the model: retrieval over the customer's documents, tool definitions that let the model query or update systems of record, orchestration logic, memory, guardrails and logging ¹. The model is a component; the harness is the product. This is why DeployCos describe themselves as engineering firms rather than consultancies - the deliverable is code running in the customer's environment.

Ode's CTO Eddie Siegel summarized the ratio of effort in July 2026: "I think model selection matters, but it's not where the majority of calories are spent," comparing model choice to choosing a programming language ⁵. Public descriptions of the tooling used by deployment teams include orchestration frameworks (LangChain, Pydantic AI), evaluation platforms (Braintrust, Weave), vector retrieval (Pinecone) and conventional application infrastructure such as FastAPI and AWS ECS ⁶.

Step 3: Production validation - evals, security and approval gates

Three controls distinguish a production deployment from a demo:

1. Evaluations (evals). A test set of real inputs with expected outputs, scored automatically or by domain experts, run before every change. Teams iterate on prompts, retrieval and tools until the eval score clears a bar agreed with the customer ¹.
2. Security and data review. Where the data lives, which systems the agent can write to, how credentials are scoped and what is logged.
3. Human-in-the-loop approval gates. Consequential actions (payments, customer communications, record changes) require a person's approval until the agent has earned autonomy within limits the customer sets. This pattern is described by lab-backed and independent firms alike ⁷.

Healthcare examples make the stakes concrete: Ode's August 2026 partnership with PointClickCare describes building AI systems inside the platform's existing architecture with a "clinician-in-the-loop" approach ⁸.

Step 4: Operational deployment and the learning loop

After go-live, the DeployCo monitors accuracy, latency, cost per task and exception rates, and feeds failures back into the eval set and the harness. Jaipuria calls this the "learning loop," the mechanism by which an agent improves in production rather than degrading as the business changes around it ¹. AWS says its engagements are designed to end with an exit strategy so the customer can run the system, while engineers may stay for additional use cases ³.

A worked example: income verification

Consider a lender that wants to automate income verification.

• Discovery: the lender processes tens of thousands of applications a month; each verification requires an analyst to read pay stubs, bank statements and tax forms. Outputs are checkable against the final underwriting decision.
• Engineering: the DeployCo integrates the lender's document intake, a financial data provider and the loan origination system; builds extraction and classification agents; and writes tool calls that post results back to the origination system.
• Validation: an eval set of a few thousand historical applications with known outcomes; a rule that any case below a confidence threshold, or any case over a dollar limit, routes to a human; an audit log of every extraction.
• Operation: dashboards track straight-through rate, override rate and cost per file; new document formats that fail are added to the eval set weekly.

The lender did not buy a model. It bought a working verification workflow with a measured straight-through rate. That is the difference between an API subscription and a DeployCo engagement.

How the big players describe their own process

What the playbook does not solve

• Organizational alignment. Access to systems, process redesign and buy-in across teams are not engineering problems. Jaipuria lists culture and organization alignment as the second reason DeployCos exist ¹; see Why DeployCos Exist.
• Model choice is not neutral. A lab-backed DeployCo builds on its parent's models. Whether that is a feature or a lock-in risk is debated in Risks and Debates.
• Ownership at exit. Who owns the harness, the eval set and any fine-tuned weights when the engagement ends should be settled up front; see Evaluating a DeployCo.

Frequently asked questions

References

1. Tanay Jaipuria, "The Rise of DeployCos," 10-13-2026. tanayj.com
2. OpenAI, "OpenAI launches the OpenAI Deployment Company to help businesses build around intelligence," 05-11-2026. openai.com
3. Constellation Research, "AWS launches forward deployed engineering unit with $1 billion investment," 06-30-2026. constellationr.com
4. QuantSpark, "Choosing a forward-deployed AI partner" (vendor publication). quantspark.ai
5. TechCrunch via The Next Web, "Anthropic and Blackstone bet the next fortune in AI is implementation, not models," 07-16-2026. thenextweb.com
6. Plank Research, "Ode with Anthropic: FDE Profile" (summarizing Fractional AI-era case studies). joinplank.com
7. DeployCo (deployco.co), company site describing approval-gated agents (unrelated to OpenAI). deployco.co
8. Business Wire via Morningstar, "Ode with Anthropic and PointClickCare Announce Strategic Partnership to Advance AI-Enabled Workflows," 08-13-2026. morningstar.com
9. Palantir, "Dev versus Delta: Demystifying engineering roles at Palantir." blog.palantir.com