The first time I got embedded inside a client organization, I was 26. SAP migration. Manufacturing company in Latin America. Three other consultants on the ground, all of them engineers.

They could configure the system. They could write the code. They could migrate the data. What they couldn't do was answer the question the plant manager asked on day three: "Who decides what the system is allowed to do?"

That project ran eight months over timeline. Not because the code was wrong. Because nobody had mapped the authorization structure before the engineers started building. We spent the first four months configuring a system and the next eight unwinding decisions that should have been governance calls, not engineering calls.

I've watched that pattern repeat across four continents and 27 countries. The engineers arrive first. The architect arrives after the damage is done. And the re-work always costs more than the design would have.

→ In May, OpenAI and Anthropic spent a combined $5.5 billion to build consulting arms that embed engineers inside client organizations.

OpenAI's Deployment Company — backed by $4 billion from TPG, Goldman Sachs, Bain Capital, and McKinsey — acquired Tomoro, an applied AI firm, bringing 150 Forward Deployed Engineers on day one. Anthropic launched a separate venture with Blackstone and Goldman Sachs, backed by $1.5 billion.

Both are copying Palantir's model. FDE job postings have increased 42x since 2023 — roughly 8,500 new positions across OpenAI, Anthropic, Google, Salesforce, and Databricks.

The strategy is clear: the model is a commodity. Deployment is the bottleneck. Embed engineers in the client's building and ship outcomes, not software.

I agree with every word of that diagnosis. And I've seen what happens when you execute it without process architecture.

→ Here's what the FDE model gets right: proximity. You can't deploy AI into an organization's operations from a slide deck. You need someone who understands the client's systems, data, and workflows from the inside. Palantir proved this. Their FDEs built switching costs so deep that clients couldn't leave — not because of a contract, but because the system was woven into how they operated.

Here's what it gets wrong: scope.

A Forward Deployed Engineer's job description reads like this: "Ship production AI code. Build custom workflows. Integrate with client infrastructure." That's engineering. It's necessary. It's not sufficient.

What's missing is the layer that comes before the first line of code. Who decides what the agent is authorized to do? Where do humans stay in the loop? What happens when the agent is wrong and you don't find out for six months? How does the workflow change for the 30 people who currently touch it?

Those aren't engineering questions. They're process architecture questions. And 73% of enterprise AI projects fail to deliver ROI — not because the engineering was bad, but because nobody designed the operating model before the engineers started building.

The FDE model puts an engineer in the building. The gap is that nobody put an architect in the room first.

I've been that architect. Not because the title existed — it didn't, not in the agentic context. But the function is identical to what I've done in every Fortune 100 transformation: map the process, design the governance, define the authorization structure, and then — only then — hand the spec to the engineers.

Forward deployed without that design layer isn't deployment. It's improvisation at enterprise scale.

Every failed deployment I've worked on — SAP, Salesforce, or agentic — shares the same root cause: the wrong role led the engagement. Here's how to tell which one you actually need first.

Ask these four questions about your deployment:

1. Do you know what the agent is allowed to decide? If yes — with documented authorization scope — you need an engineer to build it. If the answer is "we'll figure it out as we go," you need an architect. Authorization isn't a configuration setting. It's a governance design.

2. Can you draw the workflow before and after? Not the technology architecture. The human workflow — who touches what, where decisions get made, where handoffs happen. If that map exists and the agent just accelerates existing steps, engineering leads. If the agent changes who does what, the architect designs the new workflow first.

3. Is the failure mode a bug or a governance gap? When something goes wrong, will you need to fix code — or fix a decision that should never have been automated? If your risk is technical (latency, accuracy, integration), that's engineering. If your risk is organizational (wrong person approved, no audit trail, compliance breach), that's architecture.

4. Who owns the outcome? If one team owns the deployment and the outcome, engineering can lead. If the agent touches multiple teams, approval chains, or compliance boundaries, you need someone who designs across organizational seams — not someone who optimizes within a single system.

If two or more answers point to "architect," the engineer isn't your first hire. The blueprint is your first deliverable.

→ $5.5B says deployment is the bottleneck. OpenAI and Anthropic launched competing consulting arms in the same month — OpenAI's at $4B with 19 investors, Anthropic's at $1.5B with Blackstone and Goldman. Both acquired or hired Forward Deployed Engineers. Both partnered with private equity firms that control thousands of portfolio companies. The model wars are over. The deployment wars just started. → TechCrunch

→ FDE is now the hottest role in AI — and the definition is already fracturing. 42x increase in FDE job postings since 2023. But OpenAI's FDEs write production code. Palantir's FDEs build custom platforms. Google's FDEs do integration work. Same title, different scopes, no standard. The role is being adopted faster than it's being defined. → MarkTechPost

→ 73% of enterprise AI projects fail to deliver ROI. $665 billion in global AI spending in 2026. Nearly three-quarters of deployments don't pay back. The research points to governance failures and missing operating models — not technical limitations. The money isn't the constraint. The methodology is. → AI Governance Today

→ Gartner names agent sprawl as the next shadow IT. Six steps to manage it, published late April. By year-end, large enterprises will run 1,600+ agents — and 70% of executives say their governance isn't fit for purpose. Only 18% have a complete inventory of what's already running. The agents are deployed. The architecture isn't. → Gartner

→ Constellation Research warns FDEs are the new limiting factor. The promise: embedded engineers who ship production AI. The peril: without governance frameworks, FDEs build fast, build deep, and build switching costs that lock clients into ungoverned systems. Speed without architecture isn't deployment — it's technical debt at $500K per engineer per year. → Constellation Research

This week's exercise: The Before-and-After Map

Pick the one workflow where you're considering an AI agent — or where one is already running.

Draw two versions on a whiteboard or a blank page. Left side: the workflow today. Every human touchpoint, every decision, every handoff. Right side: the workflow with the agent in place. Who gets removed? Who gets added? Where does the approval authority shift?

If the right side looks the same as the left side with one box replaced by "AI" — you're deploying an engineer. The architecture is unchanged.

If the right side has different decision points, different approval chains, different handoffs, different people involved — you need the blueprint before you need the build.

Most organizations skip this map. Then they spend eight months unwinding engineering decisions that should have been governance calls. I know because I've been called in to do the unwinding.

Draw the map first. It costs you 30 minutes. Skipping it costs you months.

→ If your before-and-after map looks different and you don't have the governance layer designed yet: DM me on LinkedIn or book 15 minutes — cal.com/ai-workflow/readiness-score

Agentic Congruence is a weekly newsletter about orchestrating ventures, agents, and systems. Published by La Maestría. Reply to this email anytime — I read everything.