Lessons from Putting AI in Front of a Platform
- Daniel Bryant
- Jun 22
- 7 min read
Over the past year, much of the industry conversation around AI has focused on model capabilities. We debate which models reason better, write better code, or perform more effectively on increasingly complex benchmarks. At the same time, organisations are beginning to explore a more practical question: what happens when AI starts interacting with real systems?
What happens when AI isn't simply generating text or code, but is instead provisioning infrastructure, consuming internal services, or carrying out operational tasks on behalf of developers?
This was the focus of a recent webinar by my colleague Shane Dowling, who explored what we can learn from putting AI directly in front of a platform. The discussion touched on platform engineering, developer experience, organisational design, and AI reliability, but the core insight was surprisingly simple.
The effectiveness of an AI system is often less about the intelligence of the model and more about the quality of the interfaces it is allowed to use.
AI, Possibility Spaces, and Reliability
One of Shane's central arguments was that it remains useful to think of AI as a highly sophisticated prediction engine.
Every prompt creates a large space of possible responses and actions. Some lead to the outcome we want. Others may be plausible, convincing, and completely wrong.
Viewed through this lens, reliability becomes less about making models smarter and more about reducing the number of undesirable paths available to them. The challenge is not simply knowledge. It is managing the operational possibility space in which a model is allowed to operate.
This distinction becomes particularly important when AI begins interacting with production systems.
Why More Context Isn't Always the Answer
A common response to AI mistakes is to provide additional context. We add documentation, runbooks, examples, architecture diagrams, and organisational knowledge in the hope that the model will make better decisions.
Sometimes this works well. Context can significantly improve results by narrowing the scope of the problem. However, more context is not always better context.
Shane used a memorable analogy during the webinar. Imagine asking someone for directions through a city and then handing them not only a current map, but also several historical maps, details of last year's roadworks, a tourist guide, and notes from people who used to live there. While you've narrowed the conversation to a specific city, you've also introduced multiple versions of reality. Some information is current, some is outdated, and some may never have been entirely accurate.
AI systems face a similar challenge. When we provide large collections of organisational knowledge, we often expose models to multiple approaches, conventions, and interpretations. Some may reflect current best practices, while others represent decisions made years ago and since replaced.
The result is that a model can generate answers that appear well-informed but are actually based on outdated assumptions or invalid organisational practices.
The goal, therefore, is not to expose AI to everything. The goal is to create environments where invalid actions become increasingly difficult to generate.
Better Models Help, But Boundaries Matter More
It would be easy to conclude that these challenges will disappear as models improve. Better models, better retrieval systems, richer context windows, and emerging standards such as MCP will undoubtedly make AI systems more capable. They will reduce many classes of error and improve an agent's ability to discover and use organisational knowledge. However, none of these advances eliminates the need for well-defined interfaces.
In fact, the opposite may be true. As AI systems become more capable, the consequences of poorly designed interfaces increase. An agent that can only answer questions may generate an incorrect response. An agent that can provision infrastructure, access production systems, or trigger business workflows can create much larger problems if its operating environment is poorly constrained.
The challenge is not choosing between smarter models and better interfaces. Organisations need both.
This Is Where Platforms Shine
One of the primary responsibilities of a platform is to hide unnecessary complexity behind a well-defined interface. Developers are not expected to understand every Kubernetes resource, networking policy, security control, or operational workflow required to deliver a service. Instead, they interact with a higher-level abstraction that captures intent.
A developer requests a database.
The platform determines how that database should be provisioned.
A developer requests an application environment.
The platform determines how networking, observability, security, and deployment workflows should be configured.
These abstractions are valuable because they reduce cognitive load for humans. They become even more valuable when the consumer is an AI system.
A well-designed platform reduces the operational possibility space. It narrows the range of actions that can be taken, guides consumers towards approved patterns, and encodes organisational knowledge directly into the interface.
Humans can navigate ambiguity surprisingly well. We know who to ask when documentation is unclear. We learn organisational norms through experience. We absorb culture and unwritten rules. AI systems do not.
If a boundary matters, it needs to be encoded in the interface itself.
This is where platform contracts become so important. They provide a constrained and discoverable operating surface that shrinks the operational possibility space, making correct behaviour easier and incorrect behaviour harder.
Seen through an AI lens, platforms are more than developer productivity tools. They become governance systems. They define the boundaries within which autonomous systems can safely operate and ensure that organisational standards are enforced regardless of whether the consumer is a human developer or an AI agent.
A Simple Experiment: Raw K8s versus Kratix
To explore this idea in practice, Shane conducted a small experiment. Two AI agents were given exactly the same task: provision a production PostgreSQL database for a payments team. The agents used the same underlying model and received the same prompt. The only difference was the interface available to them.
The first agent was given direct access to Kubernetes resources through standard tooling. The second agent was given access to a Kratix Promise, allowing it to consume PostgreSQL as a platform capability.
Both agents successfully provisioned a working database. At first glance, this might suggest there was little difference between the approaches.
However, the interesting question was never whether the database would run. Modern AI systems are increasingly capable of generating functional infrastructure configurations. The more important question was whether the resulting implementation aligned with the standards we expect from a mature platform.
When Shane evaluated the outputs against criteria such as API-first design, discoverability, declarative workflows, idempotency, observability, upgradeability, and governance, the differences became clear.
The Kubernetes-focused agent successfully assembled the necessary resources, but much of the operational knowledge remained implicit. Labels were inconsistent, network policies were absent, and some platform conventions that would normally support discoverability and governance were missing. Re-running the process could also produce different implementations as the agent made different infrastructure decisions.
By contrast, the Promise-based approach inherited these concerns automatically. The agent did not need to understand how networking should be configured, which operational metadata should be applied, or how lifecycle management was handled. Those decisions had already been encoded into the platform capability.
Both agents created a database. Only one created a database that a platform team would be comfortable operating over the long term.
Humans Can Ask Jenny. AI Needs an API
Perhaps the most thought-provoking part of Shane's presentation was that these lessons extend far beyond infrastructure.
Platform teams are not the only producers of capabilities within an organisation. Data teams, identity teams, payments teams, security teams, and developer experience teams all expose services that others consume.
Historically, many of these interactions have relied on informal knowledge sharing. People know who to contact. They understand which Slack channels to use. They learn organisational conventions through experience.
Humans are remarkably effective at navigating these social systems. AI systems are not.
One of Shane's observations that resonated strongly with the audience was:
"Humans can ask Jenny. AI needs an API."
As organisations adopt AI more broadly, producer-consumer relationships that have historically relied on culture and tribal knowledge will increasingly require explicit contracts. Those contracts may take the form of APIs, workflows, service definitions, platform capabilities, or other abstractions. The specific implementation matters less than the outcome.
Consumers, whether human or AI, need clear and reliable interfaces.
Building for an AI-Native Future
The rise of AI does not diminish the value of platform engineering. If anything, it reinforces many of the principles that platform teams have been advocating for years.
Platforms exist to transform complexity into consumable services. They create boundaries, establish contracts, and encode organisational knowledge into repeatable workflows. As AI becomes another consumer of internal capabilities, these characteristics become even more important.
The organisations that successfully adopt AI will not necessarily be the ones with access to the most advanced models. They will be the organisations that provide those models with well-designed operating environments. They will reduce ambiguity, expose clear contracts, and ensure that governance and operational best practices are built directly into the interfaces being consumed.
For years, platform teams have been designing systems that make the right thing easy and the wrong thing difficult. AI does not change that objective. It simply makes it more important.
The future of AI is not about giving models unrestricted access to infrastructure and hoping they behave responsibly. It is about combining the flexibility of AI with intelligent boundaries. The organisations that succeed will not just have intelligent models. They will have intelligent interfaces to their platform.
This is the direction behind Syntasso Kratix Agentic (SKA): giving AI systems safe, structured interfaces to infrastructure through platform-defined capabilities and workflows.
With SKA, platform teams can define reusable capabilities once and expose them consistently across the organisation. Humans and AI systems consume the same abstractions, workflows, and operational guardrails, allowing teams to move faster without sacrificing reliability or governance.
Learn more!
Comments