AWS Bedrock AgentCore for Reliable Multi-User AI Agent Collaboration

How shared memory, isolated sessions, runtime contracts, integration checks, and evidence-first observability turn successful-looking agent runs into trustworthy systems.

Authors: John Ruiz and Luis Dias

The continuity bridge: long-term memory continuity from our previous project, plus harness collaboration continuity from this one.

At 10:46 UTC, the run looked perfect.

Three users walked into one shared channel. The harness took three separate messages, gave each one its own isolated runtime session, and still pointed all three at the same shared memory. Artifacts appeared. The dashboard lit up green, with downloadable HTML, Markdown, and SVG files. There was even an integration step that looked finished. Everyone watching nodded.

At 10:50 UTC, someone asked the question that ruins demos.

“Was the collaboration actually correct or just successful-looking?”

That gap, between green and correct, is the whole difference between an AI demo and a production collaboration system. This article is about how we closed it.

This article is our production experience layering multi-session coordination on top. The full source code is at https://github.com/johnruiz24/agentcore-harness-memory

[embed]GitHub - johnruiz24/agentcore-harness-memory Contribute to johnruiz24/agentcore-harness-memory development by creating an account on GitHub.github.com

Two problems that look like one

In our previous medium article we solved memory continuity: how a user and an agent keep meaning across sessions on AWS Bedrock AgentCore Memory, without restating context every morning. If you remember Sarah the analyst asking her agent to “continue from where we left off yesterday,” that was the problem we were chipping at.

This project is the next question over, and it caught us off guard because it looks like the same thing:

How do independent users send messages through one harness, keep their own isolated runtime sessions, and still collaborate in one shared memory without drifting into each other’s context?

Good memory does not buy you good collaboration. You can have flawless recall and still get multi-user orchestration wrong, because the things that break collaboration live somewhere else entirely: output contracts that are merely implied, validation that’s smeared across the UI and the backend, integration logic that was never modelled as its own step, and traces too thin to tell you what actually happened after the fact.

So we started treating the Harness not as a thin wrapper around “invoke the agent,” but as a control point in its own right.

The core idea: the Harness is the place that coordinates many user messages, many runtime sessions, and one shared channel memory timeline all at once.

The four ways it quietly breaks

We didn’t design this from a feature list. We designed it backwards, from four failures we kept hitting. Each one produces a run that looks fine and is wrong.

1. A prompt is a wish, not a contract

Say user 1 asks for HTML, user 2 for Markdown, and user 3 for “an SVG, integrated into the others.” Polite, clear, reasonable. And completely unenforceable. Prompt wording does not guarantee valid output. We learned to push enforcement down into the runtime: the invoke path takes an expected_format, validates the materialised file against it, and retries with explicit correction if it's wrong. Good prompts help. They are not the contract.

2. Shared memory without actor discipline drifts

Collaboration depends on every user writing into one shared namespace, keyed by channel:

actorId    = channel-<channel_id>
namespace  = /semantic/<actorId>/

Runtime sessions stay independent per user, but memory is shared by channel actor. Skip that discipline and the messages still run. They just stop meaning anything together, and inspecting the memory becomes guesswork.

3. “SVG and integrate” is two steps, not one

This is the one that fooled us most. svg_and_integrate is a collaboration contract, not an output format. The UI maps it to a plain svg generation for the runtime, and then runs a separate integration stage that injects that SVG into the HTML and Markdown artifacts. Collapse those two responsibilities into one implicit step and you get the worst kind of bug: a run marked complete when the integration never actually happened.

4. No evidence means no operations

When a run “succeeds” or “fails,” a team needs evidence, not interpretation. So the harness writes a lot of it: per-attempt traces, a final trace, tool-call snapshots, usage snapshots, the materialised artifacts, the integration outputs, before/after memory snapshots, and a synthesised execution report. Without that, debugging is opinion. With it, debugging is deterministic.

What the harness actually is, in practice

In the abstract, the Bedrock AgentCore Harness is a runtime envelope for invoking agent behaviour with actor and session scoping plus optional memory. In our repository, it’s the message-orchestration layer behind a small local collaboration console.

The shape of it: a local dashboard and Python orchestrator, the AgentCore control and data planes in AWS, and local storage for shared memory and run artifacts.

For every inbound user message, the harness does three things at the same time:

1. binds the message to an isolated runtime session,
2. binds the same execution to a shared channel actor,
3. persists a collaboration trace into shared memory and artifacts.

Four fields carry the whole thing:

• runtimeSessionId— Isolates one user's execution thread from the others.
• actorId— Unifies collaboration context across the channel.
• namespace— Anchors semantic memory writes and retrieval.
• runId— Groups all the evidence from one run together.

When those four stay consistent, the run is inspectable and reproducible. When any of them drift, the run can still go green while being quietly broken which is exactly the 10:46 problem we opened with.

Shared brain, separate hands

The design is deliberately hybrid. One shared memory actor per channel. One independent runtime session per user. One run id tying the artifacts together. That gives you two kinds of isolation in the same breath: semantic continuity is shared (everyone contributes to one timeline), while runtime execution is separated (nobody’s session contaminates anyone else’s).

Three isolated sessions, one shared timeline. Each user writes into the same channel namespace; nobody reads from another user’s runtime state.

This is the direct bridge to the long-term memory work: shared semantic substrate underneath, scoped execution on top, and a harness routing the messages in between. At the end of each invoke, the harness writes a compact record into the shared namespace (user, truncated prompt, truncated response) and the dashboard reads memory snapshots before, between, and after users to build a run-local timeline. The records are intentionally summary-level; the deep forensics live in the traces and artifacts.

The contract that needed its own stage

Of everything here, svg_and_integrate is the piece most worth dwelling on, because it's where "looks done" and "is done" diverge most easily.

Generation and integration are different responsibilities. The runtime produces a validated SVG; a separate stage injects it into HTML and Markdown, and only then is the contract satisfied.

Two stages, on purpose. First, the runtime generates and validates the SVG against the expected format, with bounded retries one to three attempts, each retry carrying an explicit correction instruction rather than a hopeful re-roll. Second, the integration endpoint reads the run’s artifacts, injects the SVG block into the HTML, appends an SVG reference into the Markdown, writes the integrated files, and reports back. The UI only marks integrationValid when both integrated outputs exist. If you'd folded that into the prompt, user 3 would have shown a cheerful green checkmark over an integration that never ran.

Trust the evidence, not the vibes

The dashboard at 127.0.0.1:8787 (example from the shared Github repo) is not decoration. It's an operations console that turns prompt experiments into repeatable runs. It captures the batch config (users, expected formats, prompts, retry caps, region and profile), executes ordered per-user invokes under one shared run id, logs per-user evidence, runs the integration stage when the contract calls for it, and emits a consolidated execution report with the memory timeline attached.

That observability surface is what lets us answer the 10:50 question honestly. The same evidence model also tells us how runs fail, and where to catch each one:

What’s left is mostly the honest stuff you can’t design away: eventual consistency and external dependencies such as credentials, region config, harness availability. We’d rather name those than pretend they’re solved.

Inside the 10:46 run

It helps to walk the actual run that started this whole thing, because the failure was invisible until you looked at the right field. Three users, one channel, one batch:

The harness ran them in order, each on its own runtimeSessionId, all writing to the same channel- actor, all grouped under one runId. Users 1 and 2 were genuinely done with valid files, validated by extension, persisted under the run directory. User 3 generated a perfectly good SVG, and the dashboard happily rendered it.

And that’s the trap. User 3’s generation succeeded. Their integration hadn’t run yet, because integration is a downstream stage, not part of the invoke. A naive console would have read three green statuses and called it a day. Ours waited for integrationValidand integrationValid was still false, because the integrated HTML and integrated Markdown didn't exist on disk. The run wasn't broken so much as incomplete, and the only thing that knew the difference was a contract check looking at artifacts rather than at chat text.

Text-only success interpretation is the single most common way a multi-agent run lies to you.

Once we ran the integration stage, the SVG landed inside both downstream artifacts, the contract flipped to valid, and the timeline in shared memory showed all three contributions against one channel. Then it was correct, not just green.

Reading a run like an operator

The flip side of designing for evidence is that you get a repeatable way to debug, which matters more than any single feature. A few symptoms come up often enough that they’re worth naming, because each maps to a specific place to look rather than a vibe to chase.

None of this requires re-running anything. The traces, the snapshots, and the execution report are already on disk, bound to the run id. That’s the quiet payoff of writing evidence first: the postmortem is just reading, not reproducing.

Why this matters beyond one repo

Stack the two projects and a clean two-layer model falls out.

• Layer A — memory continuity: what survives over time.
• Layer B — collaboration continuity: what survives across users and contracts inside a single run. Layer A gives you better recall. It does nothing to guarantee that three collaborators each produced and integrated what they were supposed to. Layer B is the part that enforces that. You need both.

There are real trade-offs in choosing this. More orchestration steps mean more moving parts to reason about. First-class artifacts mean storage grows run over run. Shared-namespace collaboration means you depend on actor discipline being right. And a local console is great for fast iteration but isn’t the production deployment surface. We think the trade is worth it over the alternative of shipping green runs you can’t actually trust.

What we’d tell our past selves

Three things, really. Push contracts into the runtime, because a prompt is a wish and a validator is a promise. Model integration as its own stage, because the moment “generate” and “combine” share a step, you lose the ability to tell whether the second half happened. And write the evidence first, because the difference between a demo and a system is whether you can answer “was it actually correct?” four minutes after the run, without rerunning it.

The harness didn’t make our agents smarter. It made their collaboration legible and at production scale, legible beats clever every time.

If you’ve shipped multi-user agents, we’d love to hear how you tell “green” apart from “correct.”