Band, a company building infrastructure for multi-agent AI systems, addresses the challenge of debugging and observing cross-framework agent-to-agent communication in production environments. The problem arises when multiple AI agents built with different frameworks need to collaborate across distributed systems, creating complex failure modes and difficult-to-trace interactions. Band's solution is an "agentic mesh" that provides a communication substrate similar to chat applications like WhatsApp, where agents can interact dynamically across frameworks like LangChain, CrewAI, and others. The platform captures end-to-end observability including messages, reasoning traces, tool calls, and handoffs between agents, enabling developers to debug complex multi-agent workflows that would otherwise require reconstructing scattered logs and traces. The demonstration showed a billing dispute scenario where customer support, pricing, and collections agents collaborated, with Band capturing all interactions and thoughts to reveal a pricing bug that would have been difficult to trace using traditional single-agent observability tools.
Band is developing infrastructure for multi-agent AI systems with a specific focus on cross-framework agent communication and end-to-end observability. The presentation, delivered by Offer from Band’s developer relations team, addresses a growing production challenge: as organizations move beyond single-agent systems to complex multi-agent architectures, traditional observability approaches designed for individual agents become inadequate for understanding distributed agent interactions.
The core insight driving Band’s approach is that the future of AI systems involves agents built with different frameworks, potentially running in different environments or even across different organizations, needing to communicate and collaborate. The company estimates that approximately 10-20% of developers at the presentation were already planning to ship cross-framework multi-agent systems, indicating this is an emerging but real production concern.
Band identifies several critical limitations in current observability approaches when applied to multi-agent systems. Traditional tools like Arize Phoenix excel at single-agent observability, providing visibility into LLM outputs, token counts, and evaluations within a single agent’s execution context. However, these tools face fundamental challenges when extended to multi-agent scenarios.
The first major issue is what Band calls “clocks lie” - when different agents send traces independently, timestamps may not align correctly, making it difficult or impossible to reconstruct the actual sequence of inter-agent interactions. This temporal misalignment becomes particularly problematic when trying to understand causality in distributed agent systems.
Second, traditional tool traces capture what happens within a single agent’s execution, including individual tool calls, but they miss the crucial handoffs and transitions between agents. When one agent decides to delegate a task to another agent, that decision point and the reasoning behind it often aren’t captured in standard tracing approaches.
Third, Band highlights the “only the survivors” problem - traces typically only capture what successfully completed, missing important context about retries, human-in-the-loop approvals, or alternative paths that were attempted but didn’t make it into the final execution. This creates blind spots when debugging production issues.
The presentation references a UC Berkeley study called MAST that analyzed 200 traces across seven different agent frameworks, revealing consistently high failure rates across various categories including system design issues, agent calibration misalignment, and task verification problems. These diverse failure modes underscore why robust observability becomes critical in production multi-agent systems.
Band’s solution is what they call an “agentic mesh” - a communication substrate that enables agents to interact similarly to how humans use chat applications. The architecture supports at least 11 different agent frameworks including LangChain, CrewAI, and others, taking a deliberately framework-agnostic approach based on the belief that organizations will inevitably use heterogeneous tooling.
The communication model is designed around chat rooms where agents can dynamically mention and tag other agents, similar to Discord or WhatsApp. This provides a flexible orchestration mechanism that doesn’t require rigid predefined workflows. Agents can behave dynamically and participate in conversations as needed, rather than following fixed choreography.
Critically, because Band sits as infrastructure between the agents, it can capture comprehensive observability data that would be impossible to reconstruct from individual agent traces. The platform collects what Band describes as the necessary “atoms” for multi-agent observability: messages between agents, the reasoning or “thoughts” that led to agent decisions, tool calls and their results, tasks and errors, and the handoff points where control transfers between agents.
This positioning as communication infrastructure rather than just an observability layer gives Band unique visibility into the full agent interaction graph. Rather than requiring developers to correlate scattered logs across different systems, Band provides a unified view because all inter-agent communication flows through its mesh.
The presentation included a live demonstration of a billing dispute scenario involving three agents: a customer support agent, a pricing agent, and a collections agent. The scenario involved a customer claiming they had a negotiated cap of 50,000 dollars monthly but were charged 75,000 dollars.
In the demonstration, the customer support agent received the initial request and dynamically invited the pricing agent into the conversation room. The pricing agent then brought in the collections agent as needed. Throughout this interaction, Band captured not just the messages exchanged but also each agent’s reasoning - the internal thoughts explaining why particular decisions were made.
The scenario was deliberately designed to contain a bug where the final resolution incorrectly referenced 71,000 dollars instead of properly applying the 50,000 dollar negotiated cap. This error might have resulted from an agent not receiving updated information or making an incorrect tool call.
The critical capability Band demonstrated was the ability to trace through the entire multi-agent workflow step-by-step to identify where the error occurred. Rather than examining separate trace logs from three different agents and attempting to reconstruct what happened, developers can see the unified conversation flow with full context about each agent’s reasoning and actions.
Band’s interface allows developers to toggle visibility of different elements - the demonstration showed options to view or hide agent thoughts, tool calls, and tool results. This graduated disclosure helps manage complexity while ensuring all relevant debugging information remains accessible.
While Band presents a compelling vision for multi-agent observability, several considerations warrant balanced assessment. The presentation is clearly positioned as a product pitch, and the dramatic 3 AM debugging scenario, while relatable, is used rhetorically rather than backed by specific customer case studies or quantitative impact data.
The approach of positioning infrastructure as a communication layer between agents is architecturally sound and does solve real observability problems. However, it also introduces a critical dependency - all inter-agent communication must flow through Band’s infrastructure. This creates both a single point of failure and potential performance bottleneck that organizations would need to evaluate carefully for production deployments.
The framework-agnostic positioning is valuable given the fragmented agent framework landscape, but the presentation doesn’t address how Band handles semantic differences between frameworks. Different frameworks have varying concepts of what constitutes a tool, a thought, or a handoff, and the translation layer required to normalize these across 11+ frameworks likely introduces complexity that wasn’t discussed.
The chat room metaphor is intuitive and the comparison to WhatsApp makes the concept accessible, but it’s unclear how this model handles more complex orchestration patterns. Many production multi-agent systems require sophisticated control flow including parallel execution, conditional branching based on agent outputs, or hierarchical delegation patterns that may not map cleanly to a chat room model.
The observability capabilities demonstrated are genuinely useful - capturing thoughts and reasoning alongside messages provides debugging context that would indeed be difficult to reconstruct from separate traces. However, the presentation doesn’t address data volume challenges. Comprehensive tracing of thoughts, messages, tool calls, and reasoning for complex multi-agent systems could generate substantial observability data, raising questions about storage, query performance, and cost at scale.
The Berkeley MAST study cited for failure rates is legitimate research, but it’s worth noting it examined experimental systems rather than production deployments, and failure rates in controlled research settings may differ from what organizations experience with mature, well-engineered production systems.
From an LLMOps maturity perspective, Band is addressing a genuine gap for organizations operating at the frontier of multi-agent deployment. However, the relatively small show-of-hands response about cross-framework multi-agent systems suggests this remains a specialized rather than mainstream production challenge. Organizations still working on single-agent reliability and evaluation may not yet need this level of sophisticated multi-agent observability.
The technical integration model appears straightforward - agents built in supported frameworks connect to Band’s platform and communicate through its mesh rather than implementing point-to-point integration. This suggests Band provides SDKs or adapters for each supported framework that handle the translation between framework-native concepts and Band’s communication protocol.
The platform’s ability to capture tool calls and results suggests deep integration with agent frameworks’ execution models, not just message passing. This level of instrumentation is necessary for comprehensive observability but also means Band must maintain compatibility as each framework evolves.
The dynamic agent discovery model where agents can invite other agents into conversations implies some form of agent registry or directory service. The presentation mentions agents “exist on a platform” and can be discovered for particular tasks, suggesting Band provides not just communication infrastructure but also service discovery capabilities.
The demonstration showed real-time updates as agents processed requests and made decisions, indicating Band provides streaming observability rather than batch processing of traces. This is important for production debugging scenarios where developers need immediate visibility into ongoing agent interactions.
The presentation positions Band for several deployment patterns. The most straightforward is internal multi-agent systems where a single organization builds multiple specialized agents that need to collaborate. The billing scenario demonstrated fits this pattern, with customer support, pricing, and collections agents all belonging to the same organization.
More ambitiously, Band envisions enabling cross-organizational agent communication where agents from different companies could interact through the mesh. This raises significant security, authorization, and data governance questions that weren’t addressed in the presentation. Cross-organizational agent communication would require sophisticated access control, audit logging, and potentially regulatory compliance features.
The framework-agnostic approach enables what might be called “polyglot agent systems” where different teams within an organization can choose their preferred agent framework while still participating in shared workflows. This could reduce organizational friction around framework standardization while maintaining interoperability.
The observability data Band captures includes several distinct types of information. Messages represent the explicit communication between agents and potentially humans. Thoughts or reasoning capture the internal decision-making process of agents before they take actions or send messages. Tool calls and results represent agent interactions with external systems or APIs. Task definitions describe what agents are trying to accomplish. Errors capture failures at various points in the workflow.
This multi-layered observability enables several debugging workflows. Post-hoc debugging of completed workflows allows developers to trace through the entire sequence of agent interactions to identify where errors occurred or why unexpected outcomes resulted. Real-time monitoring enables developers to observe ongoing agent interactions, potentially intervening before failures propagate. Pattern analysis across multiple workflow executions could identify recurring failure modes or inefficiencies.
The presentation emphasized the value of seeing agent reasoning alongside actions, which addresses a common challenge in debugging LLM-based systems. When an agent makes an unexpected decision, understanding its reasoning can reveal whether the problem is prompt engineering, inadequate context, incorrect tool results, or other root causes.
Several important questions remain unaddressed. The presentation doesn’t discuss how Band handles agent authentication and authorization - ensuring that agents can only access conversations and invoke other agents they’re permitted to. For production deployments, especially those handling sensitive data, this security layer would be critical.
The scalability characteristics of the platform weren’t discussed. As the number of agents, concurrent conversations, and message volume grows, how does Band’s infrastructure scale? Are there limits on conversation size, message throughput, or agent count that organizations need to plan for?
The pricing model and commercial terms weren’t mentioned, making it difficult to assess the total cost of ownership for production deployments. Observability infrastructure often has costs that scale with data volume, which could become significant for high-throughput multi-agent systems.
Integration with existing observability and monitoring stacks also wasn’t covered. Organizations typically have established tools for logging, metrics, and tracing. Whether Band integrates with these systems or requires adopting a separate observability stack affects adoption feasibility.
The relationship between Band’s observability capabilities and agent evaluation frameworks is an interesting area. Tools like Arize Phoenix mentioned in the presentation offer evaluation capabilities for assessing agent performance. Whether Band provides complementary evaluation features or focuses purely on observability affects its positioning in the LLMOps toolchain.
Finally, the presentation doesn’t address how Band handles long-running or asynchronous agent workflows. The billing scenario appeared to complete in near real-time, but production multi-agent systems often involve workflows that span hours or days with periods of waiting for external events or human approvals. How Band represents and makes observable these temporal complexities would be important for many use cases.
This comprehensive case study examines how multiple enterprises (Autodesk, KPMG, Canva, and Lightspeed) are deploying AI agents in production to transform their go-to-market operations. The companies faced challenges around scaling AI from proof-of-concept to production, managing agent quality and accuracy, and driving adoption across diverse teams. Using the Relevance AI platform, these organizations built multi-agent systems for use cases including personalized marketing automation, customer outreach, account research, data enrichment, and sales enablement. Results include significant time savings (tasks taking hours reduced to minutes), improved pipeline generation, increased engagement rates, faster customer onboarding, and the successful scaling of AI agents across multiple departments while maintaining data security and compliance standards.
AI practitioners Aishwarya Raanti and Kiti Bottom, who have collectively supported over 50 AI product deployments across major tech companies and enterprises, present their framework for successfully building AI products in production. They identify that building AI products differs fundamentally from traditional software due to non-determinism on both input and output sides, and the agency-control tradeoff inherent in autonomous systems. Their solution involves a phased approach called Continuous Calibration Continuous Development (CCCD), which recommends starting with high human control and low AI agency, then gradually increasing autonomy as trust is built through behavior calibration. This iterative methodology, combined with a balanced approach to evaluation metrics and production monitoring, has helped companies avoid common pitfalls like premature full automation, inadequate reliability, and user trust erosion.
Otto, founded by Suli Omar, addresses the challenge of making AI agents accessible to non-technical users by embedding agent workflows directly into spreadsheet interfaces. The company transforms unstructured data processing tasks into spreadsheet-based workflows where each cell acts as an autonomous agent capable of executing tasks, waiting for dependencies, and outputting structured results. By leveraging the familiar spreadsheet UX instead of traditional chatbot interfaces, Otto enables finance teams, accountants, and other business users to harness agent capabilities without requiring technical expertise. The solution involves sophisticated model selection across three tiers (workhorse, middle-tier, and heavy reasoning models) to optimize cost and performance, continuous evaluation through customer usage patterns, and iterative model testing to maintain service quality as new LLM capabilities emerge.
