Forward-Deployed AI: Why the Best Consultancies Embed

Forward-deployed AI is a consulting model where agents run inside the client's own codebase, commit to their repo, and operate under the client's direct control from day one. At Armada Works, this is the only way we deliver: every agent, every prompt file, every state file lives in the client's repository, not ours. The term borrows from Palantir's "forward-deployed engineer" concept, where engineers embed at client sites rather than building from headquarters, and applies it to AI agent delivery.

The distinction matters because most AI consultancies do the opposite. They run agents on their own infrastructure, pipe results into a shared dashboard or Slack channel, and charge a monthly fee for access. The client gets output. They do not get the system. When the engagement ends, the output stops. Forward-deployed AI inverts that relationship: the client owns the system from the first commit.

What "Forward-Deployed" Means in AI Consulting

Palantir popularized the forward-deployed engineer role in the early 2010s. Instead of building software at headquarters and shipping it to clients, Palantir sent engineers to sit inside client organizations, understand their data problems firsthand, and build solutions directly in the client's environment. The model spread. Anduril, Sierra, and dozens of AI-native companies now use variations of it for product managers and engineers alike.

The same principle applies to AI agent consulting. A forward-deployed AI consultant does not build agents on a separate platform and grant the client a login. They deploy agents into the client's codebase, configure them to commit work to main, and set up coordination patterns that the client's team can read, tune, and eventually run independently.

Robert Cowherd, founder of Armada Works, describes it this way: "If the agents are running on our infrastructure, the client is renting output. If they are running in the client's repo, the client is building a capability."

Here is what separates forward-deployed AI delivery from traditional outsourced AI work:

	Forward-deployed (embedded)	Outsourced (remote)
Where agents run	Client's codebase and repo	Consultancy's platform or infrastructure
Who owns the prompts	Client (version-controlled in their repo)	Consultancy (proprietary, often locked)
Visibility into agent decisions	Full: git log, state files, daily briefs	Partial: dashboard summaries, API outputs
What happens when the engagement ends	System keeps running	Output stops
Knowledge transfer	Built into the model (client reads diffs daily)	Requires separate handoff project

Why Most AI Consultancies Outsource Instead of Embed

Running agents on your own infrastructure is easier to operationalize. You control the environment. You standardize the tooling. You can serve multiple clients from the same platform without managing different codebases, different git workflows, different CI pipelines.

The problem is that this model creates dependency by design. Three patterns show up repeatedly:

• Platform lock-in. The agents run on the consultancy's platform. The client cannot move them without rebuilding from scratch.
• Prompt opacity. The agent prompts are proprietary. The client cannot see why an agent made a particular decision, tune its behavior, or fix it when it breaks.
• No exit path. When the retainer ends, the agents stop. There is no codebase to hand over, no runbook to follow, no documentation that lets the client's team pick up where the consultancy left off.

This is the staff augmentation trap applied to AI. The consultancy provides labor (in this case, agent labor), and the client pays for as long as they need it. The system never becomes the client's own.

What Embedding Actually Looks Like

At Armada Works, embedding means the agent fleet runs inside the client's repository from day one. Every agent has a prompt file at docs/agents/, a state file at docs/agents/state/, and a scheduled cadence that commits work directly to main.

Here is what the client sees in their repo after the first week:

• Prompt files for each agent (CMO, SEO, Content, Sales Lead, Outbound, and any custom agents scoped to their bottleneck). These are markdown documents the client can read, edit, and version-control.
• State files that each agent updates after every run. The Content agent's state file shows what it drafted, what is in the queue, and what questions it has for the CMO agent. The SEO agent's state file shows current rankings, traffic snapshots, and open issues.
• Daily briefs committed to git and posted to a dashboard the client owns. The CMO agent reads every other agent's brief each morning and writes a single synthesis for the founder.
• Commit history that traces every piece of agent output back to the prompt and state that produced it. git blame works on agent output the same way it works on human code.

The client does not need to ask what the agents are doing. They can git log docs/agents/state/ and see the full history. They can open a prompt file, change a sentence, commit it, and watch the agent behave differently the next morning.

This is what forward-deployed AI delivery looks like in practice. The agents are not running somewhere else and sending results. They are running here, in the client's repo, under the client's version control.

The Embed-Then-Transfer Model

Forward-deployed delivery sets up the most important move: the transfer. Because everything lives in the client's codebase, handing it over is not a migration project. It is a matter of the client's team learning to do what the consultancy's team has been doing: reading briefs, tuning prompts, adjusting cadences, and handling the occasional edge case.

The transfer engagement model at Armada Works is a 2-to-4-week fixed-scope engagement ($10,000 to $20,000) that ends with the client running their own fleet. The Pilot ($2,500 to $4,000, one week, single agent) serves as the entry point: it proves the architecture works in the client's repo before either side commits to the full transfer.

The key insight is that embedding is what makes transfer possible. If the agents ran on the consultancy's platform, transferring them would mean rebuilding them from scratch in the client's environment. Because they already run in the client's repo, the transfer is a training exercise, not an engineering project.

For a detailed walkthrough of how the engagement runs week by week, see how an agent engagement actually works.

How to Tell If a Consultancy Is Actually Embedding

Not every consultancy that claims to "deploy into your codebase" is doing forward-deployed work. Here are the questions that separate real embedding from rebranded outsourcing:

1. Where do the agent prompts live? If the prompts are on the consultancy's platform or in a separate repo the client cannot access, it is outsourcing.
2. Can you git log the agent's output? If the agent's work shows up in a dashboard but not in your commit history, the agent is not embedded.
3. What happens on day one after the engagement ends? If the answer is "the agents stop running," the consultancy did not embed anything. They provided a service.
4. Can your team tune a prompt today? If changing agent behavior requires a support ticket to the consultancy, the system is not yours.
5. Is there a runbook? A forward-deployed consultancy leaves behind documentation that lets your team operate independently. If there is no runbook, there is no transfer.

Frequently Asked Questions

What is forward-deployed AI?

Forward-deployed AI is a consulting delivery model where AI agents are embedded directly into a client's codebase and infrastructure, rather than running on the consultancy's own platform. The client owns the agents, the prompts, and the system from day one. The term adapts Palantir's "forward-deployed engineer" concept to AI agent delivery.

How is forward-deployed AI different from AI outsourcing?

In an outsourced model, the consultancy runs agents on their own infrastructure and delivers results to the client. The client gets output but not the system. In a forward-deployed model, agents run inside the client's repo, commit work to main, and can be read, tuned, and operated by the client's team. When the engagement ends, the system keeps running.

What does an embedded AI consultant actually deliver?

An embedded AI consultant delivers a working agent fleet inside the client's codebase: prompt files under version control, state files that track agent decisions, daily briefs committed to git, a dashboard the client owns, and a runbook that lets the client's team operate independently after handoff.

How long does a forward-deployed AI engagement take?

At Armada Works, the Pilot engagement (one agent, one week, $2,500 to $4,000) proves the model works in the client's repo. The full transfer engagement runs 2 to 4 weeks ($10,000 to $20,000) and ends with the client operating independently. An Operate retainer ($5,000 to $12,000/month) is available for founders who want the output without running the system themselves.

How do I evaluate whether an AI consultancy is really embedding?

Ask five questions: Where do the prompts live? Can you git log agent output? What happens when the engagement ends? Can your team tune a prompt today? Is there a runbook? If the answer to any of these is "no" or "not yet," the consultancy is outsourcing, not embedding.

---

Book a free 30-minute discovery call to find out whether a forward-deployed agent fleet fits your bottleneck.