AI Forward Deployed Engineer Agent: Its Riskiest Output Is a Default

The riskiest thing our integration agent produced wasn't bad code. It was a confident default standing in for a decision nobody made.

Bad code eventually fails something: a test, a type check, a browser. A default that quietly decides who owns a patient chart has nothing to fail against.

We run an AI forward deployed engineer: a coding agent that onboards partners onto our Partner API. One engineer built the first version on our original platform. Another adapted it to the Partner API and proved it on an early partner tenant before anyone else used it. It takes a brand from credentials to a working site and intake funnel. It has three standing rules: never pick the questionnaire for the user, never invent the client's copy, and confirm before scaffolding.

The rules weren't enough. The agent still slipped, and the serious slips all had the same shape.

What an AI forward deployed engineer agent does

An AI forward deployed engineer agent is a coding agent that does the partner onboarding a human FDE would otherwise do. For an API company, that's most of the job. You read the API, work out which auth flow the partner's server wants, chase credentials, wire a client, then build the intake funnel and debug it in a sandbox. The work repeats from partner to partner with small changes, which is exactly what agents handle well. The patterns coding agents have converged on all apply here. What's different is the domain rules. I've covered the org side in The Two Rhythms of B2B Tech.

In June 2025, a16z's Joe Schmidt called the human role "the hottest job in startups". Most of what has been written since is explainers and job ads. Very little shows how to build the agent.

Palantir ships an "AI FDE" product, and its review loop is close to what you'd want. It branches every workflow and proposes changes as a pull request for human review. But it only operates Foundry. For your own API, you build it.

Measure engineer time, not tokens

I don't have a clean "before" number, and I won't invent one. What I have is model time:

• A build run is about 4M tokens.
• A storefront run is 3.5–15M tokens and about 6–26 minutes of generation.
• A new brand's site went from credentials to a working scaffold in about a day. Most of that day went on credentials and access, not generation.

That last line matters most. Once generation takes minutes, the bottleneck is the part no agent can touch: getting keys issued and access granted. The next win is in entitlements, not prompts.

So baseline two numbers before you build: time to first successful call per partner, and engineer hours per partner. Pull them from the time logs on your last hand-built partner. Tokens tell you what the agent costs. Those two numbers tell you whether it helped.

The gates before an engineer sees the PR

Ground the agent in your own material: your OpenAPI spec, your auth docs, reviewed past integrations and a sandbox. Then don't let it hand anything over until it proves the work. This is our pre-handover checklist. Every item exists because of a failure described below:

• The React hooks lint rules pass before any proof run.
• The funnel works end to end in a real browser. Passing tests, a type check and a server-side drive isn't enough.
• The agent walks the whole funnel, captures it as data, and checks every page against the client's source in a browser.
• Intake answers are validated on our side, and every coded answer carries its code system.
• Auth failures caused by entitlements get reported as platform issues. The agent doesn't patch around them in code.
• No business-rule defaults. Identity reuse, booking, paid status and test flags go through the gates covered at the end.

In healthcare, add two rules on day one: scoped sandbox keys only, never production credentials, and synthetic FHIR and HL7 fixtures only, never patient data. Save each finished onboarding as a regression case too, the same way you'd grow an eval set.

The API surface is a separate problem, covered in Every Service Is Going to Need an MCP Layer. That piece is about agents calling your API. This one is about an agent building a partner's integration against it.

What got past tests and a type check

It crashed in the browser on the first screen. Tests, the type check and a server-side drive all passed. The cause was a React hook after an early return. That renders on the server and fails in the browser. This is why the lint and real-browser gates exist.

The intake "succeeded" but the data was wrong. This is the one I'd warn every team about. The API said yes. The intake endpoint returns 201 even when the answers don't fit the form. A choice answer without its code system is stored unresolved, and eligibility then reads it as unanswered. Every check is green, and the patient looks like they skipped the question. A 201 tells you the request was stored. It doesn't tell you the data was right. Now we validate on our side, and every coded answer carries its system:

{
  "linkId": "smoking-status",
  "answer": [{
    "valueCoding": {
      "system": "http://example.org/fhir/CodeSystem/intake",
      "code": "never"
    }
  }]
}

One questionnaire reused the same question id eight times. That breaks any submit keyed by question id. We filed it as a questionnaire fix, not an agent fix.

It looked done, but it wasn't the client's site. The agent read only the landing page and invented the rest. So much for "never invent the client's copy." A rule in the prompt didn't stop it. A browser check against the source did.

We hit no FHIR or HL7 format quirks. The closest thing was identity mapping. Order events identify the patient by an EHR-side reference instead of the API's own patient id. People have to agree on that mapping.

The rule I use for support on a timer holds here too. Only hand a human work that has passed the gates that mean something. For a funnel, a real browser is one of those gates.

SMART Backend Services vs client credentials

It's common to treat these two as alternatives. They aren't. SMART Backend Services is a client_credentials grant with a signed JWT as the client assertion. The real split is symmetric versus asymmetric. Symmetric means a shared secret, sent with client_secret_basic or client_secret_post. Asymmetric means private_key_jwt, signed with RS384 or ES384.

Scope syntax changes by version too. Backend Services STU1 uses system/*.read. SMART v2 uses system/*.rs. The agent should detect the version, not assume it. Here's a sketch of the idea:

// Sketch: the server's advertised config picks the auth path and scope syntax.
const cfg = await fetch(`${baseUrl}/.well-known/smart-configuration`).then(r => r.json());
const supported: string[] = cfg.scopes_supported ?? [];
if (!supported.length) throw new Error("No scopes advertised; ask the partner, don't guess");

const authMethod = cfg.token_endpoint_auth_methods_supported?.includes("private_key_jwt")
  ? "private_key_jwt"       // asymmetric: signed JWT
  : "client_secret_basic";  // symmetric: shared secret

// SMART v2 read+search is ".rs"; STU1 is ".read".
const v2 = supported.some(s => s.endsWith(".rs"));
const scopes = ["Patient", "Observation"].map(r => `system/${r}.${v2 ? "rs" : "read"}`);

The spec also says expires_in SHOULD NOT exceed 300 seconds, so the generated client has to keep minting new tokens.

Discovery won't catch everything. Both of our auth failures were platform problems. In the first, a token minted fine and every call returned 403. The credential had been issued for an audience the API didn't accept. Fixing it took a platform change: per-environment audiences. The agent can't fix an entitlement. In the second, a tenant lacked a user-read scope. The agent now reports that as a platform entitlement, not a code bug. For SMART scopes from the agent's own side, see the FHIR MCP server piece.

What an AI FDE agent should never decide on its own

The standing rules didn't cover everything. These are the places where business rules came out as code:

• Identity policy. "Reuse the patient found by email" went in as plain code. That needed a human decision about proof of ownership.
• Program scope. The test tenant didn't sell the brand's product line, so the agent picked a different program on its own. It also recorded screens it had never seen as "agreed with the client."
• Payment and access. An unpaid, unverified session could book a visit. An overdue subscription counted as "confirmed."
• Environment policy. A test flag was hardcoded on every patient. That's a production decision, not a code default.

None of these was a bug in the usual sense. The code did what it was written to do. Each one is now a gate the agent can't pass on its own:

• proof of ownership before reusing a patient
• payment and a verified identity before booking
• only active subscriptions count as paid
• an environment-driven test flag
• never recording "agreed" without the user's agreement

Above those gates sit the things I wouldn't hand an agent at all: the BAA, and scoping which programs and product lines a partner is buying. People make those calls. The agent implements them.

The worst line our agent wrote passed every check we had. It looked like sensible dedupe: reuse the patient found by email. It was a chart takeover.