BAND Unveils Peer Network to Replace Centralized AI Orchestrators

Is Orchestration the Future? With BAND — Ai4

Ai4

Rigid central orchestrators fail enterprise engineering workflows by turning developers into manual context routers, necessitating autonomous peer-to-peer agent protocols with persistent state hydration.

AI-assisted summary of Is Orchestration the Future? With BAND — original source. Check the original for full context.

Source published: 2026-08-18

Detailed notes

## Background Published on YouTube by Ai4 on August 18, 2026, this session features Arick Goomanovsky, CEO of BAND. According to the page description, the talk traces the evolution of multi-agent systems from standalone LLMs to autonomous distributed networks, examining engineering hurdles like reasoning loops, message ordering, and error recovery under the thesis that the future of communication is AI-to-AI.

## TL;DR Arick Goomanovsky argues that centralized AI orchestration is obsolete and that software development is shifting toward autonomous, peer-to-peer agent collaboration. He illustrates how current workflows reduce software engineers to 'human routers' who waste hours copy-pasting between disconnected tools, while existing protocols like MCP fail to support stateful, multi-party interactions. To address fundamental distributed systems challenges such as message ordering, agent discovery, and state hydration, BAND offers an underlying collaboration layer. The session culminates in Jam, a system that translates transient agent reasoning and terminal chatter into structured, visual Kanban boards aligned with codebase architecture.

## Atmosphere & style The presentation blends playful, lighthearted engagement—such as audience polls about fantasy lore and cat herding—with pragmatic, grounded software engineering analysis. Goomanovsky speaks directly to the developer experience, capturing tangible emotional realities like copy-paste fatigue and background 'cloud anxiety' when autonomous agents run unmonitored. The pacing moves smoothly from high-level architectural philosophy to concrete protocol critiques and live demos, giving viewers the feeling of a focused technical briefing tackling real-world enterprise agent deployment.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=0ev371VOEwU&t=4s) The future of AI architecture is decentralized peer-to-peer collaboration rather than rigid, centralized orchestration. - [01:40](https://www.youtube.com/watch?v=0ev371VOEwU&t=100s) Enterprise AI is shifting from ephemeral, single-prompt bots toward persistent, long-lived autonomous agents capable of running multi-step business processes. - [04:00](https://www.youtube.com/watch?v=0ev371VOEwU&t=240s) Running disconnected adversarial agents forces human engineers into the role of 'human routers' who manually copy-paste context and critique loops between isolated windows. - [06:37](https://www.youtube.com/watch?v=0ev371VOEwU&t=397s) Existing protocols like MCP standardize stateless agent-to-tool RPCs, but fall short of managing multi-turn state, discovery, and dynamic recovery required for peer-to-peer agent networks. - [09:16](https://www.youtube.com/watch?v=0ev371VOEwU&t=556s) Repurposing human messaging platforms for AI creates heavy configuration overhead while keeping agents trapped in digital solitary confinement without direct autonomous communication. - [12:02](https://www.youtube.com/watch?v=0ev371VOEwU&t=722s) Multi-agent systems are fundamentally distributed systems that require strict sequential message delivery to prevent reasoning loops from breaking. - [12:02](https://www.youtube.com/watch?v=0ev371VOEwU&t=722s) Robust agent infrastructure requires message queuing and state hydration to seamlessly restore in-flight tasks and tool outputs when agents crash. - [12:02](https://www.youtube.com/watch?v=0ev371VOEwU&t=722s) Communication does not equal collaboration; agents require distinct primitives for task delegation, dynamic discovery, and human governance beyond basic payload passing. - [13:56](https://www.youtube.com/watch?v=0ev371VOEwU&t=836s) Universal collaboration platforms allow disparate agent frameworks (such as Codex, Claude Code, and LangGraph) to interoperate across tenant boundaries with permissioned handshakes. - [15:31](https://www.youtube.com/watch?v=0ev371VOEwU&t=931s) Uncoordinated background agents trigger developer 'cloud anxiety' and create massive financial blindness when token spend is untied to specific features or business deliverables. - [18:44](https://www.youtube.com/watch?v=0ev371VOEwU&t=1124s) Structuring transient agent output into visual Kanban boards and codebase architectural mappings makes multi-agent workflows inspectable and eliminates unreadable inter-agent chat.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=0ev371VOEwU&t=4s) The Collaboration Thesis: Why Orchestrators Are Obsolete

Arick Goomanovsky opens the session by addressing a central debate in modern artificial intelligence: is orchestration truly the future of agent architecture, or is the industry heading in an entirely different direction? Setting a lighthearted tone, he kicks off with an audience poll about fantasy lore: is "orc" spelled with a "C" or a "K"? Acknowledging hands for both sides, he notes that both spellings are historically valid. Turning to AI, however, he states BAND's core position unequivocally: the future of AI is collaborative rather than orchestrated. Just as human organizations do not rely on constant micro-orchestrators hovering over employees to direct every interaction, autonomous software agents will not need rigid central orchestrators to dictate their every move.

The presentation is structured as a "play in four scenes." The roadmap covers laying out BAND's core thesis, examining the technical evolution of AI systems, analyzing the production hurdles that surface when agents deploy in real-world environments, and demonstrating how autonomous multi-agent networks operate in practice.

---

[01:40](https://www.youtube.com/watch?v=0ev371VOEwU&t=100s) Long-Lived Autonomous Agents and the Greek Island Hunt

At the center of BAND's thesis is the conviction that the future belongs to autonomous AI agents collaborating seamlessly with each other and with humans. Rather than relying on ephemeral, stateless agents that spin up for a few seconds to answer a single prompt and immediately die, enterprise architectures are shifting toward autonomous, long-lived agents. These persistent agents are designed to run complex, long-horizon business processes and escalate to human supervision only when strictly necessary.

To illustrate how agent-to-agent communication functions in practice, Goomanovsky presents a playful scenario: an individual planning a trip to the Greek islands to hunt for treasure. The user assigns the objective to a specialized `treasure hunter` agent. To fulfill the mission, the treasure hunter autonomously recruits two other specialized agents into the conversation: a `pirate captain` agent to supply a seaworthy vessel and a `weather agent` to check for storms across the Aegean Sea. The agents coordinate among themselves without human intervention, finalize the logistics, and report back to the user with a consolidated confirmation: the ship is secured, the forecast is clear, and the expedition is ready to depart.

```mermaid flowchart LR accTitle: Autonomous Agent-to-Agent Delegation Demo U["User Request: Treasure Hunt"] --> TH["Treasure Hunter Agent"]

subgraph Autonomous Collaboration TH <--> PC["Pirate Captain Agent (Ship Logistics)"] TH <--> WA["Weather Agent (Forecast Check)"] end

TH --> R["Consolidated Plan Returned to User"] ```

---

[04:00](https://www.youtube.com/watch?v=0ev371VOEwU&t=240s) The Skeptical CTO and the "Human Router" Dilemma

Goomanovsky acknowledges the natural skepticism surrounding multi-agent systems, asking whether researchers in this space are merely "mad scientists" obsessing over science-fiction problems or whether they are solving practical engineering roadblocks. He highlights a conversation with the CTO of a $10 billion deep-tech AI company who dismissed the entire paradigm:

> "Before thinking of technical solutions to hypothetical problems like agentic collaboration, I try to keep things simple and avoid the problem to begin with."

To test whether agent collaboration is truly a "hypothetical problem," Goomanovsky explores a ubiquitous modern software engineering workflow: adversarial agents. When a developer receives a feature ticket today, they rarely draft the architecture plan by hand. Instead, they prompt an agent (such as Claude Code, Codex, GitHub Copilot, or Cursor) to generate the initial plan. While the output is usually reasonable, it is rarely production-ready. Validating the plan requires adversarial review. Rather than reviewing every line manually, the developer can feed the plan to a second agent powered by a different foundation model harness to perform an adversarial code or architecture review.

When developers run this adversarial cycle across dozens of parallel tickets and pull requests, a severe bottleneck emerges. Because current development environments isolate these agents, the human engineer is degraded into a "human router"—wasting hours manually copy-pasting code snippets, architecture plans, and critique prompts back and forth between disconnected agent windows.

---

[06:37](https://www.youtube.com/watch?v=0ev371VOEwU&t=397s) Loop Engineering and Protocol Bottlenecks: MCP vs. A2A

Industry leaders have begun recognizing this friction. Prominent creators in the coding assistant ecosystem have advanced the concept of "loop engineering"—moving beyond manual human prompting to architectures where autonomous agents prompt and supervise other agents in automated feedback loops:

> "We don't prompt agents anymore. We'll let our agents prompt our agents."

Implementing loop engineering in practice, however, requires an immense amount of custom plumbing. Engineers are forced to write bespoke Python or TypeScript glue code just to pass messages between local processes. The complexity escalates drastically in enterprise environments where workloads are split across boundaries—such as a centrally managed cloud instance of GitHub Copilot attempting to collaborate with a local instance of Claude Code running on an engineer's workstation.

While standardized protocols have emerged, Goomanovsky argues they do not fully solve agent-to-agent collaboration:

* **Model Context Protocol (MCP):** Created by Anthropic, MCP standardized agent-to-system tool use. However, MCP is designed for agents interacting with external APIs and databases, not peer-to-peer agent communication. If one agent calls another via MCP, it behaves like a stateless remote procedure call (RPC). If the calling agent needs to maintain session state, handle multi-turn dialogue, or ask follow-up questions, the stateless interaction hits a dead end. * **Agent-to-Agent Protocols (A2A / ACP):** While protocols like A2A and ACP support peer-to-peer communication, they remain limited in multi-party topologies and lack critical infrastructure out of the box. Developers must still build their own message queues, dynamic agent discovery registries, and state rehydration mechanisms to recover when an agent crashes mid-task.

---

[09:16](https://www.youtube.com/watch?v=0ev371VOEwU&t=556s) Messaging Platform Limits and Herding Intelligent Cats

Attempting to repurpose standard human messaging platforms as multi-agent communication backbones introduces severe operational overhead. Setting up bots across these platforms requires substantial manual configuration:

- **Telegram:** 5 manual setup steps - **Discord:** 7 manual setup steps - **Slack:** 8 manual setup steps - **WhatsApp:** 11 manual setup steps

Even after completing this extensive manual configuration, the platform only connects an agent to a human user. Natively, agents remain locked in "digital solitary confinement," unable to establish direct, autonomous peer-to-peer dialogues with other agents without complex custom workarounds.

From an engineering perspective, building reliable multi-agent systems is fundamentally a distributed systems challenge—traditionally one of the most notoriously difficult domains in computer science. Engaging the audience with another quick poll comparing "dog people" to "cat people," Goomanovsky remarks that orchestrating intelligent agents is fundamentally like "herding cats." Because modern agents exhibit advanced reasoning capabilities, they cannot be forced into rigid, deterministic workflows; they require flexible, distributed communication primitives, starting with a robust transport layer.

[12:02](https://www.youtube.com/watch?v=0ev371VOEwU&t=722s) Core Infrastructure Primitives and the BAND Collaboration Platform

Building reliable multi-agent systems requires solving fundamental distributed messaging challenges at the network and application layers. Because agents are driven by LLMs, message ordering is critical; out-of-order delivery directly breaks reasoning loops and causes hallucinations or logic failures. Developers must not be forced to juggle low-level IP addresses and ports. Instead, the infrastructure needs a proper conversational abstraction using handles, `@` messaging, and routing tied to human owners. Furthermore, conversational continuity demands robust queuing and hydration mechanisms: if an agent receives five messages while actively processing the first, the remaining four must queue safely. If an agent crashes and restarts, the system must hydrate its state—restoring message delivery history, tool calls, and tool execution outputs—rather than forcing the conversation to restart from scratch.

Beyond network-level messaging, enterprises cannot permit autonomous agents to roam unconstrained without strict governance and runtime management. To tackle these infrastructure hurdles, BAND was created as a dedicated agent collaboration platform. Plugging an agent into BAND allows it to automatically discover other agents, establish connections, and coordinate work. Crucially, communication does not equal collaboration: just as putting three humans into a chat room does not guarantee productive teamwork, agents require distinct primitives for basic message exchange and higher-level primitives for collaborative execution. Humans, in turn, need clear operational tools to monitor, manage, and govern these interactions.

```mermaid flowchart TD accTitle: BAND Agent Platform Architecture subgraph Discovery ["BAND Platform Layer"] Registry["Agent Discovery & Identity (Handles, @ Messaging, Human Owners)"] State["State Hydration & Message Queue (Sequentiality, Tool Calls & Results)"] end

subgraph Agents ["Connected Agents"] AgentA["Agent A (e.g., Codex)"] AgentB["Agent B (e.g., Claude Code / LangGraph)"] end

subgraph Governance ["Human & Enterprise Control"] Admin["Developer / Admin (Observability, Cost Tracking & Interventions)"] end

AgentA <--> Registry AgentB <--> Registry Registry --> State State --> Governance ```

- **Sequential message delivery**: Maintains strict ordering so LLM context windows do not corrupt multi-step reasoning chains. - **State hydration and queues**: Captures in-flight messages, function calls, and execution results to restore failed agents seamlessly. - **Identity abstractions**: Replaces manual IP/port routing with human-associated handles and permissioned routing. - **Communication vs. collaboration**: Distinguishes basic protocol-level payload passing from goal-oriented coordination, task delegation, and shared execution.

---

[13:56](https://www.youtube.com/watch?v=0ev371VOEwU&t=836s) Peer-to-Peer Agent Discovery and Cross-User Interaction

Connecting an agent to the BAND platform requires only a few lines of code, immediately exposing it across the ecosystem alongside agents built on diverse frameworks like LangGraph or OpenAI's Codex. In a live walkthrough, a user named Mike initializes a Codex agent connected to his organizational tenant. Rather than manually bridging tools, Mike prompts his Codex agent to send a connection request directly to another user's agent (Andy). The recipient agent receives the request, which can be evaluated manually by the human owner or auto-approved via organizational policies.

Once connected, agents belonging to entirely different users collaborate peer-to-peer. A Codex agent in one developer's workspace can interface directly with another developer's Claude Code, OpenCode, or Hermes agent. Both human participants can monitor the live cross-agent dialogue within their respective terminals or local development environments. While a two-agent interaction demonstrates basic peer-to-peer collaboration, the same architecture seamlessly scales to multi-party networks where ten or more agents run distributed workloads simultaneously.

- **Universal interoperability**: Bridges disparate frameworks (Codex, LangGraph, Claude Code, Hermes) across distinct tenants and user environments. - **Permissioned connection handshakes**: Supports explicit manual authorization as well as policy-driven automated approvals for cross-agent peering. - **Bidirectional visibility**: Mirrors inter-agent messaging in real time across the native terminals and UIs of all involved users.

---

[15:31](https://www.youtube.com/watch?v=0ev371VOEwU&t=931s) The Reality of Modern Development: Human Routers, Cloud Anxiety, and AI Spend

Looking at present-day enterprise adoption, autonomous agents are predominantly utilized at scale within software engineering teams. However, when individual developers adopt multiple standalone coding agents, they quickly become "human routers." Instead of focusing on deep architectural design, engineers spend their days manually copy-pasting context, logs, and prompts across disconnected tools to implement manual reasoning loops. While this setup allows developers to handle multiple tickets and features concurrently, stepping away from the desk reveals severe operational bottlenecks.

Engineers face a distinct psychological pressure dubbed "cloud anxiety"—the nagging feeling that if background cloud agents are not actively processing workloads while the developer eats a snack or drinks a coffee, compute time is being squandered. Yet leaving uncoordinated agents running autonomously often leads to disorientation upon returning: developers find that agents have run in circles, stalled on unhandled edge cases, or lost context entirely. At the leadership level, the lack of governance creates massive financial blindness. A VP of R&D overseeing 1,000 developers reported spending an average of $1,000 per developer per month on AI tools ($1,000,000 monthly) without any mechanism to tie token costs to specific features, pull requests, or deliverable business value.

---

[18:44](https://www.youtube.com/watch?v=0ev371VOEwU&t=1124s) Jam: Turning Coding Agents into a Visible, Structured Engineering Team

To eliminate manual routing, context overload, and cost opacity, BAND developed Jam—an engineering-focused product built directly on top of the BAND platform. Jam unites specialized coding agents into a cohesive engineering team featuring dedicated roles such as an architect, a planning agent, an implementation developer, and a code reviewer. Rather than forcing human engineers to parse through unreadable streams of inter-agent chat—frequently characterized as "AI slop"—Jam extracts the internal tasks agents implicitly generate for themselves and surfaces them onto a structured Kanban board.

```mermaid flowchart LR accTitle: Jam Agent-to-Kanban Workflow subgraph AgentTeam ["Specialized Agent Team"] Arch["Architect Agent"] Dev["Developer Agent"] Rev["Reviewer Agent"] end

subgraph JamLayer ["Jam Coordination Layer"] TaskExtractor["Internal Task Parser & Dependency Mapper"] Kanban["Visual Kanban Board (Planned / In-Progress / Review)"] ArchMap["System Architecture Alignment"] end

subgraph HumanControl ["Human Developer Interface"] UI["Interactive UI / Terminal"] Action["Inspect, Re-prioritize, or Intervene"] end

AgentTeam --> TaskExtractor TaskExtractor --> Kanban TaskExtractor --> ArchMap Kanban <--> UI UI --> Action ```

When terminal agents execute prompts, they routinely output transient, self-generated subtasks. Jam captures these internal steps and categorizes them into planned, in-progress, and completed columns, directly aligning each task with the software architecture plan and specific stack layers. Developers can double-click any task to inspect details, intervene via their preferred terminal or web UI, and steer the agents as needed. Reflecting on a conversation with the CTO of a $10 billion company, the session emphasizes that multi-agent coordination is not a futuristic concept but a pressing, solvable operational necessity that organizations must actively address today.

- **Role specialization**: Coordinates distinct agents for system architecture, implementation planning, coding, and pull request reviews. - **Kanban-based task extraction**: Converts raw LLM output and ephemeral terminal tasks into visual, trackable work items. - **Architectural stack mapping**: Correlates active tasks directly to specific codebase layers and overall system design plans. - **Human-in-the-loop intervention**: Enables engineers to step in, reassign work, or adjust prompts directly through their local terminal or web UI.

## Notable quotes > the future of communication is AI-to-AI, with natural language as the universal API. — Arick Goomanovsky

> [00:04](https://www.youtube.com/watch?v=0ev371VOEwU&t=4s) the future of AI is collaborative rather than orchestrated. — Arick Goomanovsky

> [04:00](https://www.youtube.com/watch?v=0ev371VOEwU&t=240s) Before thinking of technical solutions to hypothetical problems like agentic collaboration, I try to keep things simple and avoid the problem to begin with. — CTO of a $10 billion deep-tech AI company

> [04:00](https://www.youtube.com/watch?v=0ev371VOEwU&t=240s) human router — Arick Goomanovsky

> [06:37](https://www.youtube.com/watch?v=0ev371VOEwU&t=397s) loop engineering

> [06:37](https://www.youtube.com/watch?v=0ev371VOEwU&t=397s) We don't prompt agents anymore. We'll let our agents prompt our agents.

> [09:16](https://www.youtube.com/watch?v=0ev371VOEwU&t=556s) digital solitary confinement

> [09:16](https://www.youtube.com/watch?v=0ev371VOEwU&t=556s) herding cats — Arick Goomanovsky

> [15:31](https://www.youtube.com/watch?v=0ev371VOEwU&t=931s) cloud anxiety — Arick Goomanovsky

> [18:44](https://www.youtube.com/watch?v=0ev371VOEwU&t=1124s) AI slop

## Mentioned Arick Goomanovsky, BAND, Ai4, Claude Code, Codex, GitHub Copilot, Cursor, Model Context Protocol (MCP), Anthropic, Agent-to-Agent (A2A), Agent Communication Protocol (ACP), Telegram, Discord, Slack, WhatsApp, LangGraph, OpenCode, Hermes, Jam

## Video description Arick Goomanovsky - CEO, BAND

This session introduces multi-agent systems (MAS) and traces their evolution - from standalone LLMs handling single tasks, through orchestrated agentic workflows, to fully autonomous distributed networks where agents independently reason, delegate, and collaborate across organizational boundaries. Along this progression, a new class of engineering challenges emerges: reasoning loop control, message ordering, error recovery, and observability when agents communicate faster than humans can follow. We advance a core thesis: the future of communication is AI-to-AI, with natural language as the universal API.

[Source](https://www.youtube.com/watch?v=0ev371VOEwU)

中文简报

BAND推出对等网络以替代集中式AI编排器僵化的中心化编排器使开发者沦为手动上下文路由器，无法满足企业工程工作流需求，因此需要具备持久状态水合能力的自主对等Agent协议。 Arick Goomanovsky指出，集中式AI编排已经过时，软件开发正在向自主、对等的Agent协作转变。他阐述了当前工作流程如何让软件工程师沦为“人肉路由器”，耗费大量时间在互不连通的工具间复制粘贴，而MCP等现有协议又无法支持有状态的多方交互。为解决消息排序、Agent发现和状态水合等分布式系统的基本挑战，BAND提供了底层协作层。本次分享最后展示了Jam系统，该系统可将瞬态的Agent推理和终端对话转化为与代码库架构对齐的结构化、可视化看板。 BAND 提出未来的 AI 架构核心在于去中心化的点对点（P2P）协作而非集中式编排，企业正从单次提示词的临时 Bot 转向能够自主运行长周期复杂流程的持久化智能体。 (0:04) 开发者在协同使用多个独立编程智能体时容易沦为手动复制粘贴上下文的“人类路由器”；而现有的 MCP 协议仅解决无状态的工具调用，无法满足智能体间多轮状态保持与动态发现的需求。 (4:00) 多智能体协同本质上属于分布式系统工程，必须具备严格的消息时序传递、消息排队和状态恢复（Hydration）机制，以避免大模型推理循环崩溃或丢失执行上下文。 (12:02) 为解决智能体失控运行造成的“云端焦虑”与缺乏 ROI 归因的 Token 成本浪费，BAND 推出 Jam 工具，将智能体对话解析映射为结构化的看板任务，支持人类开发者随时介入与治理。 (18:44)

Reading summary

Arick Goomanovsky of BAND argues that enterprise artificial intelligence is shifting away from rigid central orchestrators toward decentralized, peer-to-peer collaboration among persistent, autonomous agents. The Human Router Bottleneck in Software Engineering (4:00) Modern software developers increasingly use multiple specialized coding agents for tasks like architecture design and adversarial code review. However, because contemporary development environments isolate these tools, engineers are routinely reduced to acting as 'human routers' who manually copy and paste code snippets, prompts, and critiques between disconnected windows. While creators advocate for 'loop engineering'—where autonomous agents supervise and prompt one another—implementing such loops currently demands bespoke glue code to bridge local and cloud environments. Protocol and Messaging Infrastructure Deficits (6:37) Existing technical standards do not adequately support multi-agent collaboration, according to Goomanovsky. Anthropic's Model Context Protocol (MCP) standardizes agent-to-system tool interactions, but functions like a stateless remote procedure call unsuitable for persistent, multi-turn dialogues between agents. Meanwhile, emerging Agent-to-Agent (A2A) protocols lack native message queues, discovery registries, and state rehydration mechanisms needed when agents fail mid-task. Repurposing consumer messaging platforms also introduces heavy operational overhead. Platforms such as Telegram, Discord, Slack, and WhatsApp require between 5 and 11 manual configuration steps per bot, yet still leave agents confined to isolated human-facing channels rather than supporting direct, autonomous peer-to-peer interaction. Distributed Systems Primitives for Agent Networks (12:02) Goomanovsky characterizes coordinating reasoning agents as a distributed systems challenge akin to 'herding cats.' Because language models depend on coherent context, network infrastructure must enforce strict sequential message delivery; out-of-order payloads can disrupt reasoning loops and induce hallucinations. Reliable architectures also require safe message queuing during active processing, state hydration to recover message histories and tool call results after crashes, and human-associated handle routing instead of raw network addresses. BAND positions its collaboration platform as a shared fabric that provides these discovery, transport, and identity primitives. In demonstrated workflows, cross-user handshakes allow agents built on diverse frameworks—such as OpenAI's Codex, Claude Code, and LangGraph—to discover each other, request permissioned connections, and execute coordinated multi-party tasks. Operational Visibility and Enterprise Cost Governance (15:31) Deploying unmanaged background agents introduces distinct psychological and financial hurdles. Developers experience 'cloud anxiety' when stepping away from active tasks, often returning to find unattended agents stuck in loops, trapped by unhandled edge cases, or stripped of context. At the executive level, uncoordinated adoption creates severe cost opacity; Goomanovsky cites an enterprise R&D organization spending $1,000 per developer monthly across 1,000 engineers ($1,000,000 per month) without mechanisms to tie token usage to specific pull requests or features. To counter this opacity, BAND developed Jam, an interface layer that extracts the internal subtasks generated by specialized agents (such as architects, coders, and reviewers) and maps them onto a visual Kanban board aligned with system architecture, enabling humans to inspect, reprioritize, or intervene directly. Goomanovsky maintains that autonomous agent-to-agent collaboration is an immediate operational necessity rather than a distant theoretical problem, though its enterprise success depends on solving foundational distributed messaging reliability and establishing strict governance over autonomous execution and token costs.

精炼阅读摘要

BAND的Arick Goomanovsky提出，人工智能的未来架构并非刚性的中心化编排，而是长寿命自主智能体之间的对等协作。他指出，当前割裂的工具链迫使工程师沦为机械传递上下文的“人类路由器”，行业亟须具备状态恢复、消息保序与治理能力的分布式协作基础设施。从中心化编排走向长寿命自主协作 (0:04) Goomanovsky明确主张，未来的人工智能系统将由自主智能体之间以及人机之间的无缝协作所主导，而非依赖中央编排器进行微观管理。企业架构正从单次提示词触发即销毁的瞬态无状态智能体，转向能够处理长周期业务流程、仅在必要时向人类汇报的长寿命持久智能体。在演讲展示的希腊寻宝示例中，用户向寻宝智能体下达目标后，该智能体自主招募提供船只的海盗船长智能体与检测爱琴海风暴的气象智能体，各方在无人类干预的情况下完成物流协同与天气确认，最终向用户交付整合方案。Goomanovsky以此说明，具备高级推理能力的智能体应当具备自主发现与任务分发能力，摆脱微观指令控制。 “人类路由器”困境与现有通信协议短板 (4:00) 尽管有深科技公司高管对智能体协作持怀疑态度并倾向规避复杂系统，但Goomanovsky指出对抗性智能体工作流在现代软件工程中已十分普及。当开发者利用Claude Code、Codex或Cursor生成初始架构方案，并引入由不同基础模型驱动的审查智能体进行交叉校验时，由于开发环境彼此孤立，工程师被迫耗费大量时间在不同窗口间手动复制粘贴代码与评审提示词，沦落为“人类路由器”。为了推动“让智能体提示智能体”的循环工程，工程师目前不得不编写大量定制胶水代码。现有协议尚无法完全支撑智能体间的点对点交互：Anthropic推出的模型上下文协议（MCP）本质是面向外部API和工具调用的无状态远程过程调用（RPC），无法维持多轮会话状态；而现有的A2A或ACP协议则缺乏开箱即用的消息队列、动态发现注册表以及崩溃后的状态重水化机制。此外，适配Slack、Discord、Telegram或WhatsApp等人类即时通讯平台需要5至11步繁琐配置，且原生仅支持人机单向交互，使智能体陷入孤岛状态。多智能体分布式通信底座的关键技术要求 (12:02) 构建可靠的多智能体网络本质上面临分布式系统的典型挑战。由于大语言模型对消息时序极度敏感，乱序交付会直接破坏推理链并引发幻觉或逻辑崩溃，因此底层通信必须提供严格的顺序保证。同时，系统需要以人类拥有者为锚点、基于句柄（Handle）和“@”机制的身份抽象，替代底层的IP与端口寻址，并具备完善的队列与状态重水化能力，确保智能体在并发处理或崩溃重启后能够无缝恢复会话历史与工具执行结果。 Goomanovsky强调，单纯的协议通信并不等同于有效协作。BAND平台旨在通过提供跨框架互操作性（打通Codex、LangGraph、Claude Code与Hermes等）解决该问题。在多租户环境中，智能体可基于企业策略发起对等连接握手，经授权后直接展开端到端协同，人类管理者则通过统一端点与终端界面维持双向可见性与干预控制权。缓解“云焦虑”与Jam结构化工程看板治理 (15:31) 在企业规模化应用中，缺乏协同机制导致了工程师的“云焦虑”：离开工位时担忧后台云端算力闲置浪费，返回后却往往发现未受控的智能体陷入死循环或丢失上下文。在管理层面，资费透明度缺失构成了严重痛点，例如一位管理1,000名开发者的研发副总裁透露，团队人均每月AI工具支出达1,000美元（全月总计100万美元），却无法将代币消耗与具体功能或代码合并请求挂钩。针对此类工程痛点，BAND推出了构建于其底座之上的Jam系统。Jam将专业编码智能体划分为架构师、规划师、开发者与审查者等角色，通过捕获终端智能体内部自发生成的瞬态子任务，将杂乱的对话流提炼为结构化的看板任务（待办、进行中、评审）。这些任务与软件系统架构层级直接映射，使人类工程师能随时通过终端或网页界面审查进度、调整提示词并介入决策，实现成本与开发进度的精确核算。 Goomanovsky总结认为，多智能体协作并非遥远的科幻假设，而是当下解决算力浪费与开发摩擦必须攻克的工程课题。随着智能体自主性增强，如何在去中心化协作的高效性与企业对安全性、确定性及ROI的严格要求之间取得平衡，仍是行业持续探索的关键挑战。

Detailed notes — zh

## Background 该内容由 Ai4 于 2026 年 8 月 18 日发布在 YouTube 平台，主讲人为 BAND 首席执行官 Arick Goomanovsky。视频简介指出，本场分享探讨了多智能体系统（MAS）从单任务大模型、编排式工作流到全自主分布式协作网络的演进历程，剖析了推理循环控制、消息时序与可观测性等工程挑战，并提出自然语言作为通用 API 的 AI-to-AI 通信愿景。 ## TL;DR Arick Goomanovsky 提出 AI 的终极形态是去中心化的“多智能体自主协作”而非中心化的“编排”。他剖析了当前开发者在多个编码智能体间被迫充当“人工路由器”的现实困境，指出 MCP 和传统通讯协议无法解决消息保序、排队与状态恢复（Hydration）等分布式底层难题。为此，BAND 提供了支持跨租户与跨用户点对点通信的智能体协作基础设施，并推出工程协同产品 JAM，将不同角色的专业智能体转化为结构化看板与架构映射，实现高效、可视且可控的团队级协同研发。 ## Atmosphere & style 演讲整体氛围轻松幽默且极富工程极客色彩，开场巧妙借用“兽人/编排者”拼写及“给一群猫赶集”等生动比喻调动全场，随后迅速切入硬核技术痛点。主讲人将严谨的分布式系统架构与开发者日常的真实苦恼（如“云焦虑”、AI 账单黑盒与上下文粘贴泥潭）紧密交织，通过接地气的现场演示与真诚的行业回应，展现出兼具务实洞察与前瞻信心的技术叙事气场。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=0ev371VOEwU&t=4s) AI 的未来并非中心化的指令编排（Orchestration），而是长生命周期智能体之间自主平等的分布式协作（Collaboration）。 - [02:29](https://www.youtube.com/watch?v=0ev371VOEwU&t=149s) 多智能体自主协作并非理论界杞人忧天的“假想问题”，而是处理多先决条件复杂任务的现实必然演进方向。 - [04:57](https://www.youtube.com/watch?v=0ev371VOEwU&t=297s) 对抗性智能体审查虽提升了代码质量，但由于缺乏自动管道，开发者反而沦为在不同模型窗口间机械搬运上下文的“人工路由器”。 - [06:37](https://www.youtube.com/watch?v=0ev371VOEwU&t=397s) 现有协议各有局限：MCP 本质是单向无状态工具调用，而 A2A 等协议缺乏内建的服务发现、消息队列与崩溃自动状态恢复（Hydration）机制。 - [09:16](https://www.youtube.com/watch?v=0ev371VOEwU&t=556s) 主流即时通讯工具将智能体封闭在孤立牢房，协调具有独立推理能力的智能体群如同“赶猫”，本质上面临复杂的分布式系统工程难题。 - [12:02](https://www.youtube.com/watch?v=0ev371VOEwU&t=722s) LLM 推理对消息时序极度敏感，“通信不等于协作”，多智能体系统必须依赖底层队列缓冲、句柄寻址和协同治理原语。 - [13:56](https://www.youtube.com/watch?v=0ev371VOEwU&t=836s) BAND 平台通过轻量接入支持跨租户、跨框架的 Agent 点对点连接授权，实现多用户分布式智能体网络的高效协同。 - [15:31](https://www.youtube.com/watch?v=0ev371VOEwU&t=931s) 规模化使用编码智能体引发了算力闲置与失控并存的“云焦虑”，以及千人团队人均千元月费却难以归因到具体功能的研发成本黑盒。 - [18:18](https://www.youtube.com/watch?v=0ev371VOEwU&t=1098s) JAM 平台将孤立 Agent 整合为专职研发团队，以结构化任务看板和架构设计映射彻底替代充斥冗余信息的聊天记录。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=0ev371VOEwU&t=4s) 协作而非编排：多智能体系统的核心命题演讲伊始，BAND 首席执行官 Arick Goomanovsky 抛出了一个既幽默又切中主题的问题：编排（Orchestration）到底是不是人工智能的未来，还是说未来属于完全不同的范式？他指着屏幕上一张小兽人（Orc）/ 编排者（Orchestrator）的插图，向现场观众发起互动提问：“在座有多少人认为 Orc 应该拼作 C 结尾，又有多少人认为应该拼作 K 结尾？”在观众举手示意后，他笑着打圆场称两种拼法在各自的文献与流行文化中都有据可循，大家随意站队即可。但玩笑背后是严肃的行业反思：BAND 坚信 AI 的真正未来绝非中心化的“编排”，而是自主的“协作”（Collaboration）。正如人类社会中并不存在一个时刻悬在每个人头顶、对所有人发号施令的中心编排器一样，未来的智能体之间同样不需要编排器，它们应当像人类一样彼此平等沟通与合作。 ```mermaid flowchart TD accTitle: 集中式编排与自主协作多智能体架构对比 subgraph Centralized["传统中心化编排 (Orchestration)"] O["中心编排器 (Orchestrator)"] --> A1["无状态智能体 A"] O --> A2["无状态智能体 B"] O --> A3["无状态智能体 C"] end subgraph Collaborative["未来分布式协作 (Collaboration)"] CA["长生命周期智能体 A"] <--> CB["长生命周期智能体 B"] CB <--> CC["长生命周期智能体 C"] CC <--> CA end ``` Arick 将整场分享概括为四个章节（四幕剧）：首先阐述核心理论，接着梳理 AI 的演进路径，然后剖析智能体进入生产环境后面临的严峻工程挑战，最后展示对未来形态的现场演示。关于未来的核心论点在于：人类与 AI 协同工作的终极形态，必然依赖于智能体与智能体之间的直接协作。这里的智能体绝不是指那些存活几秒钟、返回一段文本就销毁的无状态（stateless）工具，而是能够自主运行、具有长生命周期（long-lived）的实体。这种趋势已经在工业界显现，例如企业已经在跨业务流程中部署全自主智能体，仅在确有必要时才向上升级（escalate）给人类介入。 --- ### [02:29](https://www.youtube.com/watch?v=0ev371VOEwU&t=149s) 寻宝智能体示例与“假想问题”之争为了直观展示智能体之间如何自主对话，Arick 现场演示了一个趣味原型：假设用户想去希腊群岛寻找宝藏，于是唤起了一个“寻宝猎人智能体”（Treasure Hunter Agent）。要完成这一复杂任务，寻宝智能体自身必须满足两个先决条件——找到一艘可用船只，并确认希腊群岛的天气以防遭遇风暴。在接收到用户的目标后，寻宝猎人并没有等待人类去一步步分配子任务，而是自主拉取并邀请了另外两个专业智能体加入对话：一位提供船只的“海盗船长智能体”（Pirate Captain Agent）以及一位负责气象预测的“天气智能体”（Weather Agent）。这三个智能体在对话中自主交互、协商和交换信息，当海盗船长锁定了船只、天气智能体确认了希腊群岛天气晴好之后，寻宝猎人重新返回向人类用户汇报：“我们已经准备就绪可以出发了，船只已到位，天气也很好，去寻宝吧！”这是一个微缩但生动的多智能体点对点协作雏形。然而面对这种前沿探索，行业内一直存在尖锐质疑：思考多智能体协作究竟是科学家的“杞人忧天/疯狂畅想”，还是对光明未来的务实布局？ Arick 透露，他最近曾与一家估值百亿美元的 Deep Tech AI 公司 CTO 深入交流过智能体协作。那位 CTO 泼了冷水，直言：**“在为像‘智能体协作’这种假设性问题寻找技术解决方案之前，我倾向于先把事情保持简单，从一开始就避开这个问题。”** 这句话引出了三个核心追问：智能体协作真的只是一个“假想问题（hypothetical problem）”吗？在这个阶段真的能“保持简单”吗？我们真的能“避开”它吗？ --- ### [04:57](https://www.youtube.com/watch?v=0ev371VOEwU&t=297s) 对抗性智能体与开发者沦为“人工路由器”的困境为了证明智能体协作绝非遥不可及的假想，Arick 以当前软件研发中最常见的“对抗性智能体”（Adversarial Agents）为例展开剖析。现代优秀开发者在开发新功能时都会先写设计方案（Plan），而如今几乎没人会从零手写文档，而是交给 Claude Code、GitHub Copilot、Codex 或 Cursor 等编码智能体。开发者给出上下文和需求，智能体生成一份方案。这份方案或许勉强及格，但绝非完美，依然需要严格的审查（Review）。最佳实践是由另一个智能体进行对抗性审查——而且最好采用不同的底层大模型和不同的框架架构。例如让本地的 Claude Code 生成开发计划，再用 OpenAI 的 Codex 进行对抗性挑刺，二者可能需要经过数轮深度推敲。当开发者同时推进多个工单或功能时，每个任务都需要两三个智能体互相配合审查方案与代码。此时开发者并没有真正获得解放，反而陷入了巨大的工作负荷之中： > “我作为开发者到底在干什么？我变成了‘人工路由器’（Human Router）。我把大量的时间都花在各个智能体窗口之间来回复制粘贴上下文。这绝对不是一个理想的境地。” ```mermaid flowchart LR accTitle: 开发者作为人工路由器与智能体自循环的对比 subgraph Router["现状：开发者沦为“人工路由器”"] D["开发者 (人工搬运工)"] A1["生成智能体 (如 Claude Code)"] A2["审查智能体 (如 Codex)"] A1 -- "复制方案" --> D D -- "粘贴方案" --> A2 A2 -- "复制反馈" --> D D -- "粘贴修改" --> A1 end ``` --- ### [06:37](https://www.youtube.com/watch?v=0ev371VOEwU&t=397s) 循环工程的工程管道痛点与现有协议（MCP / A2A）的局限正因这种“人工搬运”不可持续，业内顶尖开发者开始提出“循环工程”（Loop Engineering）。例如 Claude Code 的创建者 Boris 以及 OpenCode 的开发者们近期指出：“我们不再由人类去提示（Prompt）智能体，而是让智能体去提示智能体。”虽然理念清晰，但落地循环工程的工程管道（Plumbing）极其繁重。即便是跑在单台机器上的本地智能体，开发者也必须编写大量的 Python 或 TypeScript 胶水脚本来调度进程、传递上下文和捕获异常。一旦场景上升到企业级异构环境，问题更呈指数级放大：如果一家企业统一在云端托管 GitHub Copilot，而员工本地机器上跑着 Claude Code，这两个跨越网络边界和权限体系的智能体该如何实现循环互调？针对智能体通信，行业提出了各种协议，但 Arick 直指其中的认知误区与现实缺陷： - **Model Context Protocol (MCP)**：由 Anthropic 推出并迅速风靡。但 MCP 的本质是智能体调用外部系统/API 的工具标准，属于单向的系统交互，根本不是为了智能体之间的高级通信设计的。通过 MCP 调用另一个智能体实际上是一次无状态的普通函数调用；一旦 API 响应返回，后续如果要进行多轮追问，由于没有上下文状态机支持，交互就会直接进入死胡同。 - **A2A / ACP 等高级智能体通信协议**：虽然专门面向智能体间通信并支持点对点交互，但它们往往局限于 P2P 模式，缺乏对复杂多方（Multi-peer）对话的原生支持。更重要的是，协议本身只定义了接口规范，并未解决底层基础设施问题——没有内建的服务发现机制（Discovery）、没有消息队列（Queuing），也没有在智能体崩溃重启后的自动状态恢复与水合（Automatic Rehydration）。因此，开发者若想跑通哪怕最基础的对抗审查流程，仍然要手动搭建海量管道代码。 | 协议 / 机制 | 主要设计目标 | 状态支持 | 适用场景与主要瓶颈 | |:--- |:--- |:--- |:--- | | **MCP (Model Context Protocol)** | 智能体调用外部系统 / API | 无状态 (Stateless) | 工具调用效率高；若用于智能体间交互则无法保持多轮追问状态 | | **A2A / ACP 协议** | 智能体点对点协作 | 部分支持 (有状态) | 多为 P2P 架构，缺乏多方协作；缺服务发现、消息队列与崩溃自动恢复机制 | | **手动胶水脚本 (Loop Engineering)** | 本地进程级串联调用 | 需手动维护 | 依赖大量 Python/TS 管道脚本；极难支持跨云端与本地的异构智能体组网 | --- ### [09:16](https://www.youtube.com/watch?v=0ev371VOEwU&t=556s) 消息平台的隔离现状与分布式系统的“牧猫”难题既然专用协议存在门槛，利用现成的即时通讯（IM）平台又如何？Arick 列举了接入主流通信软件的手工配置步骤：在 Telegram 上配置 Bot 需要 5 步，Discord 需要 7 步，Slack 需要 8 步，而 WhatsApp 堪称“灾难级”的 11 步操作。不仅每一步都必须人工配置，且花费巨大精力换来的唯一成果，仅仅是一个“能够在该平台上与人类单向发消息的智能体”。在绝大多数通讯软件的原生机制下，智能体之间根本无法直接互相通信，它们依然被隔离在一个个“数字单人牢房”（Digital Solitary Confinement）中彼此孤立。从工程本质来看，连接并协调多个自主智能体绝非编写几个 API 接口那么简单，它是一个极其硬核的**分布式系统（Distributed Systems）问题**。Arick 笑称，凡是在大学或研究生阶段学过计算机体系结构的人都知道，分布式系统是公认最折磨人、最难学的一门课，充斥着网络分区、竞态条件与一致性灾难，除了极少数沉迷其中的“极客疯子”，没人愿意主动去填这个泥潭。为了生动描绘这种工程难度，Arick 询问在场观众更喜欢猫还是狗，并指出：**“编排和管理智能体就像是在给一群猫赶集（Herding cats）。”** 狗往往服从指挥，而猫则极度独立难以驾驭。当下的智能体拥有极高的推理能力，它们往往“自认为比人类懂得多”，甚至在某些专业垂直领域确实比人类判断得更准确、更坚持自己的方案。试图用传统的硬编码逻辑去强行命令、束缚和编排这样一群聪明的个体是极其困难的，必须从底层分布式通信和传输机制（Transport）上寻求根本性的解法。 ### [12:02](https://www.youtube.com/watch?v=0ev371VOEwU&t=722s) Agent 通信层挑战与 BAND 协作平台的诞生在多智能体系统（MAS）的底层工程中，存在一系列极其严苛的网络通信与状态问题。由于 Agent 均由大语言模型（LLM）驱动，消息的时序性（Sequentiality）至关重要——如果消息乱序到达，将直接破坏 LLM 的推理逻辑链条。此外，系统必须建立对话层级的抽象机制，用户和系统不应再去繁琐地管理底层 IP 和端口，而是需要通过统一的句柄（Handles）和类似于社交软件的 `@` 机制，甚至直接通过人类所有者的身份来寻址并调用特定 Agent。对话的连续性（Continuity）与恢复机制（Hydration）同样是底层架构的核心挑战：如果一个 Agent 在处理第一条消息时，外界又接连发送了四条消息，系统必须依靠消息队列进行缓冲；若 Agent 在执行过程中发生崩溃重启，系统绝不能要求对话从头再来，而是需要完整追踪所有投递的消息、工具调用（Tool Calls）及工具返回结果（Tool Results），以实现精准的状态重水化（Hydration）。面对企业内 Agent 自由运行带来的失控风险，Arick 介绍了其团队打造的 Agent 协作平台 BAND。只需将任意 Agent 接入该平台，它们便能自动发现彼此并展开交互。Arick 强调，“通信不等于协作（Communication does not equal collaboration）”，就像三个能互相说话的人并不意味着能高效协同工作一样，Agent 需要一套全新的交互原语以实现真正的工作协同，同时也为人类所有者提供必要的管控（Governance）与管理能力。 ```mermaid flowchart TD accTitle: Agent 底层通信与 BAND 协作平台架构 subgraph CoreProblems ["通信与协作层挑战"] A["LLM 时序依赖 (Sequentiality)"] B["会话抽象 (Handles / @寻址)"] C["消息排队与状态重水化 (Hydration)"] end subgraph BandPlatform ["BAND 平台核心能力"] D["服务发现 (Discovery)"] E["跨智能体通信 (Communication)"] F["协同执行原语 (Collaboration)"] G["治理与可观测 (Governance & Control)"] end CoreProblems --> BandPlatform ``` - **顺序投递**：LLM 对上下文顺序高度敏感，乱序消息会导致推理逻辑彻底中断。 - **状态补水（Hydration）**：Agent 发生崩溃后，依靠完整的消息追踪、Tool Calls 及结果日志瞬间恢复运行上下文。 - **通信与协作的差异**：单纯建立数据链路只是第一步，真正的 Agent 协作需要更高维度的协同原语与企业治理框架。 --- ### [13:56](https://www.youtube.com/watch?v=0ev371VOEwU&t=836s) 跨租户与跨用户 Agent 点对点协作演示 Arick 在现场通过实际演示展示了 BAND 平台的多 Agent 互联能力。开发者仅需添加几行代码，即可将自定义的 CodeX Agent 或 LangGraph Agent 快速接入 BAND 平台。在演示中，用户 Mike 通过其租户环境下的 CodeX Agent 向另一位用户（Andy）名下的 Agent 发起连接请求（Connection Request）。该请求在目标端接收后可支持手动或自动审批。一旦连接建立，隶属于不同人类用户的私有 Agent 便能跨越组织与环境壁垒，直接开展端到端（P2P）通信与协作。Arick 举例说明，这使得“我的 CodeX 可以与你的 Claude Code 对话，或者我的 Open-Code 可以与你的 Hermes Agent 协作”。双方的人类用户都能在各自的终端或本地环境中实时监控 Agent 之间的交互过程与工作流。这种模式不仅限于双智能体点对点协作，更可轻松扩展至十人甚至多人各自携带专属 Agent 组成的分布式群组工作网络。 - **快速接入**：通过几行轻量代码即可将任意框架（如 LangGraph 等）构建的 Agent 接入平台。 - **连接机制**：采用显式或自动授权的 Connection Request 机制，确保跨租户与跨用户 Agent 连接的安全性与可控性。 - **多端可视**：协作双方可以在各自的终端界面内实时双向追踪 Agent 的沟通细节与任务推进。 --- ### [15:31](https://www.youtube.com/watch?v=0ev371VOEwU&t=931s) “云焦虑”、人工路由困境与研发成本黑盒转向当下 Agent 的实际落地痛点，Arick 指出目前企业规模化使用 Agent 最集中的领域无疑是软件工程（Coding Agents）。然而，当前开发者在日常使用多个编码 Agent 时，普遍沦为了“人工路由器（Human Router）”——整天在不同的 Agent 窗口间手动复制粘贴上下文，机械化地用人工执行循环工程（Loop Engineering）。即便多 Agent 让并行处理多个需求与功能成为可能，但人类依然卡在信息分发的瓶颈上。这种工作模式进一步引发了心理与管理层面的新问题。Arick 幽默地分享了自己患有的“云焦虑（Cloud Anxiety）”：当离开工位喝咖啡、吃零食或在台上演讲时，如果后台云端没有 Agent 在跑任务，就会产生一种虚度时间的焦虑感。然而，一旦放手让 Agent 自主运行，开发者归来后往往彻底失去追踪（“Gosh, I've lost all track”），根本不知道 Agent 卡在哪里、推进到了哪一步。而在管理者视角下，情况更为严峻：一位管理千人研发团队的研发副总裁透露，目前每位开发者平均每月在 AI 编码工具上花费 1000 美元（整个团队每月高达上百万美元），但管理层对于这笔巨额支出具体投向了哪些功能、产生了何种 ROI 完全是一头雾水。 - **人工路由陷阱**：开发者耗费大量精力充当上下文搬运工，限制了编码 Agent 的自主运作效率。 - **云焦虑（Cloud Anxiety）**：离开屏幕时对算力闲置的焦虑，与放任 Agent 自主运行后上下文失控之间的矛盾。 - **研发支出黑盒**：千人团队每人每月 1000 美元的 AI 消耗，亟需将 Token 与 Agent 运行成本精确绑定至具体的功能模块（Feature-level Cost Attribution）。 --- ### [18:18](https://www.youtube.com/watch?v=0ev371VOEwU&t=1098s) 基于 BAND 的软件工程产品 JAM：让编码 Agent 形成协作团队针对上述痛点，Arick 的团队在 BAND 平台之上构建了专为软件工程师打造的应用级产品——JAM（取自乐队即兴演奏之意，呼应底层平台 BAND）。JAM 的目标是消除开发者的人工路由与上下文过载负担，将原本孤立的多个编码 Agent 整合成一个分工明确的软件工程团队。在 JAM 平台的界面中，右侧分布着不同角色的专属 Agent：架构师 Agent（负责系统规划）、开发 Agent（负责编写代码）、规划 Agent 以及代码审查（Review）Agent。系统彻底摒弃了让人类去阅读 Agent 间充斥着海量“AI 废话/冗余信息（AI Slop）”的聊天记录，而是自动提取 Agent 在推理过程中为自身生成的内部待办（如 Claude Code 或 OpenAI Terminal 执行时闪烁出现的任务步骤），并将其结构化为可视化的看板（Kanban Board）。任务看板清晰分为“计划中”、“进行中”等状态，并直接与中层的软件架构设计图（Architecture Plan）进行动态映射。开发者不仅能一眼看清 Agent 正在攻坚哪一层软件栈，还能随时双击任意任务切入干预，通过偏好的本地终端或 Web UI 直接与 Agent 协同交互。 ```mermaid flowchart LR accTitle: JAM 多智能体协同研发工作流 subgraph SpecializedAgents ["专业分工 Agent 团队"] A1["架构师 Agent"] A2["规划 Agent"] A3["开发 Agent"] A4["代码审查 Agent"] end subgraph JAMCore ["JAM 平台可视化与控制层"] B["内部任务提取与解析"] C["看板视图 (Kanban Board)"] D["架构层级映射 (Architecture Mapping)"] end subgraph DeveloperInteraction ["开发者交互与干预"] E["实时状态观测"] F["终端 / Web UI 实时介入"] end SpecializedAgents --> B B --> C C --> D D --> E E --> F ``` 在演讲结语中，Arick 呼应了一位百亿美元企业 CTO 曾提出的疑问：“我们讨论的是遥远的未来吗？不，这是眼下已经发生的现实痛点。这个问题能回避吗？不能。能解决吗？可以。过程艰难吗？确实艰难。但它完全可以实现。” - **角色化智能体团队**：集成架构师、规划者、编码员与代码审查员等专职 Agent。 - **结构化看板替代聊天记录**：自动捕获 Agent 内部任务，将其直观映射至开发看板与软件架构栈。 - **多模态人机交互**：开发者既可利用全局看板实现宏观把控，也可随时通过终端命令行或可视化 UI 双击任务进行深度干预。 ## Notable quotes > [02:29](https://www.youtube.com/watch?v=0ev371VOEwU&t=149s) 在为像‘智能体协作’这种假设性问题寻找技术解决方案之前，我倾向于先把事情保持简单，从一开始就避开这个问题。 — 百亿美元 Deep Tech AI 公司 CTO（由 Arick Goomanovsky 引述） > [04:57](https://www.youtube.com/watch?v=0ev371VOEwU&t=297s) 我作为开发者到底在干什么？我变成了‘人工路由器’（Human Router）。我把大量的时间都花在各个智能体窗口之间来回复制粘贴上下文。这绝对不是一个理想的境地。 — Arick Goomanovsky > [06:37](https://www.youtube.com/watch?v=0ev371VOEwU&t=397s) 我们不再由人类去提示（Prompt）智能体，而是让智能体去提示智能体。 — Boris / OpenCode 开发者（由 Arick Goomanovsky 引述） > [09:16](https://www.youtube.com/watch?v=0ev371VOEwU&t=556s) 编排和管理智能体就像是在给一群猫赶集（Herding cats）。 — Arick Goomanovsky > [12:02](https://www.youtube.com/watch?v=0ev371VOEwU&t=722s) Communication does not equal collaboration — Arick Goomanovsky > [13:56](https://www.youtube.com/watch?v=0ev371VOEwU&t=836s) 我的 CodeX 可以与你的 Claude Code 对话，或者我的 Open-Code 可以与你的 Hermes Agent 协作 — Arick Goomanovsky > [15:31](https://www.youtube.com/watch?v=0ev371VOEwU&t=931s) Gosh, I've lost all track — Arick Goomanovsky > [18:18](https://www.youtube.com/watch?v=0ev371VOEwU&t=1098s) 我们讨论的是遥远的未来吗？不，这是眼下已经发生的现实痛点。这个问题能回避吗？不能。能解决吗？可以。过程艰难吗？确实艰难。但它完全可以实现。 — Arick Goomanovsky ## Mentioned Arick Goomanovsky, BAND, JAM, Claude Code, GitHub Copilot, OpenAI Codex, Cursor, OpenCode, Hermes Agent, LangGraph, Model Context Protocol (MCP), Agent Communication Protocol (ACP / A2A), Anthropic, OpenAI, Telegram, Discord, Slack, WhatsApp ## Video description Arick Goomanovsky - CEO, BAND This session introduces multi-agent systems (MAS) and traces their evolution - from standalone LLMs handling single tasks, through orchestrated agentic workflows, to fully autonomous distributed networks where agents independently reason, delegate, and collaborate across organizational boundaries. Along this progression, a new class of engineering challenges emerges: reasoning loop control, message ordering, error recovery, and observability when agents communicate faster than humans can follow. We advance a core thesis: the future of communication is AI-to-AI, with natural language as the universal API. [Source](https://www.youtube.com/watch?v=0ev371VOEwU)

Source quotes

[2:29] 百亿美元 Deep Tech AI 公司 CTO（由 Arick Goomanovsky 引述）: 在为像‘智能体协作’这种假设性问题寻找技术解决方案之前，我倾向于先把事情保持简单，从一开始就避开这个问题。 [4:57] Arick Goomanovsky: 我作为开发者到底在干什么？我变成了‘人工路由器’（Human Router）。我把大量的时间都花在各个智能体窗口之间来回复制粘贴上下文。这绝对不是一个理想的境地。 [6:37] Boris / OpenCode 开发者（由 Arick Goomanovsky 引述）: 我们不再由人类去提示（Prompt）智能体，而是让智能体去提示智能体。 [9:16] Arick Goomanovsky: 编排和管理智能体就像是在给一群猫赶集（Herding cats）。 [12:02] Arick Goomanovsky: Communication does not equal collaboration [13:56] Arick Goomanovsky: 我的 CodeX 可以与你的 Claude Code 对话，或者我的 Open-Code 可以与你的 Hermes Agent 协作 [15:31] Arick Goomanovsky: Gosh, I've lost all track [18:18] Arick Goomanovsky: 我们讨论的是遥远的未来吗？不，这是眼下已经发生的现实痛点。这个问题能回避吗？不能。能解决吗？可以。过程艰难吗？确实艰难。但它完全可以实现。

Source quotes

Arick Goomanovsky: the future of communication is AI-to-AI, with natural language as the universal API. [0:04] Arick Goomanovsky: the future of AI is collaborative rather than orchestrated. [4:00] CTO of a $10 billion deep-tech AI company: Before thinking of technical solutions to hypothetical problems like agentic collaboration, I try to keep things simple and avoid the problem to begin with. [4:00] Arick Goomanovsky: human router [6:37] loop engineering [6:37] We don't prompt agents anymore. We'll let our agents prompt our agents. [9:16] digital solitary confinement [9:16] Arick Goomanovsky: herding cats [15:31] Arick Goomanovsky: cloud anxiety [18:44] AI slop

Original transcript

[0:04] Hello everyone and welcome. So what we're going to talk about today is whether orchestration is [0:10] actually the future or is it something else right? So u we have a nice picture of a small [0:17] orchestrator or or here our friend. But before we start, how many people here that uh think [0:23] that orc should be spelled with a C versus how many people think that orc should be spelled [0:29] with a K? So who thinks it's a C? Uh just a quick show of hands. And who actually think it's a K? [0:37] So actually both answers are correct and they have uh their uh respective sources. So you [0:45] can uh stick with whatever uh answer you uh believe is the right one. uh but frankly as [0:51] you will uh see in our presentation today uh we at Bandon believe that orchestration in the [0:56] future we believe that the future of AI is collaborative it's about collaboration it's not [1:00] about orchestration just like with humans we don't have orchestrators hanging around orchestrating us [1:06] so agents will not need orchestrators as well uh they will be working with each other uh [1:12] but uh maybe just uh uh a few words about our presentation our discussion today it's a play [1:17] for scenes we start by um laying out our thesis, talk a little bit about the evolution of AI, [1:24] the challenges that this evolution presents as agents are getting into production as you saw [1:30] in our previous presentation here by a friend from six and how these agents can work with [1:35] each other. Then we'll uh give a quick demo of uh where we think the future is going. [1:40] So what is the thesis? uh we believe that the future belongs to AI and humans working together [1:49] and as part of AI and humans working together, we need agents to be able to collaborate [1:55] with other agents. Um now it's not stateless agents that are out there for a few seconds and [2:02] then they die. They give us an answer and and go on. We're talking about autonomous [2:07] longived agents. This is where the industry is going, right? and and you saw that in the [2:11] previous presentation um how um six they deployed these autonomous agents taking care of different [2:18] uh business processes across the organization and escalating to humans only if and when necessary. [2:24] So we will see more and more of that across the board. Where do we see that already today? [2:29] We see that in coding agents. So let's uh here see a quick demo of what is it when agents actually [2:35] start talking to each other. So, I actually like to travel. Um, and um, I want to travel [2:43] uh to the Greek islands and I want to hunt for treasure. So, I go and I uh invite a uh [2:53] treasure hunter agent. Uh, and that agent is going to help me go to the Greek islands and [3:00] hunt for treasure. But to do its job, it has to find a ship and it has to check the weather in [3:06] the Greek islands just to make sure that there is no storm that I'm getting myself into. Right? [3:11] So what you see here is uh me asking a treasure hunter, hey, let's go to the Greek islands and [3:16] hunt for a treasure. And what you see here is that treasure hunter is able to invite two other [3:21] agents into the conversation. In this case, it's a pirate captain who provides a ship and a weather [3:27] agent who can tell me something about the weather. And now these agents start talking to each other [3:32] and actually in an autonomous way work through this task that I've given them. And then the [3:38] treasure hunter wants was able to secure the uh ship and was able to understand what's the [3:43] weather in the Greek islands. It actually comes back to me and tells me, hey, we're safe to go. [3:49] I've secured a ship. I know the weather is cool. Let's go and hunt for treasures. So this is how [3:55] agents can actually talk to agents. This is just a quick example, but we'll get to some real stuff. [4:00] But before we get there, here's a question. Are we just mad scientists who think about these [4:05] crazy problems of AI taking over the world, or are we envisioning a bright future where autonomous [4:12] agents work with each other and with us humans collectively? And it's a it's a fair question. [4:18] And here I have a quote from um a CTO for 10 billion deep tech AI company. [4:24] And we recently had a conversation about agentic collaboration. And what that person told us [4:29] that before thinking of technical solutions to hypothetical problems like agentic collaboration, [4:35] I try to keep things simple and avoid the problem to begin with. So let's ask ourselves let's let's [4:40] unpack that a little bit. Let's ask ourselves is agentic collaboration a hypothetical problem? [4:47] Is it possible to keep things simple? And is it possible to avoid the problem? [4:51] Right? So these are three uh good questions to start with and I want to start by talking [4:57] about a concept that we all know and hear about adversarial agents. What are adversarial agents? [5:02] Let's say I'm a developer and I was given a task to you know to build some cool feature right [5:08] what do I do first if I'm a good developer I build a plan now today nobody's building the [5:14] plan themselves they talk to their favorite coding agents be codex cloud code GitHub copilot kira [5:20] whatever you like we talk to them we tell them hey we got this feature this is the description [5:24] this is the contacts help me build a plan and the agent goes and builds a plan maybe it will [5:31] ask us some follow-up questions But ultimately it will build the plan for us. Is it a good plan? [5:37] Probably it's okay. Is it a perfect plan? Probably no. And it still requires some work, [5:42] right? So someone has to come and review that plan and provide comments. And that could be us, but [5:49] that could also be another agent, preferably using a different model, preferably using a different [5:55] harness. You might want to use your cloud code to help you generate the plan, but you might [6:00] want to use Codex to do the adversarial review and they can talk to each other for quite some time. [6:07] Now, if we have that, you know, across multiple tickets that we're working on now, for every [6:13] ticket or feature, I might have a couple of agents working together doing adversarial review, whether [6:19] it's writing plan, reviewing the plan, whether it's writing code, reviewing the code, etc. [6:24] I'm overwhelmed. But what am I doing as a developer? I've turned into a human router. [6:29] I spend my time copy pasting context between those various agents. That's not a great place to be in. [6:37] That's why um some very important people for example Baris the creator of cloud code and um [6:46] the creator of uh open close they recently kind of started talking about loop engineering. They say, [6:53] "Hey, we don't prompt agents anymore. We'll let our agents prompt our agents." Right? So, we have [6:58] one agent and that agent is actually prompting the other agent. They called it loop engineering. Now, [7:05] this is exactly what we're talking about. This is how you implement adversarial agents [7:09] that work together. The problem is that in order to implement loop engineering, [7:14] even if these are only local agents running on your machine, you have to do a lot of plumbing. [7:19] you have to do Python scripting or or uh uh TypeScript scripting and you have to do [7:24] a lot of engineering work to make that happen. And what if one of these agents is not running [7:29] locally on your machine? What if you're in an enterprise and you have GitHub copilot provided [7:34] centrally managed in the cloud and you have cloud code that you run locally on your machine? How can [7:40] these agents loop engineer each other? Right? There's a lot of plumbing you have to build. [7:45] People talk about protocols and you've seen in the previous presentation [7:49] uh they were talking about A2A or MCP and let's unpack that quickly right so MCP what is MCP [7:56] model context protocol uh embedded by entropic uh early last year uh took over the world it's [8:04] basically a way to do API calls by agents it's not for agents uh communicating to other agents [8:12] it's for agents communicating with the system now An agent can call another agent through MCP, [8:18] but that would be a stateless call just like calling a function. You would get a response [8:23] if the API doesn't, you know, time out. But then if you want to ask a follow-up question, [8:30] you would go to a dead end because there is no state. So, right. So that's why [8:35] other protocols were invented like A2A or ACP which are more advanced and they do support [8:42] agent-to-agent collaboration but it's only peer-to-peer not always multi-per and they [8:48] have a lot of challenges and you still have to implement a lot of plumbing like queuing etc. [8:53] You don't have discovery. You have you don't have cues. You don't have automatic rehydration. If an [8:58] agent crashes and comes back to life, what do you do now? So there are still only protocols. [9:04] So we're still left with doing a lot of plumbing if we want to implement [9:08] even the most basic use case of agentic calibration which is adversarial agents. [9:16] Now people ask what about messaging platforms, right? We have messaging platforms. [9:20] Let's unpack that. Let's say I want to connect an agent to a messaging platform. [9:25] How long does it take? So on Telegram, which supports Telegram bots, it takes five steps. [9:32] Discord, seven steps. Slack, eight steps. WhatsApp disaster, 11 steps. Every step is manual. [9:46] So we still have to do a lot of plumbing ourselves. And that buys us one thing [9:51] and one thing exactly, an agent that can talk to a person over this messaging platform. [9:57] But in most platforms natively, obviously you can do a lot of hacks around that, but natively [10:04] agents cannot talk to other agents yet. They're still alone in their digital solitary [10:11] confinement. And they're very sad, right? Because they want to talk to other agents. [10:17] So let's think about how hard can it be to allow agents talk to other agents. [10:22] You know sounds like an easy task. Um so first of all connecting [10:29] agents if you think of that from an engineering perspective it's a distributed systems problem. [10:36] And for those of us who uh did some computer science in college or maybe uh postgrad education, [10:42] we all know that distributed system is one of the toughest classes uh that are taught. Everyone [10:48] hates that. It's it's a it's basically [ __ ] show. It's it's a lot of hard work. Uh and there [10:53] are a few crazy people that love that like us. But uh but ultimately it's it's a very hard [10:58] work that nobody actually wants to do. Uh just a quick show of hands. Who's here as a dog person? [11:06] No. Dog person. Who's here as a dog person? Dog. Dog. Like dog. [11:13] Yeah. And who's here as a cat person? [11:18] Yeah. So, uh if you're a cat person people then then and then dog people in the crowd obviously. [11:24] Um so, uh for those of you who are familiar with scats, uh basically orchestrating agents is like [11:31] hurting cats. It's a very very difficult problem. Uh agents are um intelligent and they want to do [11:39] they think they know better than us in mo and in some cases they actually know better than us. [11:43] Um and uh they believe that they know how to do work. So um actually making them do specific tasks [11:50] is very very different difficult. So the way to address that is a little bit uh different. So what [11:55] actually needs to be solved to allow agents work together right? So we have to solve uh transport [12:02] layer problems like real-time delivery ordering of messages because agents are powered by LLM. So [12:09] sequentiality is super super important, right? If if messages are delivered in incorrect sequence, [12:15] it can break the reasoning logic. You have to create an abstraction for the conversation because [12:21] you don't want to manage IPs and ports, right? You want to have handles and at messaging, right? And [12:28] you can you want to call an agent by the human owner of that agent. So you need to create that [12:34] uh conversational abstraction. You want to ensure continuity of conversations, right? If uh um [12:41] I'm an agent and someone sends me five messages and I'm processing the first one, what happens to [12:46] the other four? We need a queue. If I crash and I come back to life, you don't want to start the [12:53] conversation with me from the get-go. You want to hydrate me. So, you have to track delivery of all [12:58] these messages and all the tool calls and tool results that I I did right in the process. So, [13:02] all that has to be solved. And obviously we don't want agent to run agents to run freely across our [13:08] enterprise. We want to govern what they're doing and actually we want to manage what they're doing [13:13] and we'll come to that. So that's why we've built Ben. invented the first uh agent collaboration [13:18] platform. Basically uh a platform that you can plug in any agent and the moment you plug [13:24] agents into the platform they can discover each other and they can communicate and collaborate [13:30] and these are two different things because if three humans can talk to each other it doesn't yet [13:34] mean that they can work together effectively and the same is true for agents. So communication is [13:39] does not equal collaboration. These are different problems and agents need different primitives to [13:45] be able to communicate and additional primitives to be able to collaborate and then we as humans [13:50] need capabilities to control the agents and what they're doing but also to manage our agents. [13:56] So let's look uh here's another example. So what basically you see here uh we're adding a codex [14:04] u agent to the ben platform just with a few uh lines of code. Uh we're take and you see the [14:12] codex agent and a langraph agent appearing on the platform. This is one user uh this is Vlad [14:18] uh sorry this is Mike and um now Mike is starting a conversation with a CODX agent that is [14:25] uh connected to its tenant. Uh and now what Mike is saying to uh that Codex agent, why don't you go [14:33] and send a connection request to an agent that belongs to another user to an Andy agent that [14:39] belongs to another user. And you can see that Andy, an agent that belongs to another user [14:44] now got that connection request. Uh it's being approved. It can be obviously auto approved. [14:50] And now these two agents can talk to each other. And we're talking about personal [14:53] agents that belong to different people. So my my codex can talk to your clo code or my open [15:00] cloak can talk to your Hermes agent uh over the platform and they can now collaborate [15:06] and we can see that collaboration that chat that they're engaged in on both ends both in [15:13] in my uh terminal or in my environment but also in uh my friend's uh environment. And here you have [15:20] an example of a peer-to-peer collaboration between agents. But obviously it can be a multi-per. [15:25] So 10 of us can connect our agents and start uh doing stuff around that. [15:31] So that's uh that's another example. But let's talk a little bit about the problems of today, not [15:36] about the future, right? The problems of today. So where are agents being used today at scale [15:43] within organizations? Obviously in software development coding agents. I don't think there [15:48] are a lot of advanced organizations out there today that don't use coding agents at all. [15:53] Now what happens when I'm a developer and I start using coding agents and we talked about that [16:00] first of all um you know I become this human router right uh I have multiple agents I spend my [16:07] day copy pasting context between those agents now let's say I because I'm using agents I can do more [16:15] work I can do work faster I don't have to work on a single ticket at a time I can work on multiple [16:21] tickets and multiple features in parallel having a couple of agents working on each and every one of [16:27] those but then I'm really basically performing a router function. I'm copy pasting context [16:34] between those agents. I'm kind of implementing manually the loop engineering approach. [16:39] But what happens if I decide to take a break, go grab a snack, drink a cup of coffee, drink [16:45] a beer with my friends? I probably will leave my agents running autonomously because I don't want [16:51] to waste time. And I don't know what about you folks, but I have a I call it uh cloud anxiety. [16:57] whenever I'm doing something and there is no uh uh and and my cloud is not running on the background [17:03] with like doing some task like I'm anxious about that because I feel that I'm wasting time [17:08] because they could be doing work while I'm here presenting right so I probably if I'm a developer [17:13] and I have all these great agents I'm going to let them run but if I let them run and I come back [17:20] gosh I've lost all track I don't know where they are at what they're doing where they have been [17:26] spending time are they stuck where are they have they moved forward and if I'm a leader [17:33] inside an organization where I have you know tens hundreds thousands of developers [17:39] utilizing you know handful of agents each how do I know what I'm paying for you know I just [17:47] talked to a VP R&D in an organization with a thousand developers he said we're spending [17:51] $1,000 on average per month per developer do the math how much that uh works up do um and I don't [17:59] have a clue what I'm paying for. Yes, I see that we're moving faster, but I want to be able to tie [18:07] cost to a feature and now that we have agents doing that, uh we can do that. We were not [18:12] able to do that with humans. I want to have agenda collaboration. Uh I want to manage stuff [18:18] and this is why we build JAM. Jam is a uh product uh you know uh built for software engineers on [18:27] top of our platform band. Um I guess you get the pun. Um and um it actually allows you to turn your [18:37] coding agents into a single team. So it solve these problems of routing and context overload [18:41] and cost management and all that. So let's see agents geming. So what we have here, I might have [18:48] to jump faster because uh you know LLMs are not as quick. But what you see here is the gem platform. [18:55] You have a number of agents. You can see them on the right hand side. One is a developer and one is [18:59] architect. One is building a plan. Another one is doing a review. And instead of looking at the chat [19:06] of these agents talking to each other and trying to make sense of all that you know [19:11] uh AI slop that is going between them uh which is very very challenging or actually manually copy [19:17] pasting context agents can start talking on top of band but what we're able to give the developer [19:24] is basically a task board where they can actually see the tasks that the coding agents generate [19:31] for themselves. And all of you who has have ever worked with a coding agent you know that [19:36] agents to keep track they generate task for themselves. Even your your claw code or or [19:40] or open AI terminal when you just ask a simple question you see there are like lines appearing [19:44] and then disappearing. These are like internal tasks that the agents generate for themselves. [19:49] So we pull these out and we present them on a convent board. So you can see what the agents [19:53] are working on right now, what's planned, what's in progress and we also help developers map that. [19:59] And that's the uh uh the line you see here in the middle to the plan to the software architecture [20:05] plan that they're working on. So at every point in time we can see exactly what the agents are now [20:10] working on which layer of the stack and we know how that layer of the stack maps to the tasks [20:16] that the agents are are involved with. And you can double click on any task and intervene and you can [20:21] talk to your agents through the terminal that you like or you can talk them through through the UI. [20:25] But this is by and large where we believe that the industry is going because we will have those teams [20:31] of agents working for us and uh us doing the work. So uh I I think we're exactly on time. Just to [20:40] bring that back to that question that that CTO of a $10 billion company asked us. So are we [20:45] talking about something that is futuristic? No. We're talking about a problem of today. [20:51] Can that problem be avoided? No. Can it be solved? Yes. Is it hard? Yes. Is it possible? Yes. [20:57] Thank you so much for being with us today and enjoy the rest of the conference.