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.

After 170 days of running our own eight-agent fleet this way, the model has survived enough operational stress that we can describe not just the theory but the failure modes, the maintenance patterns, and the specific moments where embedding proved its worth over outsourcing.

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
Operational debugging	Client can trace any failure to a specific commit and prompt version	Client files a support ticket and waits

The Forward-Deployed AI Landscape in 2026

The AI consultancy market is splitting into two camps, and the distinction maps directly to the forward-deployed question.

On one side, firms like Agency (agen.cy) have scaled to 518 employees and 400+ agents, running what amounts to a managed service. Their scale is impressive, but the model is fundamentally outsourced: their agents run on their infrastructure. AY Automate, which claims Anthropic Partner Network membership, runs Claude Code agents for clients but retains operational control. ClaudeCodeDeveloper.com, a newer entrant focused specifically on Claude Code delivery, operates a similar model.

On the other side, a smaller group of consultancies delivers forward-deployed. The agents ship into the client's repo. The prompts are version-controlled by the client. The consultancy's job is to build the system and leave, not to run it in perpetuity.

The distinction matters most at the end of the engagement. An outsourced consultancy's 400-agent fleet is impressive while you are paying for it. The day the retainer ends, you have nothing. A forward-deployed consultancy's output is less flashy while you are paying for it. The day the engagement ends, you have a working system.

JADA Squad has built a content moat of 400+ pages about agent operations, but their content is marketing for a service, not documentation of a transferable system. Stormy AI publishes extensively about agentic marketing with Claude Code, and NoimosAI covers similar ground. These are competitors in content, but the operational question remains: does the client own the system when the relationship ends?

For a broader look at how to evaluate these firms, see the buyer evaluation pillar page.

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. This is also why senior AI hires stall without operational backing: they get strategy authority but no implementation infrastructure, and an outsourced agent fleet does not fix that gap because it never becomes the organization's own capability.

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.

The fleet currently runs eight agents: a CMO synthesizer that reads every other agent's daily brief, plus seven specialist sub-agents (SEO, Content, Sales Lead, Outbound, Email Marketing, Social Media, and X Prospecting). Over 170 days, the Content agent alone has shipped 52 blog posts across 103 runs. The SEO agent has completed 150 sessions of ranking monitoring and technical audits. The state files for these agents now carry months of institutional knowledge: what worked, what failed, and what the agent should watch for next session.

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

• Prompt files for each agent. These are markdown documents the client can read, edit, and version-control. A prompt change is a git commit, not a support ticket.
• 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.

What 170 Days of Forward-Deployed Operation Taught Us

Running a forward-deployed fleet for nearly six months has surfaced three failure patterns that validate the embedding model. Each one would have been invisible in an outsourced arrangement.

Auth degradation is silent until it isn't. On Day 89, the Social Media agent's Buffer API token expired. The agent did not crash. It simply stopped posting and reported "0 posts scheduled" in its daily brief. Because the brief was committed to git and the CMO synthesizer reads every sub-agent's brief, the degradation surfaced within one morning cycle. In an outsourced model, this failure would have been a line in someone else's log. In a forward-deployed model, it was a diff the founder could read over coffee.

State files grow, and growth is an operational surface. The Outbound agent's state file grew to 1,800 lines over five months. The X Prospecting agent's hit 1,100 lines. At that scale, the state files become harder for the agents to parse accurately, and subtle errors compound. The fix is periodic compaction: trimming completed entries, archiving historical data, resetting counters. Because the state files live in the client's repo, the founder can see the growth happening in real time (git log --stat docs/agents/state/) and schedule compaction before it causes problems. If the state files lived on the consultancy's platform, the client would only learn about the problem when agent quality visibly degraded.

Prompt maintenance is continuous, not one-time. The Content agent's prompt has been revised across 103 runs. Each revision is a commit the client can trace. The SEO agent's prompt absorbed new competitive intelligence (ClaudeCodeDeveloper.com, Stormy AI, JADA Squad) as the landscape shifted. Forward-deployed delivery makes prompt maintenance a normal part of the workflow, not a black-box version bump the client cannot inspect.

For a deeper look at how these failures surface and resolve, see what happens when agents break and the production runbook.

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. Forward-deployed delivery is one piece of a broader AI org-design approach that addresses why most senior AI hires stall: the role gets strategy without implementation infrastructure, and embedded agent fleets provide that infrastructure from week one.

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. See what a production runbook looks like for what that should contain.
6. Can you see when something broke and why? A forward-deployed fleet surfaces failures in git diffs and daily briefs. If failures are invisible until you notice missing output, the fleet is running on someone else's terms. Auth degradation, state-file bloat, and prompt drift are operational realities of any agent fleet, and your visibility into them determines whether you can fix them independently.

For a comprehensive buyer checklist that covers these questions and more, see how to evaluate an AI agent consultancy.

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 production 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 six 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? Can you see when something broke and why? If the answer to any of these is "no" or "not yet," the consultancy is outsourcing, not embedding. For a detailed framework, see the buyer evaluation guide.

What operational challenges come with forward-deployed AI?

Three patterns surface over months of operation: auth tokens expire silently (the fix is visibility into daily briefs, not a monitoring platform you cannot access), state files grow and need periodic compaction (the fix is git log --stat and a compaction schedule), and prompts need continuous tuning as the competitive landscape shifts. Forward-deployed delivery makes each of these visible and fixable by the client's own team. For more, see what happens when agents break.

Are there consultancies that scale forward-deployed delivery?

Currently, most large-scale AI consultancies (Agency at 518 employees, AY Automate, ClaudeCodeDeveloper.com) run outsourced models because outsourcing is easier to scale. Forward-deployed delivery requires adapting to each client's codebase, git workflow, and CI pipeline. Armada Works prioritizes embedding over scale: fewer clients, full ownership at the end. For a landscape overview, see AI agent consultancies for founders in 2026.

---

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