Multi-Agent Collaboration on a Shared Canvas

This post was co-written with Staff Software Engineer Martin Holman.

Honeycomb Canvas is a collaborative investigation environment. When something goes wrong in production, multiple engineers might join the same Canvas to debug it together. Each person has their own AI agent, so they can pursue their own conversation thread and line of inquiry.

This creates an opportunity for coordination. If multiple agents are working on the same investigation, can we harness their independent capabilities against a common goal? The standard reply in the agentic era is to use subagents. However, the underlying problem is not just one of awareness and cooperation, but also independence.

Each user has a different mental model, different experience with the system, and potentially a different hunch about what's going wrong. Alice might want to start with the deployment timeline, while Bob might believe the issue lies in database connection availability. Forcing them into the same conversation thread means they're competing for the agent's attention and constraining each other's investigations. To avoid this, they could each have their own investigations, but then we've lost something special and powerful: collaboration.

With Canvas, we built something new: independence with awareness. Each agent operates autonomously, with its own conversation, tools, and reasoning. At the same time, agents can see what their peers are doing so they can build on each other's findings. Canvas essentially allows engineers to share a whiteboard with their agents. This post describes the architecture that made this possible.

Establishing a shared context

In part 1, we talked about how AWS AgentCore provisions isolated microVMs for each new session.

A Runtime session is AWS AgentCore's concept. This session maps to an execution environment with its own memory, process space, and network, which enables a multitenant architecture with tenant isolation by default. The standard approach in AWS AgentCore is to model each Runtime session as a unique agent session. With Canvas, we went in a different direction: what if we thought of each Runtime session as multitenant in itself? This model lays the foundation for the low-latency collaboration environment we ultimately built.

We established a 1:1 relationship between investigations and Runtime sessions, not users and Runtime sessions. Agent invocations for a Canvas investigation always route to the same Runtime session, regardless of which user sent them. The only 1:1 relationship that a user participates in is with their agent. The resulting framework allows a single investigation to host multiple agent sessions. Alice's agent and Bob's agent run in the same environment, but they maintain separate LLM session contexts. We'll talk about what this enables next.

The shared coordination context

OK, so we've got multiple agent sessions in a common environment dedicated to a Canvas investigation—but they don't just start magically cooperating. Something needs to connect them, and that's what Canvas's inter-agent collaboration plane does. At the start of each investigation, the collaboration plane is created and accessible to every agent in the investigation. It tracks five key sets of information.

Who's working on what

Agents claim a hypothesis to investigate, like, "Hypothesis: the latency spike correlates with the deployment at 14:32." The claim is a simple, lightweight semaphore: it records which user's agent owns an investigation thread. If another agent tries to pick up the same hypothesis, the claim check notifies that another agent is already on it. This prevents multiple agents from doing identical work in parallel.

What each agent is doing right now

Each agent publishes its current activity, including the hypothesis it is investigating and a short progress narrative. Other agents can query this at any time. When Bob's agent is about to start investigating the database connection pool, it can check if anyone else is already looking at that, and what they’ve found so far. This is different from the claim mechanism, which prevents duplicate work on the same hypothesis. Activity tracking provides situational awareness across different hypotheses. Together, they give agents a lightweight picture of the investigation's overall state.

What's been found

When an agent completes an investigation thread ("Hypothesis invalidated: the latency spike does not correlate with the config deploy; it started 4 minutes earlier"), it records its findings. These findings are available to every other agent in the investigation. This is how agents build on each other's work. Alice's agent rules out the deploy hypothesis and records its reasoning. When Bob asks his agent "What do we know so far?", the agent can reference Alice's findings without re-running the analysis. Negative results are just as valuable as positive ones, because they narrow the search space for everyone.

What peers told their users

Each agent stores the text of its most recent response to its user so other agents can retrieve it. This sounds simple, but it's surprisingly useful. It gives agents conversational context about the investigation without requiring them to share full conversation histories. If Alice's agent told her "I'm seeing elevated error rates on the payment service starting at 14:28," Bob's agent doesn't need to re-query the data. It can reference the peer's summary directly.

Event queues for real-time coordination

Internally, each user's agent has a private notification queue. When something happens that another agent may want to know about, like a new hypothesis, an event is pushed to all other agent queues. The agents check these queues between turns, which gives them situational awareness without polling. This makes coordination feel real-time rather than lazy-loaded. When Alice's agent finishes an investigation, Bob's agent learns about it on the next turn because the notification was already there waiting.

The investigation framework enables two distinct agent collaboration patterns: directed and cooperative investigation.

The canvas itself

At the center of the coordination is the canvas itself: a shared space where humans and agents work alongside each other during an investigation. It can hold a range of shapes—Honeycomb primitives like queries, result tables, and BubbleUp results, alongside markdown, images, and diagrams. These can be arranged as the investigation demands.

This is a deliberate departure from the chat transcript that most agentic systems default to. A transcript is linear and disposable, while investigations have threads of work that branch, evidence that accumulates and can be ruled out, conclusions that sit alongside the supporting data. On the canvas, humans and agents are peers. They read from and write to a single shared surface. Humans react to and build on the agent's output, and the agent does the same with theirs. The surface unlocks what a transcript can’t: layouts that group related findings, semantic meaning shown by where and how things are placed. The most challenging part of this surface is the same thing that makes it powerful: the freedom of a blank space.

Directed and cooperative investigations

Directed investigations

When a user's agent begins investigating multiple hypotheses, it spawns subagents. The subagents are specialized for investigation and run their own conversation. The parent agent is the orchestrator: it decides what to investigate, assigns work to subagents, and synthesizes their results.

This is what we call a directed investigation: a classic hierarchical system. The parent agent sees the full investigation, decides which hypotheses are worth pursuing, and fans out. Each subagent gets a focused brief, like "Investigate whether the latency spike correlates with the config deploy at 14:32. Look at deployment markers, error rates before and after, and affected services." Then the subagent investigates and reports back. Directed investigation works best when one coordinator has a complete picture and can make ideal assignment decisions. It's fast because there's no coordination overhead, and the results roll up cleanly because the orchestrator is the one managing the conversation.

Cooperative investigations

Across users, there is no central orchestrator. When multiple users' agents are working the same investigation, each person and their agent makes their own decisions about what to investigate. But those decisions are informed by the shared coordination context. This is what we call a cooperative investigation. With Canvas's collaboration plane, during an investigation, Alice's agent can see that nobody is investigating the database angle and claim it. Shortly after, Bob's agent sees Alice's claim and picks up a different thread. When Alice's agent finishes, it posts findings and releases the claim. Bob's agent picks up the findings on the next turn and adjusts its own investigation accordingly.

With a cooperative investigation, the results are an emergent product of the collaboration across users and agents. It's messier than a directed investigation. There's no global correctness lock, no centralized control; all the agents make locally rational decisions. But it scales with the number of users, doesn't bottleneck on a single orchestrator, and handles the inherently dynamic nature of human investigation. Real incident debugging doesn't follow a strict plan, because people follow hunches, change direction, get interrupted, and come back around. This is what Canvas was built for.

Insights

Within a single user's scope, we use directed investigations, and across users we leverage a framework for cooperative investigations. Your agent and your colleague's agent coordinate by claiming work, sharing findings, maintaining awareness without either being subordinate to the other. This two-layer model maps naturally to how humans actually investigate together. Each person drives their own line of inquiry (directed), while the collective maintains shared situational awareness as understanding grows (cooperative).

While that setup may be specific to Canvas and our use of AgentCore, the takeaway is important. Multi-agent collaboration doesn't have to be directed; it can be built into the very fabric of interactions. Modeling the natural learning behavior of a group of people solving a problem yields the most powerful investigation framework of all.

Looking ahead: observability is the LLM superpower

When two agents are coordinating work implicitly and the outcome isn't what you expected, you need to be able to reconstruct what happened. Which agent claimed which hypothesis? What did they see?

We instrument every action by the agent with spans containing rich attributes describing the state at the time. Honeycomb's wide event model lets us add as much detail as we need so that when an investigation goes sideways, we can trace the sequence of coordination decisions that led there. This is where the investment in agent observability pays dividends. Multi-agent coordination bugs don't throw exceptions; they just produce suboptimal outcomes. We fight this with observability. Observability powers evals, and evals answer "Given what the agent knew, were its actions, decisions, and conclusion reasonable?"