A container test can prove that a.NET agent starts, responds and survives a health check. It cannot prove that production session routing and conversation memory will preserve context across requests.
At 4:41 p.m. on Friday, Elena was holding a paper cup of cold coffee beside a release dashboard in a shared workspace in Manchester. Her team’s support agent had passed every container test. Then the final production request arrived and asked, “Can you apply the second option?”
The agent replied: “What second option?”
This is an invented composite, but the failure pattern is plausible. Minutes earlier, the same conversation had produced two account-recovery paths. The latest request reached a healthy container, yet the agent no longer had the state required to interpret it. If Elena’s team could not explain the loss quickly, the release would miss its window and the weekend support rota would keep handling the workflow by hand.
The container was running. The conversation was gone.
A healthy container proves a narrow set of facts
Container checks answer useful questions. Did the image build? Does the process start? Is the expected port available? Can the service return a response? Does it recover after a restart?
Those checks matter, but they describe the runtime unit rather than the complete interaction. An agent conversation can cross several boundaries outside that unit: request routing, session identifiers, memory storage, streaming connections and retries. A green container result says little about whether those pieces agree on which conversation a request belongs to.
Elena’s local test kept one conversation inside one predictable environment. Each message followed the previous one, and the in-memory state remained available. Production introduced conditions the test had hidden. Requests could reach different instances. A retry could repeat part of an exchange. A missing or altered session identifier could make an existing conversation look new.
The agent did not need to crash for the experience to fail. It only needed to forget.
That distinction should shape release criteria. “The service responded” is weaker than “the service responded with the correct state after routing, restart and retry.”
Session ownership becomes a production dependency
AWS.AgentCore.Hosting connects containerized.NET agents to Bedrock AgentCore. In the stated service model, Bedrock AgentCore manages scaling, session routing, health checks, streaming and conversation memory.
That division of responsibility can remove infrastructure work from the application team. It also makes the boundary between application state and managed session state a critical part of the system. Teams need to know which component creates the session identifier, where conversation memory lives, how requests recover it and what happens when an instance changes.
A useful architecture review follows one conversation rather than one container. Start with the first request. Record the session identifier. Trace where memory is written. Send the next request through another instance. Interrupt the stream. Retry it. Restart the application. Then ask a question that only makes sense if an earlier detail survived.
This resembles the broader reliability problem described in why authorizing every step can still break production on Friday. A control can work exactly as designed while the complete workflow still fails at the boundary between components.
For Elena’s team, the decisive clue appeared when they compared the working conversation with the failed one. The agent logic had produced the expected output in both environments. The request path had not preserved the same conversation identity. Once they tested that boundary directly, the green container result stopped looking like release evidence.
Test continuity, interruption and ambiguity
A production-minded agent test needs stateful scenarios with assertions about meaning. A generic prompt such as “Hello” proves almost nothing about memory. Use a sequence where the final turn depends on a specific earlier choice.
For example, tell the agent that a fictional account has two recovery options. Choose the second one. Change the serving instance or restart the process. Then ask it to continue without repeating the choice. The expected result should state what context must survive and what the agent must do if that context is unavailable.
Test the failure response too. An agent that has lost state should avoid guessing what “the second option” means. It should say that the earlier context is unavailable and ask the user to restate the choice. That response is less impressive in a demo, but safer in production.
The same scrutiny applies to retries. If a request is submitted twice, can the agent duplicate an action? If a stream ends midway, does the next attempt resume, restart or create a separate turn? If memory arrives late, will the model answer from incomplete context?
These cases belong beside container startup and health checks in the release plan. They also deserve logs that connect one user-visible conversation across infrastructure events. Without that trail, a lost-memory report becomes a hunt through healthy services.
Make the release gate follow the conversation
At 5:03 p.m., Elena’s team had a smaller but more honest release target. They held the deployment and added a test that moved a conversation across instances while checking the final answer against earlier context. They also defined a safe response for missing state instead of allowing the agent to infer an answer.
The following release would require evidence from the whole conversation path: stable session identity, recoverable memory, controlled retry behavior and an explicit fallback when context disappears.
On Elena’s desk, the container check remained green. Beside it sat a new result that mattered more: after a restart, the agent still knew which recovery option had been chosen.
Comments
No comments yet.