AgentCore's Multi-Agent Collaboration Is a Shared /tmp Directory

Amazon's new runtime instances let agents work together for up to 14 days. The handoff protocol is a folder. The security page explains why that matters more than the 14 days does.

In the launch demo for Amazon Bedrock AgentCore runtime instances, a writer agent generates some Python and a reviewer agent critiques it. The two agents never send each other a message. There is no queue, no A2A envelope, no handoff schema, no orchestrator relaying results. The writer saves a file to /tmp/agentcore-session/ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2/code.py. The reviewer opens it.

That path is the entire collaboration protocol. AWS says so plainly: "The two agents never exchanged messages or called each other's APIs. They collaborated through the shared file system that runtime instances provide within a session." (AWS News Blog)

Every headline about the August 6 launch led with 14 days. Sessions used to cap at 8 hours on microVMs, now they run for two weeks, and that is a real change for anyone whose agent rebuilds its whole world on every invocation. But the sentence worth reading twice is on a different page, and it is the one that tells you what you just bought.

The position: a filesystem is a fine coordination primitive and a terrible trust boundary

I like this design. Shared state through a mounted directory is how Unix processes have cooperated for fifty years, and it beats inventing a message format for two agents that live three inches apart. It is fast, it is legible, and you can ls it when something goes wrong. Compared to the agent-to-agent protocols currently being drafted in public, a folder is refreshingly boring.

The problem is that a folder is also an authorization surface, and most teams will read "multi-agent collaboration" as a feature bullet rather than as a statement about who trusts whom. AWS wrote the caveat down. It is in the security documentation, several clicks past the launch post, and it deserves to be quoted in full.

What the security page actually says

Three passages from the AgentCore Instances security model do more work than the entire announcement.

The first is a bullet whose bolded label is already the answer: "Agents on an instance are not isolated from each other." The body follows: "Multiple agents can run on the same instance and share its filesystem. Agents run on the instance either in containers or, for directly deployed agents, as processes directly on the instance, neither provides a security boundary between workloads on the same instance. All agents that share an instance must be mutually trusted." (AWS documentation)

Containers are not a boundary here. AWS is not being coy about it.

The second concerns credentials. Each agent gets its own IAM execution role, which sounds like the isolation you were hoping for, and then the docs add: "Any code running on the instance can read the credentials available to it." Two agents on one instance means two credential sets in reach of whichever one goes off the rails first. If your reviewer agent has read-only access and your deploy agent can push to production, co-locating them collapses that distinction to whichever role is more permissive.

The third is about session routing. You pass a runtimeSessionId on every invocation, and AgentCore "validates the format of that session ID but does not verify that it belongs to the calling identity." Authorization happens against the runtime ARN, not the session. AWS then repeats the point in an Important callout, which is the version worth pinning above your architecture diagram: "In deployments where a single IAM principal invokes on behalf of multiple end users, the platform does not enforce that a sessionId belongs to the calling user. You are responsible for ensuring your backend passes the correct sessionId per user." In plain terms, if one backend role invokes for many users and you do not bind sessions to users yourself, an authenticated user who obtains someone else's session ID can route a request straight into that person's session.

None of this is a vulnerability. It is a documented shared-responsibility line, drawn clearly, on a page that ships with the product. The failure mode is not AWS hiding something. The failure mode is a team reading "agents can collaborate on the same task" and staffing that session with agents that should never have shared a machine.

How the pieces fit

The mechanism is worth understanding before you wire anything up, because a few of the choices are permanent.

A capacity provider is the template: operating system, allowed instance types, VPC and subnets, storage volumes, and the IAM roles used to launch and reach the instances. Once created, only its description can be edited. Changing anything else means duplicating it and starting over. Deleting it stops and deletes every associated session along with that session's persistent storage.

A session is one EC2 instance, mapped 1:1 to the combination of capacity provider plus session ID. This is the isolation unit. The same session ID under two different capacity providers points at two different machines.

An agent is a workload inside a session, and this is the 1:N part. Invoke two runtimes that share a capacity provider with the same runtimeSessionId and both agents land on the same box, sharing a filesystem. That is the whole trick. Collaboration is a side effect of colocation.

The instances are EC2 managed instances running in your own account, which means your CloudTrail, your VPC Flow Logs, your service control policies, and your Savings Plans all apply. It also means they are hidden from your EC2 console views and API list operations by default, while remaining fully operational and billable. There is a managed resource visibility setting that turns them back on. Turn it on.

When a session hits the 14-day ceiling, AgentCore stops it, terminates the instance, and keeps the EBS volumes. Invoke again with the same session ID and you get a fresh instance with the old volumes re-attached, possibly on a newer machine image with the latest patches. Deleting the session deprovisions everything.

Put this into practice

If you want to try this today, the smallest useful path is about thirty minutes, and most of it is IAM.

1. Create a capacity provider in the AgentCore console. Pick the OS, one allowed instance type (the AWS demo used c7g.2xlarge, 8 vCPU and 16 GiB), your VPC and subnets, and let the console create the infrastructure role. Check every field before you submit, because only the description stays editable.
2. Scope the infrastructure role with IAM conditions before you use it for anything real. That role is what lets AgentCore launch compute in your account, and the docs tell you to scope it "to specific VPCs, subnets, or instance types."
3. Create a runtime, choose Instances as the compute type, and attach the capacity provider. The docs are blunt here: "You can't change the compute type after a runtime is created." Package your agent as a zip with an @app.entrypoint function, or bring a container image. The launch post lists Python 3.11 through 3.14.
4. Decide your session boundary before your second agent. Write down which agents are mutually trusted enough to share a filesystem and credentials. Anything that fails that test gets its own session, which is a separate instance and a separate bill.
5. Derive runtimeSessionId server-side from the authenticated user. Never accept it from client input. If you can afford per-user or per-tenant IAM principals, use them, because then IAM enforces session scoping instead of your application code.
6. Turn on the cross-principal alarm. CloudTrail records both the calling principal and the target sessionId in the same InvokeAgentRuntime event. A principal routing into a session another principal created is the signal you want paged on.
7. Mount an EBS volume through the capacity provider if the work needs to survive a stop. Workspace files, caches, and checkpoints persist across restarts that way.

Step 4 is the one people will skip, and it is the one that determines whether any of the rest matters.

Honest limitations

The 14-day number is a ceiling, not a promise of continuity. Your session gets stopped at day 14 whether or not the work is finished, and resuming means a new instance and a cold start.

Persistent compute is a persistent bill. The instances run in your account at standard EC2 pricing plus an AgentCore management fee that AWS has not published a rate card for in the launch post. Idle stop and restart is offered as a cost lever, but wiring the policy that decides when to stop is on you.

Availability is narrow at launch: US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland). The compute comparison table lists networking as VPC for Instances against "PUBLIC or VPC" for microVMs, so plan on a VPC.

Accelerator support is real but bounded. Eight NVIDIA GPU families are listed (g4dn, g5, g6, g6e, gr6, g6f, gr6f, g7e), plus inf2, which is Inferentia2 rather than a GPU. Ask for an unsupported accelerator type and CreateCapacityProvider fails with a ValidationException. Ordinary non-accelerator instance types are unaffected, which is why the c7g.2xlarge in step 1 works fine. Every agent on an instance shares its GPUs, which is the colocation tradeoff again in a different costume.

One exception in the security model is easy to miss. The AgentCore service-linked role used to delete and clean up resources "is not restricted by SCPs," which the docs describe as "consistent with how AWS treats service-linked roles generally." True, and still an asterisk on "your account controls apply."

And the first invocation of any new session includes instance provisioning, so it is slow. This is not the compute type for a chatbot.

What I would watch

The interesting question is not whether a shared directory is a good handoff mechanism. It is whether "mutually trusted agents" survives contact with production, because that phrase assumes a team can tell you today which of its agents trust each other, and most cannot. The org chart for agents does not exist yet. AWS just shipped infrastructure that requires one.

If you are deploying this, the artifact worth writing is not a diagram of your agent topology. It is a one-page list of which agents may share a filesystem and why, reviewed by whoever owns the most permissive IAM role in the group. Write that before you write the capacity provider.

Sources: AWS News Blog, August 6, 2026; AgentCore Instances developer guide; Security model and permissions for Runtime Instances.