I will warn you up front: I have something to sell you. It is an idea.

Last time I asked what people actually mean when they say Forward Deployed Engineer, and I argued that the thing separating most of them, AI-native or plain software engineer, internal or external, from a very good consultant is the platform. A repeatable, improvable, iterating base underneath the work. It is the commodity layer that makes each customer engagement look bespoke on top without being bespoke all the way down. Call it 50 to 80 percent that is not custom. You put the customization on top of a base that is efficient, scalable, and something a team can actually maintain.

If you are working as an FDE without one, you, or the company paying for you, should probably want to invest in that. And here is what has changed: it is 2026, this is the age of AI in the cloud, and in a lot of cases you can build your own repeatable IDP that works well.

The usual objection is fair. "I am not Palantir. I am not Anthropic. I cannot spend a decade and a hundred engineers to build Foundry." Correct. You do not have to. If we are talking about hosting applications in a repeatable, scalable way, and you want those applications to be AI workloads, Claude has made that more reachable than it has ever been.

Start with what the platform actually buys you, in plain terms. A golden path, so you are not hand-wiring the same scaffolding at every client. Security and observability that are simply handled, injected into and around the application instead of bolted on by hand, so you can see what your deployment is doing in the customer's environment. Policy and access control, so the customer's security team says yes. A self-service layer, so the customer uses the portal instead of pinging you, and your time goes into improving the portal instead of answering the same request twice.

I will be honest about what I am suggesting here. At Palantir the Delta wrote the customer code, the Echo handled adoption, and a separate core product team did the generalizing, turning one customer's bespoke work into a reusable platform feature. What I am proposing is that a modern FDE, or a small FDE team, can now do that generalizing too, because the agent does the platform engineering. You build the bespoke last mile and fold the reusable parts back into a base that makes the next engagement faster. Maybe that is too much for one person. But if you have a team, it is worth considering. I would bet you could stand up a very respectable platform even as an FDE.

The reason I am pushing this is that for an FDE, that repeatable, evolving base is the whole game. It is the difference between walking into a constrained environment and shipping in days, and rebuilding the foundation from scratch every single time, which takes weeks.

Standing up a platform like that used to be a multi-quarter program with a dedicated team. It is not anymore. An AI coding agent can do the platform engineering itself, on a hyperscaler, on a real Kubernetes cluster, in hours.

I am going to show exactly that on July 23, and I will be straight with you, I am selling you the idea because I want you to come see what it looks like. Claude Code builds a 33-component AI-native Internal Developer Platform, live, on a real Kubernetes cluster on AWS. Honestly it will probably take less than four hours. I ran the predecessor at KCD Texas in Austin this year, and on the test run with a solid spec file, Claude Code stood the thing up in under ninety minutes. It took me longer to test the cluster than it did to build it.

Here is roughly what gets built. The cloud-native foundation first: Backstage for the developer portal, the Argo stack for GitOps delivery, an OpenTelemetry plane for observability with Prometheus, Grafana, and Jaeger behind it, Kyverno for policy, External Secrets for secrets management wired into AWS. Then the AI plane that makes it AI-native: kgateway and agentgateway, kagent for declarative agents, LLM Guard for prompt-injection defense on both input and output, KServe and vLLM serving a model inside the cluster, llm-d for distributed inference. Runtime security where the cluster needs it, KubeArmor and Tetragon. Every component reconciled from Git by ArgoCD, and the agent that builds it runs on an allowlist and shows up in the platform's own audit trail.

Now put an FDE on top of that. You walk into a customer's environment with a commoditized AI-native workhorse you can stand up fast, and your work is the last mile, the fit to their reality. You can walk in and bend it to DoD standards if that is what the engagement needs. Exactly like a Palantir Delta and Echo, except in one person, or one small team.

The difference is that the base that took Palantir years is something you can now provision in an afternoon. The model that made the FDE valuable in the first place is suddenly within reach of a single engineer, or a single team of engineers. That is the argument in full. The FDE role was never only about being embedded, or about writing production code in someone else's environment. Plenty of consultants do that. It was about doing it on top of a platform that made the work repeatable. For more than a decade that platform was a moat only a few companies could afford. It is not a moat anymore. An agent will build it for you.

If you want to see it built, come to the workshop. Thursday, July 23, 11 AM to 3 PM EDT, virtual and hands-on. You build alongside on your own cluster and take the whole platform home.

Register: https://www.eventbrite.co.uk/e/agentic-devops-with-claude-build-a-33-component-ai-native-platform-live-tickets-1991969049048?aff=MichaelLinkedIn. Use code MICHAEL40 for 40% off.