Platform engineering has evolved from a software discipline into a fundamental approach for redesigning how organizations work. In their new book Thinking in Platforms, Luca Galante and Kaspar von Grünberg make a compelling case: the biggest gains don't come from working harder or layering AI on top of chaos - they come from turning recurring knowledge work into scalable production systems. This post unpacks their core frameworks and what they mean for platform engineers navigating the agentic era.

Main insights

• Platform engineering is a production system for knowledge work, not just a tooling exercise
• The "path to outcome" model provides a reusable mental framework for designing platforms across any domain
• Enterprise AI adoption at scale requires platform engineering - there is no production-ready AI without well-designed platforms
• Starting small with a minimum viable platform and iterating based on user feedback is the key to sustainable success

Luca Galante is managing director at Weave Intelligence, the leading analyst firm in platform engineering, where he benchmarks how the discipline is practiced across hundreds of enterprise organizations. He hosts PlatformCon, and writes Platform Weekly. Kaspar von Grünberg has designed reference architectures, built platforms hands-on with hundreds of enterprise leaders, and supported platform initiatives at some of the largest organizations in the world over the past decade. As a technical founder, he has founded several companies in the field and built products like the platform orchestrator that powers large-scale Internal Developer Platforms across industry verticals. 

You can watch the full discussion here if you missed it.

Why this book, why now

The timing of Thinking in Platforms reflects a genuine inflection point in the discipline. As Luca explains, "We've iterated a lot on these concepts through our Platform Engineering University, which has been live for over two years. We felt that many of these frameworks had been stress-tested enough by literally thousands of students to commit to them in a book."

With 280,000 platform engineers globally, the discipline has reached the maturity needed to generalize its patterns. But maturity alone wasn't the only driver. "Platform engineering hit this inflection point in the last 12 to 18 months where it's moved beyond the traditional DevEx and infra focus within IT," Luca observes. "It's quickly incorporating FinOps and observability and security, and even beyond that, platform engineering is becoming ever more relevant in an AI-first world."

The book also addresses a gap that purely technical resources leave open: the sociotechnical challenge. "Many of us are engineers and start with that mindset," Luca says. "But it's really the social elements - getting user feedback, thinking of things as a product, getting support from your executives - those are the things that ultimately often determine whether a platform initiative will succeed or not."

Platform engineering as a production system

The book's central framework reframes platform engineering as a production system for knowledge work - a concept with deep historical roots. Kaspar draws a deliberate parallel to Henry Ford's transformation of automobile manufacturing: "If you go back to 1903 in Detroit, you have these workshops where a couple guys are assembling cars. Then in 1906, Henry Ford comes in and says the actual thing we have to do is take a step back and think about can we treat the way we're building that car as a product."

This shift from artisanal to platform-based production doesn't mean turning knowledge workers into assembly line workers. "You don't want to have a situation where the knowledge worker stops thinking," Kaspar clarifies. The book maps four distinct production system archetypes:

• Artisanal - Informal coordination, highly dependent on individual skill
• Hero-based - One senior person absorbs complexity and solves problems reactively
• Bureaucratic - Optimized toward security and compliance, often at the cost of velocity
• Platform-based - Deliberate design, clear interfaces, and scalable automation

Platform-based systems score highest across delivery velocity, organizational learning, maintenance efficiency, and operational resiliency. But the real insight is recognizing which archetype your organization currently operates in

Luca highlights the hero-based pattern many teams will recognize immediately: "We often talk about shadow operations, which is a euphemism to mask this idea of hero-based production systems where you have some usually more senior member of the team that steps up and says 'I'll take care of everything.' That solves the problem in the short term but creates this huge dependency that kills you when it comes to organizational learning and operational resiliency."

The path to outcome model

The book introduces paths to outcome as the molecular unit of platform thinking - a framework for decomposing what a platform actually does into discrete, designable units. "A path allows users to essentially get something from my production system," Kaspar explains. "I have an intent and the path is serving that intent for me."

Each path has four components:

• Input: The user's request or intent (for example, "I need a Postgres database")
• Interface: How the user expresses that intent - multiple interfaces can serve the same capability
• Capability: The platform's ability to fulfill the request, the underlying mechanism that creates the database
• Output: What the user receives to continue their work

One of the model's most clarifying insights is how it collapses apparent complexity. "In reality, the path of 'I need a database' can be a couple kinds of databases, a couple sizes of databases, but that's already factoring from a mathematical perspective," Kaspar explains. "You think like 'those are a lot of paths' - not true. This is one path. A path is 'I need a database.' That path accepts a couple different inputs."

The practical implication is significant: "Looking at this at scale in a software world, you can maybe think of 20 paths or 25 paths. It makes the whole problem a lot better to digest and understand." The framework also deliberately uses non-IT examples - including a content marketing workflow - to demonstrate that path-based thinking applies across any domain, from software delivery to legal operations to sales.

Platform engineering in the agentic era

The discussion returns repeatedly to AI as both a driver and a beneficiary of platform thinking. The pattern is familiar to most practitioners: "Everyone here is familiar with the idea of an impressive day zero, day one demo of some agentic AI use case," Luca observes. "But we've all also increasingly unfortunately become familiar with hitting that wall of 'okay, that was a cute demo - now how do I actually make it day 100 ready, production ready, enterprise-grade?'"

The answer is a well-designed platform. "You need somebody that essentially builds the guard rails, builds the paved roads and the golden paths, and allows you to standardize that behavior - that cute demo - into something that can drive automation, standardization, and governance by design," Luca explains.

Kaspar identifies two structural reasons why AI depends on platform engineering. First, agents require navigable, well-documented systems: "Agents need a very clear path through your estate. They need to understand where the context is, what capability to invoke. Things have to be behind well-documented, authentication-ready APIs." Second, the infrastructure that runs agents has to live somewhere - and the platform teams are the ones who will own it.

This creates unprecedented demand for platform engineering skills. "There's essentially no job role that is in higher demand," Kaspar notes. "My number one advice is the thing that will be 100% secure is platform product management or really anything related to platform engineering."

Beyond IT: Platform thinking everywhere

One of the book's more forward-looking arguments is that platform thinking is no longer confined to internal developer platforms. "You can consistently see legal platform engineers are starting to build agentic legal platforms. Sales platform engineers are building agentic sales platforms," Kaspar shares.

The traditional threshold of 50 to 100 developers for justifying a platform team has also blurred. Agentic workflows change the math: "If you're really agentic-enabled and you have 20, 30, 50, 100 agentic workflows running for each of you, you multiply that and you're already hitting that low hundreds of users or independent actors," Luca explains. "The moment you hit that, if you don't have a platform, you'll see the mess that quickly creates."

How to start: The minimum viable platform

For practitioners ready to act, the book offers a clear starting point. "Start small," Luca emphasizes. "Ask why as many times as possible and trim down so that you really get to what's actually essential and necessary - which is always way less than you originally think it is."

The minimum viable platform approach guides teams through four steps:

1. Identify the subset of applications or workflows to start with
2. Define the first set of users for piloting
3. Avoid over-complicating with edge cases
4. Talk to users and iterate based on feedback

"Don't think about all the potential security edge cases," Luca warns. "This is where things go to die and get stuck. Start small, iterate, talk to your users." User adoption is the north star metric: if teams are actively using your platform, you're moving in the right direction.

Kaspar adds a note on the value of simplicity that took real iteration to achieve: "Now you look at this thing and it's like 'this sounds so simple' - and it is very simple. But the power is in the simplicity."

​

If you enjoyed this, check out more great insights and events from our Platform Engineering Community.

If you want to dive deeper, grab a copy of the book, Thinking in Platforms.

​

Key takeaways

• Platform engineering is a production system, not just tooling. Understanding which production system archetype your organization currently operates in - artisanal, hero-based, bureaucratic, or platform-based - is the essential first step toward deliberate improvement. Platform-based systems maximize delivery velocity, organizational learning, and operational resiliency while preserving the creative freedom knowledge workers need.
• The path to outcome model simplifies platform design at scale. Breaking platforms into discrete paths (input, interface, capability, output) dramatically reduces apparent complexity. Most platforms need only 20 to 25 core paths, not the hundreds teams often imagine. This model applies across any domain, from software delivery to marketing to legal operations.
• There is no enterprise AI without platform engineering. Moving from impressive demos to production-ready, governed AI systems requires well-designed platforms with clear interfaces, documented APIs, and standardized workflows. Platform engineers are becoming the critical enablers of enterprise AI adoption across every business function.
• Start with a minimum viable platform and let user adoption guide you. Success comes from starting small, identifying essential capabilities, piloting with a focused user group, and iterating based on real feedback. If teams are using your platform, you're on the right track - that signal matters more than any feature checklist.