The Platform of Primitives

Here's the objection every smart operator raises immediately: you can't run design partnerships at enterprise scale, because you can't maintain the output. Build something custom for every single customer and you're herding cats — a pile of really bad code, fifty-five repos nobody wants to learn, and engineers who quit rather than maintain them. The objection is correct. It's also the exact line that separates an FDE function from what it isn't.

Never from scratch

What makes an FDE program different is that FDEs build on top of a platform. There is already a set of primitives — data models, workflow engines, integrations, an agent runtime — on top of which they assemble an application, a workflow, a solution that is arbitrarily valuable to that particular customer. Assembly, not authorship. That's the key ingredient, and it's what keeps a hundred customer solutions maintainable by one team.

How atomic should a primitive be?

It depends on who you serve. In some industries you can ship robust primitives — the app is 60% built and the customer's solution is the other 40% of customization. In others you need extremely granular tooling. The calibration question is breadth: AWS serves an enormously broad swath of customers, so it ships granular primitives like DynamoDB — the reason nobody has racked their own servers or invented their own database since the 90s. Your platform's job is the same at whatever altitude fits your market: absorb the undifferentiated work.

The sorting rule

Every line of code an FDE writes lands on one side of a rule:

• Bespoke and unique to one customer → it stays scoped to that customer, and only that customer.
• Generalizable → it should be generalized into the platform, in the long term, as a new primitive.

Early on you won't have many primitives — that's fine. FDE work is also a scouting function: it's how you discover, from real customer problems, which primitives and products to build next. The field feeds the platform; the platform compounds the field.

One lineage, end to end

The sorting rule is easy to state and hard to believe without a worked case. Colin Jarvis has one, and it runs from a 2023 customer engagement to a shipped OpenAI product.

It starts at Klarna, with a problem that is about scale rather than difficulty: "if you're manually writing a prompt for every single policy and you've got 400 policies, this is not a scalable method of approaching this." The move was to stop writing prompts and start writing a shape — "we worked out a way of parameterizing the instructions and tools and then wrapping each intent with a set of evals, so that we could scale from, say, 20 policies all the way up to 400 policies or more."

Then the test that decides whether it was a primitive or a one-off. The framework was extracted, named Swarm, and open-sourced. In parallel a T-Mobile engagement began — "even more complex, like maybe 10× more complex in terms of the volume and the number of policies and the complexity of policies as Klarna" — and "this framework actually worked pretty well there with a few extensions."

That is the whole sorting rule executing once, in public, with names attached: a bespoke build for one customer, a generalization, and a second customer at ten times the complexity where the generalization held. Only after that did it become product — a team stood up to build what became the Agents SDK, and later AgentKit, which Jarvis describes as "just a continuation of that story that started in 2023." Today the FDEs use it as "a standard tool in their toolbox", which closes the loop the sheet opened with: what the field generalized, the field now assembles from.

How much is supposed to come back

The reuse fraction on a first engagement is low, and Jarvis's illustration of the intended ratchet is worth quoting precisely because the numbers are modest: "if the first thing was maybe like 20% reusable, the next two get us to maybe 50% reusable, and then we almost want to push it into the scaled part of the business."

Two things to hold onto. Those figures are his sketch of the shape, offered as an example rather than as a measurement of any particular engagement — they say the fraction climbs across roughly three customers, not that it climbs to 50.0%. And the ratchet has a defined exit: at some point the thing stops being FDE work and moves to the part of the company that can do it many times. A primitive that never leaves the FDE team is a primitive the FDE team maintains forever.

Where the platform stops

Two boundaries appeared in the field that the primitives-and-outcomes picture does not draw, and both are about work the platform should decline.

The first is other people's. Pauline Brunet routes whole categories of engagement to system integrators and consultancies rather than absorbing them: "there's a lot of stuff that I just frankly don't want to do and let's have the SIs do it… I'm not really that great at change management." Partners also carry at-scale rollouts of things the vendor has already done many times, which extends reach without extending the maintenance surface. A platform strategy that treats every adjacent task as a future primitive ends up owning training, change management and rollout — none of which compound.

The second is the vendor's own product. "I have customers who'll say, 'I want to do this.' And I will say, 'ooh, Cursor is not the right tool for that.'" Her stated reason is credibility rather than modesty — being honest about where the platform does not fit is what makes the next recommendation worth anything — with a plain second reason underneath: "if it doesn't go well, then you're on the hook for that."