When an AI coding agent edits a web app, the usual way to check its work is slow: the agent changes files, those files get copied or deployed somewhere, and only then can a person open the result in a browser. Amazon Web Services has added a feature to its Amazon Bedrock AgentCore platform that removes that wait. It lets a developer open a live, running preview of the app the agent is building, watch the agent's steps as they happen, and see the page update without a manual deployment or even a page refresh.

What is new

Amazon Bedrock AgentCore is AWS's platform for building and running AI agents at scale, letting developers pick their own agent framework and foundation model. One part of it, AgentCore runtime, runs each agent session inside its own isolated virtual machine. The new capability, called Session endpoints, gives each of those sessions its own authenticated web address. That address forwards ordinary web traffic -- HTTP requests and WebSocket connections -- to whichever ports inside the session the developer has chosen to expose. In practice, this means a developer can open a browser tab pointed at the app the agent is editing live inside its sandboxed session, rather than at a copy deployed elsewhere.

AWS illustrates this with a sample project: a coding agent that keeps a small website (built with the Vite development tool) running inside its session. A local preview page shows a chat panel on the left and the live website on the right. Typing a request such as 'switch this site to a dark theme' sends the prompt to the agent, which reads and edits the site's files, and the website panel updates in place as soon as the agent saves a changed file -- no refresh needed.

How it works

Setting this up involves a few moving parts. When the runtime is created, the developer specifies which ports inside the session should be reachable from the outside, using a setting called allowedPorts (up to five entries, each a single port or a range between 8000 and 12000). Exposing a port does not start anything by itself; the application inside the session still has to be listening on that port.

Once a session starts, AWS returns a unique Session endpoint URL for it, carried in a response header. Every request made through that URL has to be authenticated -- either with an AWS Identity and Access Management (IAM) signature or a bearer token, depending on how the runtime is configured -- so simply knowing the URL does not grant access. The specific port being targeted is encoded as a prefix in the hostname (for example, 8090--session-id.runtime...), while the browser itself always connects over the standard HTTPS port.

Because a plain browser page cannot attach these authentication signatures on its own, AWS's SDK can run a small 'local endpoint' on the developer's own machine. That local endpoint listens only on localhost, adds the necessary credentials to each request, and forwards them on to the Session endpoint. In the sample, the browser loads the live website through this local endpoint; separately, the developer's prompts travel to the agent through a different, standard call (InvokeAgentRuntime) that AWS already provided before this feature. The agent reports its steps as it works, and when it saves a changed file, the Vite server pushes that change to the browser over a WebSocket connection, relayed through the Session endpoint and the local endpoint.

AWS is careful to distinguish this from the runtime endpoint that AgentCore already offered. A runtime endpoint is the stable address used to invoke an agent and can point at different versions of it, useful for promoting or rolling back code in production. A Session endpoint, by contrast, is tied to one specific running session, lasts only as long as that session, and is meant for inspecting and testing what the agent is doing right now rather than for serving an app to end users.

  • Session endpoints expose chosen ports (1-5 entries, within 8000-12000) from an isolated AgentCore runtime session to the developer's browser or tools
  • Every request must be signed with IAM credentials or carry a bearer token; the endpoint works over HTTP/1.1, HTTP/2 (including server-sent events and gRPC) and WebSocket
  • A local endpoint run by AWS's SDK adds credentials automatically so a plain browser page can connect, listening only on 127.0.0.1
  • The sample agent in the walkthrough uses Claude Haiku 5.5 on Amazon Bedrock to decide what file changes to make
  • Refused requests return clear errors: 403 for a disallowed port or bad credentials, 502 if nothing is listening on an allowed port, 404 if the session no longer exists
  • The feature works with AgentCore's microVM-based runtimes, not the separate Instances compute type, and Session endpoint URLs are reachable only over public HTTPS (no AWS PrivateLink for inbound traffic)

Why it matters

For teams building products with coding agents, the review loop is often the bottleneck. If every small change has to go through a build-and-deploy cycle before anyone can see it, reviewers wait, and agents get less useful feedback per iteration. By letting the running session itself be previewed directly and securely, AWS is trying to collapse that loop to something closer to normal local development, where saving a file and seeing the result take seconds. This is a fairly narrow, developer-facing feature rather than a new model or a new agent capability, but it addresses a practical friction point that shows up whenever agents are used to generate or modify software with a visual or interactive component, such as dashboards or prototypes.

Limits and open questions

The feature does not separate access to the website from access to the agent itself, since both run in the same session; AWS advises giving the agent's execution role only the permissions it actually needs. If the underlying compute for a session is replaced, open connections close and any unsaved edits may be lost unless persistent storage is configured. The agent's file-editing tools in the sample are restricted to a specific folder, so prompts cannot make it alter arbitrary files elsewhere in the session, but AWS notes that if other people can send prompts to a shared agent, developers should consider additional safeguards such as Amazon Bedrock Guardrails and should review agent changes before publishing them. The Session endpoint URL itself is only valid for the lifetime of the session and requires credentials, so it is explicitly described as a tool for building, testing and reviewing -- not for serving a finished app to end users, which still requires deploying to a hosting service.

How to try it

AWS has published a complete sample, including a Jupyter notebook, in the agentcore-samples GitHub repository under the '14-remote-access' or '16-session-endpoints' sample folder (the post references both). Trying it requires an AWS account in a region where AgentCore runtime Session endpoints are available, appropriate IAM permissions, Python 3.10 or later with the bedrock-agentcore and boto3 libraries, Node.js 22 or later, and access to Claude Haiku 5.5 on Amazon Bedrock. The walkthrough deploys the sample agent and website as a zip file to Amazon S3 using direct code deployment for Node.js, so it does not require Docker or a container registry. After deployment, running a short Python script starts a session, opens a local preview on localhost, and lets the developer send prompts to the agent and watch the website update live; a cleanup script at the end removes the runtime, uploaded code and IAM role to avoid ongoing charges.

Sources