Is this the future of AI platform engineering?

This one’s a hypothesis, or a rant. I’m not sure yet.

Platform engineering has always had one trick: make the hard parts invisible. A good paved road let an app team ship without thinking about clusters, networks, certificates or identity. They didn’t need to understand any of it. They followed the road and the right things happened underneath.

My hypothesis: AI platform engineering is that trick applied to the whole business. That’s how a business transforms with AI: not by teaching everyone the technology, but by giving them a road where they can see what it does and what it changed.

The talent test

So let’s take an idea, right? Someone in talent has one: an agent that pulls together interview feedback, chases the interviewers who haven’t written theirs, and drafts a summary for the hiring manager.

Today, getting that built means answering questions they’ve never had to think about. Who is the agent acting as? Which systems can it read? Can it see candidates from other regions? Where does the candidate data go, which model sees it, and who signs that off?

That’s identity, data access, privacy and model governance, and none of it is their job. So one of four things happens. They give up. They raise a ticket and wait six months. They create a skill, bug IT for connector permissions, and never show anyone else. Or they build it in secret with whatever tool they can get hold of, and nobody answers those questions at all.

On a paved road, they bring the idea and the road brings the rest. Identity is inherited from the talent team. The agent can only read the systems talent already uses. Candidate data stays where the rules say it stays. They never need to know what identity is.

That’s the test I’d put any AI platform through. Can someone in talent develop an idea without having to be aware of identity?

Do you need a platform at all?

Which raises the obvious question. Will a business succeed with AI without an advanced platform? Maybe.

You can get a long way using AI natively. Chat assistants, copilots built into the tools you already pay for, agents switched on inside your HR or CRM suite. No platform team, no road, and for one person or one team it’s often the right answer.

The trouble starts when it needs to scale. Natively, every tool brings its own identity model, its own data access, its own idea of guardrails and its own logs. The feedback chaser built inside the HR suite works fine, until it needs the calendar, the applicant tracking system and the team chat. Then someone has to answer the identity question across three vendors, and that someone is an engineer.

AI used natively works. Making it scale takes engineering effort. So the real question isn’t platform or no platform. It’s whether you pay for that effort once, in a road everyone uses, or every time, one idea at a time.

My guess: you can start without a platform. I doubt you can transform without one.

Comprehension isn’t the point

Now go back to the person in talent. Identity, connector permissions, where candidate data lives, which model sees it: none of that is their problem to solve. They could learn it, but they shouldn’t have to.

There’s a difference between comprehension and understanding.

Comprehension is knowing how it works: single sign-on, scopes, roles, data residency, which model runs where. Understanding is knowing what it does and what it changes: the agent can only see candidates in my region, it chases feedback on day two, and hiring managers now get a summary the same day.

The business doesn’t need comprehension. It needs understanding. Most AI programmes get this backwards. They train everyone on prompts, models and agents, hoping comprehension turns into change. It rarely does.

Platform engineering’s job is to absorb the comprehension and hand back the understanding.

Understanding · what the business sees

The idea

Chase interview feedback and summarise it.

What it does

Reads feedback, nudges interviewers, drafts a summary.

What it can touch

Talent systems, my region, nothing else.

What it changed

Summaries the same day, not next week.

---

The platform

Comprehension · what the platform absorbs

Identity

Inherited from the talent team.

Data access

Scoped to the right systems and region.

Models and tools

Approved, routed and paid for.

Guardrails and evals

Built into the road, not bolted on.

Port took the road itself

So let’s take a look at the real world. Port is the company I keep coming back to, because it lived this journey as a business.

It started as an internal developer portal: a catalogue of services, owners and self-service actions, so engineers could find things and do things without knowing how everything underneath worked. Platform engineering, in a product.

Then it followed what its technology could actually do. A catalogue that knows what exists, who owns it and what it’s allowed to touch turned out to be exactly what agents need too. So Port reshaped itself into an “agentic engineering platform”, a single place where people and agents work together, on the same rules.

What strikes me is that they already had the frame for it: how to rethink things, and how to change themselves. I think AI was the catalyst, but the frame was already there.

From the outside, that’s the journey I think every business is on. Not “learn the technology”, but understand what it does, follow it, and let it change what you are. Port did it to itself. It’s also why I think the catalogue is the most underrated part of any AI platform.

Trust that scales

Port’s shift hangs on the last three words: on the same rules. Open the road to the whole business and that’s what everyone worries about first. Should someone in talent really be building an agent that reads candidate data?

Most organisations answer that the way they always have: with a committee. Someone reads the use case, asks some questions and approves it. It feels safe, and for the first ten ideas it is.

It doesn’t hold at a thousand, and a thousand is roughly where you end up once someone in talent can build without a ticket. The committee becomes the queue, the queue becomes the reason people build in secret, and you’re back where the talent test started. You can’t scale what you don’t trust, and you can’t scale trust one meeting at a time.

The road answers the question differently. Identity, data access and model choices are agreed once and built in. Security stops approving every agent and starts owning the rules every agent runs inside. The talent idea doesn’t go to a committee, because there’s nothing new for the committee to decide.

Trust runs the other way too. The person in talent doesn’t want to be the one who leaked candidate data, and without the road they have no way of knowing whether they will be.

Does the person in talent trust that what they’ve built is secure? On the road, they don’t have to wonder.

Awareness

A road that clears ideas without a committee has a side effect: everyone builds. That’s the point, but it comes at a cost. A thousand ideas on the road soon turns into a dozen versions of the same agent, each one properly governed and none of them aware of the others.

Most organisations already have this problem without a platform. Agents built over a weekend, skills copied between teams, cost calculators nobody knows about. Making building easier only makes it bigger.

So the road has to know what’s on it: what exists, who owns it, what it touches and how it’s doing. Awareness usually gets treated as policing: find the shadow AI and shut it down. On a platform it’s part of understanding. Before the talent team builds their feedback chaser, the road tells them the sales team built something similar for customer calls last quarter, and how it did. They start from something that works, and the business learns from what it’s already paid for.

That’s the catalogue again, and it’s why Port’s starting point matters. A road that knows what everything is can also tell you what everything did.

Receipts

Every idea that goes down the road should come out with a receipt. It’s understanding, written down.

Not a transcript or an audit log. A receipt is short and written for whoever had the idea: what was asked, what it did, what it was allowed to touch, where a person signed off, what it cost, and what it changed.

Work receipt

Interview feedback chaser

Asked

Idea

Chase and summarise feedback

Owner

Head of Talent

Handled by the road

Acting as

Talent team

Can read

ATS, calendar (EMEA)

Candidate data

Stayed in region

Evals passed

31 / 32

Checked

Outcome review

Talent lead, 2 Nov

Cost

Model spend

£12.60 / month

Build time

2 days

Feedback to summary

6 days → same day

Keep this receipt for your records

Receipts are where impact shows up. Most AI dashboards count activity: prompts, active users, hours saved. A pile of receipts counts what changed: time to hire, days to close, customers kept. That’s what a transforming business looks like on paper.

They’re also how trust scales. Security reads the middle. Finance reads the cost. The head of talent reads the bottom line. Nobody needs a meeting first.

And look at who made that happen. The person in talent never learned what identity is, never chased a connector permission, never sat in front of a committee. They brought an idea, and the business now understands what its technology did and what it changed. They created that understanding.

A road the business can follow

The journey has to make sense to someone who’ll never read a line of the platform’s config. It’s the journey from an idea, to what the technology does, to the impact it had.

1. Bring the idea

   Who: Whoever owns the problem

   In their own words. What they want, and how they’ll know it worked.

2. See what exists

   Who: The platform

   Has someone already built this, or something close? Reuse before you build.

3. Let the road handle the rest

   Who: The platformEngineering

   Identity, data access, models and guardrails. Nobody above the line needs the words.

4. See what it does

   Who: The ownerDomain experts

   Try it, review it, and check it does the job. Understanding, not comprehension.

5. See what it changed

   Who: Everyone

   The receipt: what it did, what it cost and what it moved.

6. Take the next idea further

   Who: The business

   Each receipt is the starting point for the next idea. That’s the transformation.

What would prove me wrong

It’s a hypothesis, so it should be able to fail.

• The talent test fails. If people outside engineering still need to know about identity and data access to get anything built, the road isn’t paved, it’s just signposted.
• Native AI is enough. If the AI built into the tools you already use connects up on its own, and the vendors solve identity and data between them, nobody needs a road.
• Understanding doesn’t lead to change. If people can see what the technology does and the business still runs the same way, transformation needed something the platform can’t give.
• The rules don’t fit on the road. If most ideas still end up in front of a committee, it’s the old approval process with a nicer front door.
• Receipts show activity, not impact. If the bottom lines never move, we’ve built a well-governed way of being busy.

Final thought

Platform engineering made infrastructure invisible to app teams, and those teams got faster. Do the same for the whole business, so someone in talent can build an idea without knowing what identity is, and you get more than speed.

You take security and transparency, which used to belong to engineering and a few committees, and hand them to the whole organisation. Security that’s built into the road, so nobody has to be an expert to be safe. Transparency that’s written on every receipt, so anybody can see what was built, what it touched and what it changed. That’s how you get a business that understands what its technology does and can see the impact, idea by idea.

I might be wrong. If you’re building something like this, or you’ve tried and it didn’t stick, I’d love to hear about it.