When building autonomous modernization agents capable of re-architecting enterprise applications, parsing massive codebases, and translating legacy patterns into modern frameworks, execution time isn't measured in seconds—it's measured in hours.
While cloud-managed execution environments provide scalable, isolated runtimes for AI workloads, they introduce a distinct infrastructure challenge: aggressive session and idle timeouts. If an agent execution appears inactive from an external HTTP perspective, the host platform assumes the request is abandoned and silences the container process.
Here is a look at what our modernization agents handle under the hood, how we isolated a silent 25-minute execution limit, and how we engineered an architectural workaround to keep multi-hour modernization workflows running smoothly.
Modernizing complex software applications isn't a single prompt-and-response task. Our modernization agents execute asynchronous, deeply iterative workflows that typically take anywhere from 2 to 12 hours depending on code complexity:
When a modernization agent execution gets abruptly severed halfway through an 8-hour refactoring job, the impact isn't just a dropped connection—it leads to lost execution state, incomplete transformations, and uninformative session statuses.
During testing on hosted container infrastructure, we noticed that our modernization agents consistently stopped outputting telemetry after approximately 25 to 30 minutes.
The most challenging aspect was the complete absence of failure signals. There was no application exception, no platform error message, no container termination log, and no cancellation event. The agent was actively crunching code in background threads, and then—at exactly minute 25—it simply went dark.
To isolate the root cause, we ran four controlled experiments within a simplified test container:
The diagnostic results were conclusive: the platform runtime was dropping tasks based on request or session inactivity, regardless of how hard the internal container CPU was working.
To ensure our modernization agents remain completely stable during multi-hour jobs without requiring manual intervention, we designed a self-sustaining Agent Lifecycle Standard built on three technical pillars.
[ Client Trigger ] ──( Modernization Request )──> [ Hosted Agent Container ]
│
┌─────────────────── ( HTTP 202 Accepted ) ────────┤ ( Background Async Task )
│ │
v v
[ Client UI / CLI ] [ Main Modernization Workload ]
│
├──( Runs Code Transformations )
│
└──[ Parallel Yield / Heartbeat Task ]
│
└──( Every 5 Mins )──> [ Internal Health Ping ]
( Maintains Active Session )
Instead of holding a single HTTP connection open for 10 hours—which client interfaces and gateways cannot sustain—our agent immediately returns an HTTP 202 Accepted response with the Session ID to the caller.
In parallel with the main modernization workload, the container launches a lightweight background process known as the Yield Task. Every 5 minutes, this heartbeat process sends a lightweight health request ({"task": "health"}) back to its own session endpoint using internal environment metadata. Returning an HTTP 200 OK signals active session utilization to the host platform, keeping the container alive through 3-hour, 8-hour, and 12-hour continuous runs.
Because long-running modernization agents rely heavily on persistent session endpoints, transient retries can inadvertently spawn duplicate jobs. We enforced strict idempotency: if an agent receives a modernization request for a Session ID that is already actively processing, it gracefully attaches to and monitors the active background worker rather than initiating a competing transformation pipeline.
Forcefully tearing down hosted containers directly can cause host platforms to treat the event as an unexpected crash, triggering an immediate resurrection loop.
Our standard exposes an explicit /cancel endpoint that passes a cancellation token directly to the execution loop. When triggered (or when the main modernization task naturally finishes), the agent immediately shuts down its internal heartbeat thread. With the heartbeat stopped, CPU activity drops to zero, allowing the host infrastructure to naturally, safely, and cleanly de-provision the container idle resources without triggering automatic restarts.
It is important to note that Microsoft AI Foundry is actively working on platform-native capabilities for long-running workloads within Hosted Agents. Features designed specifically for background orchestration, native polling, and infrastructure-managed session persistence will eventually eliminate the need for custom keep-alive mechanisms altogether.
Until those platform features are natively rolled out, our self-sustaining heartbeat and lifecycle framework serve as our robust, operational bridge solution. It guarantees production-grade reliability, cost control, and uninterrupted multi-hour code transformations for our modernization agents today, while keeping our agent code abstract enough to seamlessly transition to Microsoft Foundry's native long-running agent capabilities in the future.