The next platform team

Within 18 to 24 months, every large enterprise will have an AI platform team. That is a forecast, and it is mine. The sources below are what I am leaning on, and the section near the end is what argues against me.

Cloud infrastructure and data each ended up with a team of their own. Neither started that way. First came a few engineers doing the work, then a vendor that made the layer easy to buy (AWS, then Snowflake and Databricks), and then there was too much to control, coordinate and align for it to live in the corners. The company needed one owner.

Ask a large company today where AI lives and I expect the answer to be somewhere between security, IT and no idea. I have not run that survey, so the numbers below are the nearest thing I could find. The pattern is the same one, and the infrastructure is already there to be controlled: gateways, tool servers, agent identities.

The other half of the bet: how I think products should be built. A product-minded engineer and a designer or PM, directing agents through gated loops: the KFTCDA pod. A platform team is what makes a pod that small workable, because the pod does not have to build the gateway, the permissions or the evals. It directs agents on top of them.

Each era has the same arc: a new layer appears, people build on it, and then a team forms to own it. The last milestone in each column is that team. For cloud and data it is something I can point at. For AI it is the dashed one, the projection.

Flip between the two. On the left is the company as the surveys describe it now. On the right is what I think the same company looks like with one team owning the shared parts.

The pieces are not hypothetical. Gateways, tool registries and agent identity all shipped in the last two years, and two companies that wrote about it, Uber and Cloudflare, built their own gateway. The open question is who in your company owns it.

A team of n people has n(n−1)/2 paths between them: two people, one path; five, ten; nine, thirty-six. Drag the slider. Brooks used this to explain why adding people to a late project makes it later, and Amazon's two-pizza rule and Team Topologies's size of around 8 are the same worry written as policy.

This is my recommendation, and the way KFTCDA builds products: a product-minded engineer and a designer or PM, each directing agents through gated loops. Two people and one path between them. Agents do not add paths between people the way a new hire does; they change what a person can own. One practitioner puts it as “The unit of building should shrink. The unit of ownership should not.” Anant Jain I agree.

Here is the evidence I could find that points the same way. None of it is a company saying “we run on pairs”: companies have not broadly standardized on this, and I am not claiming they have.

• LinkedIn replaced its associate product manager program with an Associate Product Builder program "that teaches coding, design, and PM skills together", and a "Full Stack Builder" title (December 2025). LinkedIn builders
• Every had 15 people running five products in July 2025, "with primarily single-person engineering teams". Every: compound engineering, Lenny on Every
• One practitioner writes of "1–2 engineers, supported by a PM/Designer", and that "the unit of building should shrink. The unit of ownership should not." (August 2026). Anant Jain
• Anthropic's engineers "described becoming leaders and managers of agents" (October 2026). Anthropic: employment
• A survey of Anthropic's own staff found "everyone is becoming more full-stack" (December 2025). Anthropic: how work changes

A pod this small only works if something else carries the load, which is the platform team above, and if the agents work inside gates that check their output. See One loop, three models for what a pod's agent loop looks like, and Designing an agent graph for how it is wired. Below the pinch of salt is what KFTCDA does with both.

The platform team does not use AI for its own sake. It serves workloads, and pods direct them. These are the five I would start with. For each, what the platform has to provide and the best evidence I found.

The patterns underneath come from Building effective agents. Pick the simplest one that works, and add the next only when a measured failure asks for it.

• Workflow. Model calls and tools orchestrated through predefined code paths.
• Agent. The model dynamically directs its own process and tool use.
• Orchestrator-workers. One model splits the job and workers do the pieces. Research uses it.
• Evaluator-optimizer. One call drafts, another judges against a rubric, and the draft improves.

This is what my consultancy, KFTCDA, does. I help a company design and stand up these structures, and build its products this way, then hand them over:

• The AI platform team. Its charter, who owns it, and its first infrastructure: the gateway, the tool registry, agent identity and permissions, evals and cost.
• The KFTCDA pod. How I build products: a product-minded engineer and a designer or PM directing agents through gated loops. For an existing team, reshaping it into pods like that, with a clear owner for each outcome.
• Agent loops and gates. The loops, skills and verification gates installed in your own repositories, so the work passes checks written down before it starts.

The first step is a pilot: an AI-native engineering team, which is a Build engagement, from $9,999, measured in weeks. It starts with a 30-minute call, free: we name the outcome, pick the tier and I follow up with a fixed price in writing. Standing up the whole platform team is the follow-on, a Transform engagement, from $49,999, measured in months.

Book a scoping call: AI-native team pilot, from $9,999