Lightly edited for clarity, September 2026.
We’re building AI platforms with the same playbook that gave us surveillance capitalism and engagement addiction.
I saw this pattern at VMware and at Stripe, and I’m watching AI platforms repeat it. It starts with technology that promises to empower users. Convenience features pile up around it, engagement becomes the metric, and eventually the system constrains the people it was built to serve.
The future of AI should look like the cloud infrastructure revolution: composable and user-controlled. It’s trending toward social media consolidation instead, centralized and optimized for engagement.
The Anti-Pattern We’re Building
Sam Altman’s “gentle singularity” vision – where he shares how AI will help accelerate innovation, solve hard problems, empower humanity – resonates with anyone who’s spent their career building platforms. I share that optimism.
I also see architectural mistakes in how we’re getting there.
ChatGPT as a “super-assistant” sounds powerful. Look closer and it’s vertical integration: models bundled with centralized storage of your context and memories, which creates dependency. It’s the monolithic, tightly coupled architecture every platform engineer has learned to avoid.
These systems feel powerful at first, then become bottlenecks, and over time their incentives drift away from the people using them.
The Productivity Debt Problem
At Stripe, the platform grew sustainably when it made its users successful. On the flip side, we saw how the aggregator model in consumer tech created perverse incentives: it rewarded time spent whether or not a problem got solved.
When platforms optimize for stickiness over utility, they create productivity debt: systems that feel helpful in the short term and constrain the people they serve over the long term.
The AI industry is walking straight into this trap. Your business model depends on keeping users engaged with your AI assistant? You’ve created a fundamental misalignment. Platform success now conflicts with user success. Users who accomplish goals quickly are bad for your metrics. Users who get stuck in long conversations are good for growth.
It’s structural debt, and it compounds.
Breaking the Pattern: The Three As Framework
Engineers don’t lack good intentions. The systems around them rarely reward building what users need.
The reinforcing loop is predictable: engagement metrics shape product decisions, product decisions create lock-in, lock-in reduces user agency, and reduced agency drives more dependency on the platform. It feeds itself. These loops have a common root: platforms optimized for engagement rather than outcomes.
To break them requires redesigning from first principles. In my InfoQ presentation on building successful platforms, I outlined three architectural principles that address them: Acceleration, Autonomy, and Accountability.
Acceleration: Build for capability
AI platforms should create leverage for the business by making users more capable.
Measure success by how quickly users achieve impact, not how long they spend on the platform. When AWS built EC2, they didn’t optimize for “time spent on EC2.” They optimized for how quickly developers could build and ship on top of EC2. Its value came from what developers could do after using it.
The architectural consequence: composability
This means building simple primitives that compose into powerful configurations. AWS created S3, EC2 and Lambda: building blocks that could be mixed and matched. AI platforms need the same approach.
Treat AI capabilities as APIs you can combine according to your needs. Let specialized AI services be composed, orchestrated and deployed based on what users actually need to accomplish.
When your platform’s value is measured by user outcomes, you build for composition, and users move faster, often leaving to build their own solutions. AWS grew by accelerating its users.
Autonomy: Separate What’s Shared from What’s Sovereign
Users maintain agency over their data, workflows, and choices.
The most critical architectural decision: separate AI models (compute) from user data (context).
The architectural consequence: data sovereignty
Share the expensive computational infrastructure. Model training and inference require massive scale to be economically viable.
But user contexts, memories, personal data? Those remain sovereign and portable. Keeping context sovereign also prevents the vendor lock-in that stifles experimentation.
When your personal AI context is trapped in one company’s platform, you lose the ability to experiment with better tools or switch to superior services. You can’t compose it with other platforms or take your investment elsewhere.
Cloud providers offer compute infrastructure while customers control their data and applications. AI platforms should work the same way. The compute can be centralized and shared. The context must be decentralized and owned.
Paradoxically, reducing lock-in often increases loyalty. Users who know they can leave feel safer investing deeply. The platforms that respect user sovereignty tend to retain users longer than those that trap them. I’ve seen the same pattern in engineering teams.
Accountability: Align Incentives with Outcomes
Platform providers answer to user outcomes. This requires transparent measurement, the right guardrails and aligned incentives.
The hardest part is resisting the pull of engagement metrics. When your board asks “how much time do users spend with our AI?”, the right answer is “as little as possible to achieve maximum impact.”
The architectural consequence: honest measurement and clear ownership
This means:
- Measuring what users accomplish
- Open APIs that third parties can build on
- Clear and owned interfaces between components
- Business models that reward solving user problems
Build systems where growth comes from enabling others to build.
When you’re accountable to outcomes, you document your limitations honestly. You make it easy for users to integrate with other services. You celebrate when users graduate from your platform to build their own solutions.
The moat is the value itself: users come back because you solve their problems.
Stress-Testing the Framework: The Hard Questions
Before we commit to an architecture, we need to stress-test it:
How do you prevent mission drift when growth incentives diverge from user interests?
Accountability prevents mission drift. When your platform’s success is measured by user outcomes, the misalignment becomes obvious in your metrics. You can’t hide behind vanity metrics when you’re measuring actual impact.
How do you build systems that remain trustworthy as they become more powerful?
Autonomy builds trust. Users trust platforms where they maintain control and can leave. Lock-in and trust are inversely correlated. As your AI becomes more powerful, users need more assurance they won’t become dependent. Data sovereignty provides that assurance.
How do you maintain these principles at scale?
Acceleration forces discipline at scale. When you measure time-to-impact, bloat becomes visible. Features that don’t accelerate user capability fail your metrics.
What This Means for Platform Engineers
For Acceleration:
- Design APIs that compose naturally
- Optimize for time-to-impact, not time-on-platform
- Build primitives and let users assemble the workflows
For Autonomy:
- Separate compute infrastructure from user context
- Make user data portable by default
- Enable seamless experiences without lock-in
- Let users own their AI’s memory and learned behaviors
For Accountability:
- Expose transparent metrics tied to user success
- Document limitations honestly
- Build business models that align with user empowerment
- Celebrate when users graduate from your platform
These require building AI platforms with the same rigor we bring to critical infrastructure: redundancy, observability, graceful degradation, clear ownership boundaries between components.
The future I want to build is one where AI platforms free people to put their energy into creativity and craftsmanship, and where power is spread widely enough that we keep the ability to choose.
The Choice
We’ve seen what happens when platforms optimize for engagement over outcomes. We don’t have to build it that way again.
As platform engineers, we get to make that call. What we measure, what we make portable, what we open up — these decisions determine whether AI empowers people or constrains them. We know enough to get this right.
I wrote a follow-up post on moving from pilots to production, which applies these principles to the practical challenge of rolling out AI across an engineering organization.
What are your thoughts on AI platform architecture? Reach out on LinkedIn.