
Why virtual desktop exits turn into packaging projects with unanticipated costs
About kateryna.pavlovska
Configuration drift, change validation and continuous compliance for hybrid estates.
Explore Guardian →Application packaging at scale, from VMs to containers, from desktops to virtual.
VM cost calculator →Run legacy Windows applications on any modern platform, no rewrites, guaranteed.
Explore Alchemy →Continuous compliance and audit-ready evidence for regulated estates.
Explore Guardian →Plan a VMware exit on your timeline, without rewrites or downtime.
Explore Foundry →Run legacy applications on any modern platform, no code changes required.
Explore Alchemy →
This week’s AWS Summit London is built around a single proposition: that organisations can now hand meaningful workflow automation to AI systems with enterprise-grade confidence, with Amazon Bedrock AgentCore as the infrastructure to do it.
Most enterprise estates run hundreds of applications, a significant proportion built before cloud was an architectural consideration, let alone AI agents, and the applications those agents will act on haven’t changed to accommodate them. These are applications with non-standard authentication flows and undocumented dependencies, hardcoded at deployment and untouched since, maintained by people who carry operational knowledge about them that exists nowhere in writing.
An AI agent in an enterprise environment interacts with whatever surfaces are available, whether APIs or UI automation, on assumptions built around how a human would behave.
Anyone who has tried to use an AI agent for automated testing against a legacy application will recognise the pattern: menus that don’t behave consistently, state that persists between sessions in ways the agent doesn’t anticipate. When a session times out mid-task or an auth flow has a non-standard step, the agent either stalls or retries incorrectly, completing with an error state it wasn’t designed to surface clearly.
AgentCore Observability doesn’t tell you that the application the agent just automated has a quirk that causes it to drop records under a specific load pattern, because that quirk exists only in the institutional memory of the person who’s been running it since 2009, not in any documentation.
If an agent inherits a user’s permissions, it can act on everything that user can access, at machine speed, without the human’s contextual judgement about when not to. That risk is receiving attention; the application compatibility problem sitting underneath it is receiving almost none.
When an organisation starts scoping agentic automation, the instinct is to ask which processes are candidates. The more difficult question is which applications are safe to put in scope at all. The demos at an event like this week’s Summit work because the environment was built for them, with clean APIs and applications designed to be interacted with programmatically, which most enterprise estates are not.
An application that’s stable under human operation may be entirely unsuitable for agent interaction, none of which surfaces in a process map until the agent is in production and something fails in a way no one anticipated.
An application’s behaviour also varies with the state of the environment it runs in, and an agent acting on an application whose configuration has shifted from its known baseline isn’t just encountering an old app but an app in an unknown state. The observability tooling AWS provides tells you what the agent did; it doesn’t tell you the environment it acted on had already diverged from anything previously tested.
The process of preparing an application for a new platform surfaces its dependencies and whether its behaviour is stable enough to be predictable, which are exactly the questions that need answering before an application goes into scope for agentic automation. In a migration project, an unstable application fails in a test environment, not in production after the action has already been taken.
Before any application is put in scope for agentic automation, it needs to be assessed against different criteria than “does it have an API.” The two questions that matter most are whether the application’s behaviour is consistent enough to be predictable to an automated actor, and whether its dependencies are documented well enough to anticipate failure modes.
For modern, well-maintained applications, most of this is manageable. For the rest of the estate, and in most large organisations that portion is substantial, the answer should be a hard scope boundary, not an optimistic pilot.
The Summit will be full of organisations being told what agentic AI can do. The question worth asking this week is which of their applications are ready to be on the receiving end of it.
Sign up to attend the AWS Summit here.

About kateryna.pavlovska
About kateryna.pavlovska