June 15, 2026
For years, platform engineering has been treated by many organisations as a “nice-to-have” rather than a necessity for digital teams. Investment in paved roads, guardrails and enterprise-wide frameworks was frequently bypassed in favour of immediate feature delivery or maintenance work.
Organisations relied on manual coordination and the invisible effort of engineers to navigate unstandardised environments, remember patterns and bridge contextual gaps. That was OK for many because humans are remarkably good at adapting and sharing institutional knowledge. They’ll ask a colleague on Slack, search a stale Confluence page, or copy a snippet from a peer’s repository.
But as we transition to the era of AI, we’ve reached the limit of this deferral. An LLM is only as good as the context it is given. If the environment is undocumented, inconsistent, and unpredictable, the AI agent will hallucinate, fail silently, or worse: succeed incorrectly.
Note: This is a blog version of the talk I recently gave at the SlashNEW conference.
In the Equal Experts Digital Platform playbook, we define a digital platform as: a bespoke Platform as a Service (PaaS) product composed of people, processes, and tools, that enables teams to rapidly develop, iterate, and operate Digital Services at scale.
It’s not a small undertaking and requires ongoing funding to realise the greatest benefits. But there is a full cast of people who are impacted and benefit from a digital platform. With paved roads, service catalogs and automated guardrails, it allows organisations to accelerate time to market, increase revenue, reduce costs, and create innovative products for customers.
These same platform capabilities that serve human engineers by alleviating developer toil, reducing cognitive load and standardising processes are the prerequisites for AI agents to function at all.
An AI agent needs to be able to answer three things before it can do anything useful:
In an organisation with a mature platform, these questions are answered by patterns, a service catalog, templates, SDKs, and policy-as-code. It means AI outputs are compliant, observable and supportable.
But most organisations trying to adopt AI today do not have a mature platform. Some are still operating in chaos without standards or guardrails. For any individual team, that may be perfectly reasonable, and the output may solve their specific issue or meet requirements.
But when viewed across all teams in an organisation, the resulting AI output is a blizzard of snowflakes and ultimately causes more headaches. Consumers of your products get radically different experiences depending on the application used, infosec needs to monitor different behaviours to detect breaches, and first-line support has no standard way to analyse performance or uptime… the list goes on.
Even those with a convention-based platform, based on informal standards but without automation or enforcement, will still experience AI outputs that are mostly consistent but frequently wrong.
The immediate reaction to this AI context gap is often to double down on Soft Guardrails and throw more context and instructions into the prompt. Individuals build complex libraries of skills and agents with Markdown files detailing policies, service structure and coding conventions for each engineering scenario.
While this works for a single component, the effectiveness is dubious at scale:
A mature digital platform instead provides hard guardrails that provide a rigid, deterministic path for the AI to follow.
To test this theory, I worked with a colleague on an experiment comparing three approaches to solving a real-world problem. We took a sample requirement – a financial ledger API with balance retrieval, fund transfers, idempotency, and audit logging – and generated it numerous times under each of three conditions.
The results were stark. In the baseline approach and without any context, the AI consistently failed to implement the business requirements correctly, with the outputs completely unusable.
Similarly, the soft approach showed massive variance, with a meaningful percentage of runs non-compliant despite detailed written instructions. Even with the same prompt, the generated code often diverged in structure and quality.
Token costs were also significantly higher. The hard approach, utilising the Platform SDK, was significantly more consistent, and the token cost was drastically lower. With more restrictions, we could use smaller, cheaper models to achieve better results than a high-end model trying to navigate a “soft” environment.
The inclusion of hard guardrails and a platform SDK changed the process from an LLM reasoning about requirements, discovering solutions, and writing a lot of code, to selecting from a menu of pre-approved options. The abstraction the SDK provides allows the agent to focus on the specific task, as opposed to re-implementing controls, architectural patterns, observability, etc. As these requirements are shared by teams across the organisation, hard guardrails ensure these requirements are solved once and are added to the menu for future use by agents.
There is a long-standing principle in UX: Accessible design is good design. When you create something for people with additional needs, it often improves the experience for everyone else using the product or service. The same is true for our platforms. If we build a platform that is structured enough for a non-deterministic AI to navigate safely, we have inherently built a better experience for our human engineers, BAs, architects and more.
We should have built these paved roads years ago to support our people. But now, with AI’s ability to rapidly scale whatever is put in front of it, including mess, we must build them to make AI work effectively. If you want to scale AI in your software delivery lifecycle without creating a mountain of AI-generated technical debt, you need to pave the road before you let the robot drive the car.
Nick Williams is Technology Principal at Equal Experts APAC. With delivery experience across the UK, Europe and Australia, Nick has held a mixture of technology, platform and architect consultancy roles. Across his career, he has led a variety of complex projects, including embedded systems in the warehousing and logistics industry, supporting the design and development of the UK government’s largest data platform and driving technology transformation in finance and superannuation.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.
