A Model Alone Is Not an Agent: What the Tooling Changed for the FDE Seat

Anthropic filed its S-1 on Monday, and the forward deployed engineer is on page one. In the defined terms: "Applied AI teams, which include forward-deployed engineers, work with enterprises to design and deploy custom solutions, specialized workflows, and domain-specific implementations tailored to a customer's own systems and processes." First registration statement I know of that puts the seat in the glossary.

The line I'd pin to the wall is under a heading called Harnesses. "A model alone is not an agent." The filing defines the harness as the secure environment, credentials, memory, and orchestration loop a model needs to plan, call tools, verify its work, and finish a task on its own. Then: "Building and operating that infrastructure is specialized, continuous work that, until recently, each customer had to take on themselves."

Until recently, the FDE built that. Now the vendor sells it, two ways. The Agent SDK makes "the same production-grade harness that powers Claude Code available to all developers, to run on their own compute." Managed Agents has the vendor run it, and "customers define their agent's tasks, tools, and guardrails." When a new model ships, "customers do not need to rebuild their agent loop."

Three write-ups pulled the numbers the same day. Rebecca Bellan at TechCrunch: more than half of customers spending $100,000 or more a year use both the platform and a first-party app, up from about 30 percent at the end of last year. Matthew Burns at The New Stack: Claude Enterprise users without Claude Code spent under $75 a month in the third quarter, and the top 5 percent with it spent about 20 times that. John Gleeson at SuccessVP counted 154 passages in the filing about the work after the sale, and landed on a line I'll borrow: "Models open the gap. Customer success closes it."

This is part 13 of The FDE Transition. Part 12 was the eval. This one is what Claude Code, harnesses, and agent platforms changed for the seat, and the S-1 is the week to write it: the company behind the most-used tool in the seat just wrote down, in a document it's liable for, what it thinks the tool is and what the engineer does.

The short version

The tooling moved the FDE's deliverable up a layer. The engineer on site used to write the loop, the retries, the credentials, and the integration code, and that was most of the job. Now the vendor ships the harness, often before the engineer arrives, and the seat's work is what the filing admits is still missing: "connectors that do not yet exist, governance frameworks that are not yet written, and orchestration logic that needs to be built from scratch," plus the skills that "turn institutional knowledge into agent capabilities." The FDE's output became a skill, a connector, and a row set, not a repo. That's cheaper to hand back and easier to generalize, which is the loop this series is about. And one thing the tooling didn't change: nothing checks a prompt. Changes got 45 times faster. Checking didn't.

The harness left the FDE's backpack

Part 4 drew three layers. The customer layer the FDE owns outright, the harness that changes by pull request with a price attached, and the core, where the word is fork. The S-1 takes the middle layer out of the customer's hands and out of the FDE's. The primitives are named in one paragraph: the Agent SDK, Managed Agents, agent skills, multi-agent orchestration, and MCP. "While these agents have different connectors and agent skills, they have the same SDK, protocol, and orchestration framework."

Read that as a job description. What's different per customer is connectors and skills. What's the same is everything the FDE used to build.

Nobody on site should have been writing retry logic, and the harness-tax study in part 4 showed how the hand-rolled version goes, same model and twice the bill. But the handback moved with it. Colin Jarvis's account of OpenAI's team last week already read this way: when a rebuilt deployment reached the next team, the work was swapping connectors and "building fresh evals (which we also had a skill for)." The harness didn't come up because it was already there. And with Managed Agents the model swap, which Lesson 07 of Becoming Forward Deployed Engineer spent a whole lesson on, becomes something the vendor does for you. That layer is gone, or going.

The tool arrives before you do

The sentence that changes week one: "By the time our direct teams engage a customer, Claude is often already in use."

The risk factors say it in their own voice: diffusion has been organic, "driven by individual users, including software developers and prosumers, who adopt Claude and often serve as internal champions," rather than by a large direct sales organization.

So the FDE lands where a dozen developers already run the harness, with skills they wrote, connectors they wired, and prompts nobody versioned. Week one isn't an install. It's an audit. What's running, who wrote it, when it last changed, what checked the change. The handback packet from part 3 now starts with an inventory of a deployment the FDE inherited.

The filing claims the next step too. "Claude can draw on that accumulated context to suggest the next workflow worth automating, reducing the effort required for each successive deployment." That's the generalization step. I'd let it suggest. The loop chapter gives the PM the editor's job, and the editor doesn't go into the harness.

The skill is the unit of handback

The S-1 on skills: "custom skills can capture anything from engineering standards and regulatory processes to proprietary toolchains. These skills turn institutional knowledge into agent capabilities."

That's the FDE's job, written as a product feature. The engineer on site goes in to find the rule that lives in a senior adjuster's head. Part 12 said the eval session is where it comes out. The skill is where it goes. A skill is text. It's versioned. The next customer's harness can load it. It's the most generalizable artifact an FDE has produced, and the easiest to overfit, because it's cheap to write one that only works in one building. Which makes it the right thing to put generalization rate on. The scorecard counts the share of what came back from the field that shipped. A skill either loads cleanly at the second customer or it doesn't. Jarvis's eval-writing skill loaded. That's the bar.

Practitioners are already packaging the seat this way. rpraharaj's forward-deployed-engineer repo on GitHub ships 43 Claude Code skills grouped by stage, land to sustain, undated as I write this, and its README says 37 of them are untested in production. An honest number.

Nothing checks the prompt

Lesson 08 of Becoming Forward Deployed Engineer came out on Monday, the same day as the S-1. "A prompt is code with nothing checking it." The story: "Someone shortens it on a Thursday to save tokens." Four lines removed, the pull request reads fine, and about two weeks later the adjusters say the answers got worse, with no way to connect the two. One of four wordings answers seven fewer questions out of forty-two, and nothing in code review would have told you which.

The fix is a prompt registry where the eval score is a field of each version, written by the same function that ran the eval. "Version the text without the score and the history tells you what changed and never whether it helped." I wrote the prompt commit for the same reason, after a classifier of mine went from 89 to 61 percent on the same prompt and a different row set.

Now put that next to the filing's own numbers. "Over 90% of the contributions to our codebase in September 2026 were written by Claude." Code volume per engineer, over 45 times what it was in 2024. The vendor's engineers "increasingly direct and review its work rather than write code line by line." If that's true inside the lab, it's true on site. The harness writes the connector, drafts the skill, and trims the prompt on a Thursday.

The thing that didn't get 45 times faster is checking. The harness made the change cheap and left verification in a human's head, unless somebody built the eval into the loop. Part 4 put it on engineering: run every customer's rows on every harness change. Add every model swap the vendor does for you, and every prompt a harness trims.

The $100 million admission

One more passage. The filing says the Claude Frontier Academy, "backed by a $100 million commitment," exists "to address a key constraint on enterprise AI adoption: the shortage of engineers who can take AI from an initial use case into production." Ten thousand engineers by the end of 2027. Next to it, Ode with Anthropic, an AI services company for mid-sized firms, which "will partner closely with our Applied AI and go-to-market teams."

Part 2 argued the FDE shortage is a product problem. The vendor's answer is to turn the seat into three things: a product (the harness), a training program (the Academy), and a services firm (Ode). The product takes the part of the job that was the same everywhere, and the training moves the rest to the customer's own engineers. What's left for the FDE is the part that was always the point. Gleeson's line is right as far as it goes. The harness closes the first half of the gap. The eval and the handback close the second, and those are still a person's job.

What this means in the seat, and at the top

If you're the FDE: stop building the loop. Your deliverables are a connector, a skill, a row set, and a governance rule the customer can read. If you're writing retry logic in 2026, you're competing with the SDK.

If you run product: the handback arrives as a skill file and an eval, both small enough to read in an afternoon. The tool will suggest the next workflow. You decide.

If you run engineering: the harness is upstream of you now. Every harness version, every model swap, every prompt change, run the rows.

If you're the buyer: the harness is rented. Ask what you own. Under the buyer's contract that's the skills, the connectors, the evals, and the governance, in a form the next vendor's harness can load on day one.

One thing to try this week: list every skill, connector, and prompt running at your live deployment. Three columns next to each: who wrote it, when it last changed, what checked the change. The blanks in the third column are where the next reversal comes from, and the harness won't fill them in for you.

Sources: Anthropic, PBC, Form S-1 Registration Statement, SEC (filed October 26, 2026), with the Applied AI definition, the Harnesses section, the Claude Code spend figures, the Academy, and Ode with Anthropic · Rebecca Bellan, "Anthropic's IPO filing reveals its strategy for keeping enterprise customers hooked," TechCrunch (October 26, 2026) · Matthew Burns, "Claude Code's top enterprise users outspend other Claude users 20 to 1, Anthropic's IPO filing says," The New Stack (October 26, 2026) · John Gleeson, "Anthropic's S-1 and the Value of Knowing the Customer," SuccessVP (October 26, 2026) · Becoming Forward Deployed Engineer, "Lesson 08: Prompts Belong In Version Control, Not In A String," Substack (October 26, 2026), author unnamed · Colin Jarvis, "What FDE means at OpenAI," OpenAI (October 22, 2026) · rpraharaj, forward-deployed-engineer, GitHub (undated)

Part of the running argument on AI Product Management: once building is cheap, the scarce work is deciding what gets built for everyone, and the harness made building cheap for the engineer on site without deciding anything.

Related answer: What did agent harnesses change for forward deployed engineers?