How Forward Deployed Engineering Gets Autonomous Agent Squads Into Production

A forward deployed engineer (FDE) works inside the client's business, sitting with the people, reconstructing how a process actually runs, and writing the code that acts on what they find. 

An autonomous agent squad is a group of AI agents that plan and carry out multi-step work with limited supervision. 

Forward deployed engineering is how those squads reach production, because a squad can only act on context somebody has made legible to it, and in most companies that context sits in people's heads, in undocumented exceptions, and in APIs with no usable descriptions. 

The FDE surfaces it, encodes it, sets the boundaries the squad works inside, and stays on as the person who approves the decisions that carry real cost.

Why Do Autonomous Agent Squads Fail When In a Real Business?

Because they arrive with general competence and no institutional knowledge. The gap between those two things is where most of the work of a business actually lives. 

Tom Blomfield, co-founder of Monzo, described deploying agents as "replacing 90% of your employees with a team of geniuses who have no idea how your company operates. Total chaos. Nothing works." 

Garry Tan of Y Combinator called that gap "the actual bottleneck": the models are capable enough already, and what's missing is company-specific knowledge held by senior people who never had a reason to write it down.

Gartner's data seems to support this. According to them, through 2026, organizations will abandon 60% of AI projects that lack AI-ready data, and 63% of the data management leaders it surveyed either had no appropriate practices for AI or didn't know whether they did.

What makes this expensive with agents is how quickly a mistake travels. 

Ankit Sobti, co-founder of Postman, describes the characteristic failure as "the answer that looks right but isn't": plausible on the surface, wrong under a forensic read, and already several steps downstream by the time anyone notices. A weak process fails loudly and gets fixed.

Once a business has watched that happen, the autonomy it was willing to grant gets pulled back, and the program stalls in pilot indefinitely.

What Forward Deployed Engineering Actually Produces

An FDE produces a machine-readable account of how the business really works, plus the boundaries that keep an agent inside it.

The chain runs in order. The FDE reconstructs a real process step by step, including the steps nobody wrote down, then assigns each step to whichever of three owners should hold it. 

That assignment becomes the squad's operating envelope. Encoded context and reachable tools let the squad act, the envelope stops it acting where it shouldn't, and the verification surface tells both sides whether it worked. 

The outcome shows up as removed cost, captured revenue, or reduced risk, which is the only form in which the program survives a budget review.

Sobti's framing separates three concerns that usually get lumped together. The system of record becomes the context layer: knowledge structured well enough that retrieval works in practice rather than in principle. 

The system of action becomes the tools layer, meaning APIs and MCP servers described well enough that an agent can choose correctly between them. 

The system of intelligence is the agents plus their experience layer, meaning when they trigger and where they appear in work people already do. 

(Most teams optimize the third layer alone, then inherit problems from the first two and misdiagnose them as model problems.)

The market has already priced this in. 

Business Insider counted 643 forward deployed engineering postings on Indeed in April 2025 and 5,330 a year later, a rise of roughly 729%. 

AWS describes its own FDE organization as agentic-first, with deployments "structured around shared goals and business results, not billable hours," and self-sufficiency designed in: customers move from observers to co-builders to autonomous operators, and leave with runbooks, documentation, and trained internal champions. 

That only works if the deliverable is a running capability inside the customer's systems, operated by the customer's people.

What You Need To Do Before You Start Deploying Autonomous Agent Squads

The first artifact of a serious engagement is a written record of how a job is done today, produced by sitting next to the person doing it. Two examples from a walkthrough of FDE practice make the case better than an argument would.

A company put an agent on refund requests. It read each request, checked it against the written policy, and declined the ones that didn't qualify, exactly as specified. Weeks later the business was losing customers it had held for years, and every declined refund was one the policy said to decline. The person who used to do that job had a rule of her own that appeared nowhere: purchases made on a company card got approved without further reading, because arguing over a single refund can cost you an account that buys every month. That check went back into the workflow as a fixed rule sitting ahead of anything the model decides.

Palantir lost close to a year on a file format migration because one engineer kept reporting the new format was worse and nobody could work out why. She validated data by double-clicking the files open, and the new format had nothing to double-click. Someone built her an opener that evening, and she approved the migration two days later.

Neither rule is discoverable from documentation, a requirements workshop, or a ticket queue. Both surface when an engineer watches the work and asks why each step exists. A step nobody can justify concretely is usually a workaround that outlived its cause.

How To Decide What The Autonomous Squad Owns, And What It Never Touches

Assign every step in the mapped process to software, to the model, or to a person before any agent code gets written. 

Three questions settle most cases:

Does the step follow a fixed rule that has to come out right every time? It belongs in ordinary code, where it is cheap, testable, and boring. 

Does it require reading something messy and forming a judgment? That is what the model is for. 

Is it expensive when it goes wrong? It stays with a person even when a model could probably handle it.

Run those questions across a real process and the answer is almost never full autonomy. In one eight-step example from the same walkthrough, four steps ran unattended, three ran with a person checking the output before it moved, and one stayed entirely human because it was a business call.

Autonomy then widens in stages. A workable ladder runs read, rank, draft, recommend, act, with each level earning the next by performing on real work first. 

Jumping to the top is how teams end up with a system that is confidently wrong in production before anyone has measured how often it is right.

How To Make Sure Autonomous Agents Can Reach The Tools They Need

An agent is worth what it can reach, which makes your API surface the ceiling on what any squad can deliver. 

Sobti puts the constraint plainly: "MCP fronts your APIs; it doesn't fix them." Once agents start choosing endpoints and inferring parameters at runtime, instead of following call paths a developer wrote in advance, every documentation gap and every authorization inconsistency turns into a production incident.

A valid OpenAPI spec is not agent readiness. The spec says what can be called. Alongside it, an agent needs the business purpose of the endpoint, the domain vocabulary, auth guidance, known-good workflows, documented failure modes, ownership, and entitlements. 

Human developers survive without most of that, because a human reads the docs, asks a colleague, and tolerates ambiguity long enough to work around it. An agent takes whatever is machine-readable and guesses at the rest.

One client in that walkthrough had spent five million dollars over five years getting onto their finance system, so the whole job became connecting everything else to it. An MCP server over a tool the team already uses beats a migration that has to be sold and funded before the agent does anything useful.

The Difference Between ‘Decision Context’ and ‘Operational Context’

Context splits into two categories that behave differently, and mixing them is one of the more common reasons a promising agent degrades in production. 

Decision context is the stable set of rules: policies, schemas, standards, contracts. 

Operational context is the state of the world right now: who is authenticated, what this customer's balance is, which error just fired.

Two types of failures can look very similar to model weaknesses, so beware. 

The first is lost-in-the-middle behavior: filling a two-million-token window degrades retrieval of whatever sits in the middle of it, so a bigger context window is no substitute for curation. 

The second is retrieval that finds the policy and misses the exception. Semantic search will return the refund policy while missing a clause in another document blocking refunds on legacy enterprise contracts unless a manager override is set. 

Vectors capture similarity, not "A overrides B when C."

How To Build Verification Services That Enables Real Autonomy

Every increase in autonomy has to be paid for with a matching increase in how well you can tell whether the agent was right. 

Evaluation starts from the process you mapped: pull real historical cases where the correct answer is known, run the system across all of them, count the hits, then read every miss.

Inside the workflow, the discipline is auditing claims instead of trusting output. 

A data agent can write flawless SQL and still compare mismatched time windows or turn a sample of twelve into a board-ready conclusion. 

The version worth deploying checks every concrete claim against what the query returned, then rewrites, caveats, or drops whatever doesn't hold up.

The control layer around all of this is now a named engineering discipline. Okta's job description for a principal FDE on its agent identity team states the requirement directly: "Every agent needs an identity, a scope, an audit trail, and a way to be shut down when it goes wrong. Most enterprises have not built this yet." 

The same posting lists scope sprawl, delegation anomalies, and kill-switch verification among the things that team measures, at on-target compensation up to $369,000.

The liability floor is already set. In Moffatt v. Air Canada, the airline's chatbot told a passenger he could apply for a bereavement rate after traveling, which the real policy did not allow. 

Air Canada argued the chatbot was responsible for its own statements, and British Columbia's Civil Resolution Tribunal disagreed, awarding CA$812.02 for negligent misrepresentation. The sum was trivial and the precedent was not.

How To Ensure That Everyone Is On The Same Page Regarding Autonomous Squads

The boundary between the delivery team and the client organization is where most time-to-value gets lost, and it stays under-managed even by otherwise sophisticated teams. 

Sobti's account of the recurring pattern is worth taking literally. Context accumulates in calls and Slack threads rather than artifacts, so nothing survives a staffing change on either side. 

Build artifacts live only with the delivery team, so the client sees progress through demos instead of runnable evidence. 

The integration layer everyone expected to shrink grows instead. And the client ends up filing tickets against their own implementation, unable to change a tool definition without the team that wrote it.

Context, tools, tests, and observability belong in a workspace both organizations can see and change, and failure cases should travel as runnable artifacts with their environments attached rather than as bug reports. 

New engineers on either side then onboard by joining that workspace instead of rebuilding tribal knowledge from meetings.

This is also where the FDE's role changes shape rather than ending. Once the squad is live, the person who mapped the process becomes the senior human in the loop: reviewing output at the boundaries deliberately left human, watching the evaluation numbers move, and widening or tightening scope based on what the logs show. 

Customer self-sufficiency is the right test of when that role can end. If the handover leaves the client unable to operate what was built, the context work was never really transferred.

What Do You Need For Autonomous Agent Squads To Work?

• Data and API readiness stay the client's to own. When the underlying surface isn't agent-ready, most of the engagement goes into building that foundation for a single scoped use case.

• Someone in the business is named, available, and senior enough to say "that isn't how we do it." Mapping a process needs protected time, not an hour borrowed from whoever looks least busy.

• Every agent has an identity, a scope, an audit trail, and an off switch before it touches anything consequential. An agent scanning a corporate network will eventually reach payroll or merger files unless access limits exist first.

• An evaluation set exists before launch, built from real cases with known answers. Without one, "is it working?" stays a matter of opinion, and opinion loses to the first visible mistake.

• The budget covers trust as well as build. In one bank deployment, technical work finished in six to eight weeks and pilots ran four more months before advisers relied on the system. Roughly 98% of them eventually did.

• Token spend is planned as an operating expense. It behaves more like a utility bill than a license fee, which means monitoring, per-team attribution, and routing narrow tasks to smaller models.

To Deploy Autonomous Agents, First Learn About The Business

The compounding asset here is the structured representation of how a specific business operates: its authoritative policies, exceptions, decision rights, and precedents. 

Agents and models are replaceable within a quarter, but that representation is not. 

Every correction an operator makes and every override that exposes an unwritten rule can feed back into it and sharpen the next decision. 

Companies with a verification surface and a named owner end up with agents doing real work. Companies that treat it as a procurement problem end up with a pilot, a bill, and a story about how the technology wasn't ready.

Monterail builds both halves of that system: forward deployed engineers who do the process and context work alongside your team, and agentic delivery squads that build inside the guardrails those engineers set.