AgentCore lets you watch a coding agent’s web app change live in your browser

Amazon Web Services says Amazon Bedrock AgentCore runtime can now give each agent session an authenticated “Session endpoint” URL, so a team can open the web app a coding agent is building and watch each saved file update the page. The details are in an AWS Machine Learning blog post published on October 30.

How a Session endpoint reaches the running app

AgentCore runtime runs each agent session in its own isolated microVM. A Session endpoint forwards HTTP requests and WebSocket connections from your browser to ports inside that session. The point, according to AWS, is to avoid the delay of copying an app out and deploying it elsewhere before each review.

Developers choose the reachable ports with allowedPorts when they call CreateAgentRuntime. The setting takes 1 to 5 entries, each a single port or a range within 8000-12000, excluding reserved platform ports. Allowing a port does not start a server; the app must listen on it, bound to 0.0.0.0. The URL comes back in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header of the InvokeAgentRuntime response. A prefix on the host name picks the port, so 8090--<id> reaches port 8090, while the client always connects on 443.

Authentication applies to every request. A runtime that uses IAM expects a SigV4 signature on each HTTP request, HTTP/2 stream and WebSocket handshake, and the caller needs the bedrock-agentcore:InvokeAgentRuntimeProxy permission. A runtime with a JWT authorizer expects a bearer token instead. Because browsers cannot add those credentials on their own, the bedrock-agentcore SDK can open a local endpoint on the developer’s machine that signs requests and forwards them.

HTTP/1.1, HTTP/2 (including server-sent events and gRPC) and WebSocket traffic all pass through. The URL lasts only as long as the session. AWS says it is meant for building, testing and reviewing agent output, not for serving users; for that it points to a hosting service such as AWS Amplify Hosting.

A sample that turns a coffee site dark

The sample in the agentcore-samples repository runs a coding agent on port 8080 with four file tools: list, read, write and edit. The agent keeps a Vite development server on port 8090, and its hot-reload WebSocket pushes each change to the browser. A local page puts a chat on the left and the site on the right. In AWS’s walkthrough, asking for a dark coffee-house theme changed the page when the agent saved the stylesheet, without a refresh. The agent calls Claude Haiku 5.5 in Amazon Bedrock.

The same endpoint also reached a status route on port 8081. Requests to a port outside the list get 403 AccessDenied, missing credentials get 403 or 401, an allowed port with nothing listening returns 502, and a session that has ended returns 404. Requests are logged in AWS CloudTrail as InvokeAgentRuntimeProxy events.

To follow the sample, AWS lists Python 3.10 or later with bedrock-agentcore 1.25.2 or later, Node.js 22 or later, and model access in Bedrock. It deploys the agent as a zip file in Amazon S3, so Docker and a container registry are not needed. Session endpoints work with microVM runtimes, not the Instances compute type, and are reachable over public HTTPS; PrivateLink is not supported for inbound connections.

A narrow but practical fix for agent review loops

The feature sits next to a runtime endpoint such as DEFAULT, which controls which agent version callers reach. A Session endpoint instead exposes what the agent is running in one session. The security notes matter for teams. The access controls do not separate the website from the agent, since both share a session, so AWS advises giving the execution role only the permissions the agent needs. The local endpoint listens on 127.0.0.1 only and refuses WebSocket connections from other origins. If compute is replaced, open connections close and edits may be lost unless persistent storage is used.

The post does not say which AWS Regions support Session endpoints, beyond requiring one where they are available, and it gives no pricing. Its claims about the workflow are AWS’s own and come from a sample, not an independent test.

Another step in AWS’s agent platform push

The release continues a run of AgentCore updates. On October 28, AWS said the AgentCore CLI reached version 1.0, with faster startup and an agentcore migrate command for moving existing projects. The previous day, as we reported, Step Functions workflows became callable by AI agents as tools through AgentCore Gateway, with no separate charge and support for more than 220 AWS services in that service’s orchestration. Together they show AWS filling in the surrounding tooling – invocation, orchestration, and now inspection – around agents that run on its runtime.

For developers already building on AgentCore, the practical change is that reviewing an agent’s output no longer requires a separate deployment step. Whether it matches the speed of local development tools is untested outside AWS’s demonstration.