The AI Builders Breakfast at AWS Summit London last week gave the event’s central premise a concrete reference point: Fin AI, Intercom’s agent product, has resolved over 40 million customer conversations, with a flywheel model where inference revenue funds compute and compute funds future training.
The day before the Summit, I wrote about the fact that the application layer underneath this infrastructure story was the part nobody was talking about, and nothing at the Summit changed that.
The expo floor was the answer
Every company on the exhibitor floor was positioned around AI, mostly infrastructure. Application readiness was absent as a category, which is consistent with how the infrastructure layer has been moving: maturing quickly while the application estates those agents will act on are not keeping pace.
The Kiro workshop confirmed the same pattern from a different angle. Spec-driven development has become the default approach for AI-assisted engineering in less than six months – but the environments those tools rely on are evolving far more slowly.
As noted ahead of the Summit, demos work because they’re designed to. Clean APIs, controlled environments, and applications built for programmatic interaction create the illusion of readiness. The reality in most enterprise environments is far more complex.
What the infrastructure story doesn’t cover
AgentCore tells you what an agent did: which actions it took, where it succeeded and where it stalled.
What it doesn’t tell you is whether the application the agent acted on had already diverged from anything tested. Or whether a task that appeared successful was actually a partial write – accepted without error, and actioned at machine speed without the judgement a human would apply about when to stop.
Most organisations scoping agentic automation ask which processes are candidates, when the harder question is which applications are safe to put in scope at all. For well-maintained applications with clean APIs and documented dependencies, this is manageable. In most enterprise estates, that’s the minority – the rest need clear scope boundaries before deployment.
The scoping question the Summit didn’t ask
Before the Summit, I argued that any application going into scope for agentic automation should be assessed against two questions: is its behaviour consistent enough to be predictable, and are its dependencies documented well enough to anticipate failure modes. Neither appeared on any stage or expo floor.
The AWS Transform VMware lab made the same point in a different context: discovery of the on-premises estate was the prerequisite for the tooling to work at all. Where firewall configuration hadn’t been captured, Transform couldn’t build the required security groups. The dependency was the same: the tool only operates on what’s been documented, and AgentCore is no different.
The organisations that will get the most from it are the ones who’ve done that assessment before deployment starts; the ones who haven’t will find that observability tells them, in some detail, exactly how things went wrong.
Cloudhouse helps organisations assess and remediate application compatibility challenges before they become deployment or automation blockers. More at cloudhouse.com.
