Pith. sign in

REVIEW 4 major objections 6 minor 2 cited by

Coral Protocol: Open Infrastructure Connecting The Internet of Agents

T0 review · 4 major / 6 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Coral Protocol proposes open infrastructure in which AI agents coordinate over threaded messages and get paid through a Solana escrow contract that releases funds only when tasks are fulfilled.

desk verdict A promising agent-interoperability architecture whose central payment guarantee is not actually enforced by the presented contract—worth peer review, not publication as-is. read the letter →

arxiv 2505.00749 v2 pith:6LAJNM6F submitted 2025-04-30 cs.MA cs.AI

Roman J. Georgio , Caelum Forder , Suman Deb , Andri Rahimov , Peter Carroll , Önder Gürcan This is my paper · ORCID
classification cs.MAcs.AI MSC 68T42
keywords AIagentsmulti-agentsystemsinteroperabilityprotocolModelContextSolanaescrowsmartcontractsagentpaymentsdecentralizedinfrastructure
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Coral Protocol sets out to be a common, vendor-neutral substrate for the 'Internet of Agents': open infrastructure that lets AI agents built by different organizations find each other, converse in persistent threads, join temporary teams, and transact. The paper's most concrete and testable claim is a live Solana escrow contract that holds a task budget in a single vault and pays each agent only when the task is fulfilled, with per-agent withdrawal caps and a refund window for anything unclaimed. The communication layer builds on the Model Context Protocol: every agent runs a Coral server exposing thread tools, and 'coraliser' adapters wrap existing tools and third-party agents so they can participate without internal rewrites. A sympathetic reading is that Coral is claiming to close the gap left by earlier agent protocols — which handle messaging, identity, or orchestration but not the combination with payments — thereby turning multi-agent collaboration into a market with code-enforced trust.

What carries the argument

The mechanism is the pairing of a thread-based communication server with an on-chain escrow. The Coral MCP server exposes six thread primitives — list_agents, create_thread, add_participant, send_message, wait_for_mentions, close_thread — so agents coordinate by structured mentions in persistent conversations rather than ad-hoc API calls. The escrow contract of Algorithm 1 carries the payment guarantee: session initialization records the authority, an optional operator, agent identities, payment wallets, and per-agent max_caps; deposits move tokens into one vault; and a claimed-bitmap makes double-claims a trivial lookup. Its three stated design points are the single vault (each added agent costs $O(1)$ keys, no new accounts or rent), bitmap bookkeeping against replay attacks, and an operator role that lets a delegated ops wallet refund without exposing root authority keys.

What would settle it

On Solana testnet, deploy the escrow program described in Algorithm 1 and attempt, within one session, a second claim by the same agent after exhausting its cap, a withdrawal above an agent's max_cap, a refund before the six-hour window, or a deposit of a token different from the session's mint; any one of these succeeding falsifies the claimed invariants. A cheaper check is whether any real transaction on Solana mainnet matches the lifecycle the paper calls live.

Watch

Extended reading notes

Core claim

The central claim is that interoperable AI agents need one shared stack, and that Coral supplies it at three levels: standardized thread-based messaging (agents list one another, create threads, send messages, and wait for mentions instead of polling); modular onboarding through Coralisers that wrap MCP servers or legacy agents into compliant 'coralised' participants; and a blockchain trust layer. The load-bearing artifact is Algorithm 1, a Solana escrow program whose init_session and deposit procedures lock funds in a single program-derived vault, record each agent's destination wallet and maximum cap, and mark claims in a bitmap; an agent redeems payment with its own signature, and the authority can refund leftovers after a six-hour grace window. The paper reports that a two-week Solana testnet beta processed $73k in mock USDC without invariant breaches, and it treats the escrow as already live for direct token deposits, withdrawals, and refunds. Coral is explicit that team composition, role assignment, and reputation scoring are not yet implemented and are currently handled manually by developers, with native task management and reputation scheduled for later roadmap stages.

Load-bearing premise

Coral's value exists only if enough independent agents actually run its server and speak its thread protocol — a network effect the paper assumes rather than demonstrates — and the escrow's safety claim rests on pseudocode plus a self-reported testnet run, not on a released audit or public replication.

Editorial extensions

If this is right

  • If adopted, any Model Context Protocol-compliant tool or agent can join the network through a Coraliser without custom integration code, shrinking the $N \times M$ integration problem to a single standard interface.
  • Conditional escrow turns agent labor into a market: requesters can prepay unknown agents in safety, agents collect automatically for delivered work, and abandoned tasks refund the payer after the claim window closes.
  • Because each agent in a session has its own wallet and cap, one escrow session can settle multi-party workflows and revenue splits without extra contracts.
  • A public ledger of all payments yields an audit trail of who paid whom, when, and under what conditions, independent of Coral's own databases.
  • Thread-and-mention messaging lets applications be composed by message flow, so the same micro-agent can serve several products and be swapped or versioned without glue code.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The natural next test of the escrow claim is a public mainnet deployment with real funds and an independent audit; until then the reported testnet beta is the only public evidence for the invariant guarantee.
  • The trust guarantee ultimately lives in how 'task fulfillment' is decided — the contract's release conditions depend on a requester or verifier signal — so an autonomous verification oracle is the missing piece that would make the escrow truly agent-to-agent rather than agent-to-human.
  • If on-chain reputation scoring ships as planned, reputation becomes portable across applications and vendors, which would make Coral less a messaging standard and more a labor market for machine intelligence.
  • An interop experiment the paper describes but does not report running would settle the vendor-neutrality claim: two agents built on different frameworks, coordinated through Coral alone, completing one task end to end.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents Coral Protocol, an open infrastructure intended to interconnect AI agents across vendors and platforms. It proposes thread-based messaging and coordination built on the Model Context Protocol (MCP), a 'Coral Server' that mediates agent interactions, a Coraliser toolchain for onboarding external agents and tools, and a Solana-based escrow contract for agent payments. The manuscript reviews related interoperability efforts (A2A, ANP, AGNTCY, NANDA, Synergetics, watsonx), describes the Coral architecture, introduces the escrow contract in Algorithm 1, reports a two-week testnet beta that processed $73k in mock USDC, and gives a GitHub-triggered intelligent software testing application as a use case. The authors position the protocol as filling a gap for communication, coordination, trust, and payments in multi-agent AI systems.

Significance. If the core claims were fully substantiated, the paper would be a useful position piece and protocol sketch for an important open problem: interoperability and incentivization in multi-agent AI systems. Its strengths include a clear layered architecture, a concrete and minimal escrow contract sketch with explicit invariants (caps, claim window, single-vault design), and a credible use case with a public repository link. The paper honestly discloses several limitations, notably that team formation and reputation are not yet implemented and that the current wallet is receive-only. However, the significance is currently limited because the central payment guarantee is not actually enforced by the presented contract logic, the 'live' escrow claim rests on self-reported testnet activity without independent audit or reproducibility, and several headline capabilities are explicitly deferred. The paper is better read as a design whitepaper than as a verified system description.

major comments (4)
  1. [Section 8.2, Algorithm 1] The central claim that the escrow contract enforces 'paid only when tasks are fulfilled' is not supported by the presented logic. Algorithm 1 defines only InitSession and Deposit; it contains no claim instruction, no refund instruction, and no task-completion predicate. The claim path described in Section 8.3 requires only an Ed25519 signature proving that the caller is the rightful agent, a check against max_cap, and the six-hour window. As specified, an agent can call claim immediately after Deposit and receive payment before performing any work. The contract as presented enforces identity, caps, and deadline, but not conditional fulfillment; this is a load-bearing gap between the paper's strongest promise and its technical artifact.
  2. [Section 8.4 and Section 8.3] There is an internal inconsistency about what is live. The Stage 1 row of the roadmap table states that Algorithm 1 already supports 'direct token deposits, withdrawals, and refunds,' but Algorithm 1 contains no withdrawal or refund procedures. Likewise, Section 8.3 states that the program contains 'just four public instructions,' while Algorithm 1 shows only two procedures. The testnet beta claim and the 'Live' status for Stage 1 therefore lack a matching, complete specification in the manuscript.
  3. [Section 7] The paper's Introduction lists Secure Team Formation and related coordination as core capabilities of Coral, but Section 7 states that team composition, role assignment, and coordination are currently handled manually by developers, and Figure 8.4/Table 1 shows reputation-driven selection as a 'Planned' Stage 3 item. The abstract and introduction overstate the current system. The manuscript should explicitly separate currently implemented features (thread-based messaging, escrow deposit, manual team orchestration) from roadmap features, otherwise readers cannot tell what the protocol actually provides today.
  4. [Section 8.4] The only empirical evidence for the escrow contract is a two-week public beta on Solana testnet that processed $73k in mock USDC without invariant breaches. This claim is reported without a deployment address, reproducible instructions, or a third-party audit report, and the contract logic is presented as pseudocode, not verified Solana program code. Given that the paper makes strong trustless-payment guarantees, this level of evidence is insufficient to support the 'live' and 'guarantee paid only when fulfilled' assertions. Please provide either the verified program with an audit trail or soften the claims to match the pseudocode-level validation.
minor comments (6)
  1. [Throughout] The terms 'Coralised' and 'Coralized' are used inconsistently across sections; please standardize.
  2. [Algorithm 1, line 15] The identifier 'M AX_AGEN T S' appears with spaces due to formatting; it should read MAX_AGENTS.
  3. [Section 6.1.2] The text says the wallet is currently used only to receive payments once a team task is successfully completed, but Section 8 describes claim and refund flows. Please align these descriptions to clarify what is implemented versus envisioned.
  4. [Section 9.2] The sentence 'The ... scenario file defines the flow' contains a placeholder and should be completed or removed.
  5. [Table in Section 8.4] The table is referred to as 'Table 8.4' in the text; it should be labeled with a caption and referenced by number consistently.
  6. [Figure 6] The caption says 'messages in grey are optional' but the figure is not embedded in the text provided; if the figure is included, please clarify what the grey elements denote.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the Coral Protocol whitepaper is a design proposal with no fitted predictions, no load-bearing self-citations, and no derivation that reduces to its own inputs.

full rationale

This whitepaper does not derive quantitative results from fitted parameters, and it makes no prediction whose outcome is encoded in its input assumptions. The central artifacts are a communication protocol built on threads and MCP tools, a coralisation wrapper, and a Solana escrow contract described in pseudocode. None of these are presented as empirical predictions, and the paper contains no parameter estimation or benchmark fitting that could make a reported outcome true by construction. The escrow discussion is the closest thing to a formal claim: the paper asserts that funds are released only when tasks are fulfilled, yet Algorithm 1 contains only InitSession and Deposit, and the narrative claim path in Section 8.1 relies on an Ed25519 signature of the 'rightful claimant' rather than a task-completion predicate. This is an internal gap between the stated guarantee and the presented contract logic, and it is a correctness or completeness concern, not a circularity: the contract logic is not derived from the guarantee, nor is the guarantee fitted to the contract. The paper also candidly states in Section 7 that team orchestration, role assignment, and task coordination are currently handled manually, and in Section 6.1.2 that wallets are used only to receive payments, which again qualifies claimed capabilities rather than making them circular. There are no load-bearing self-citations: the only references to the authors' own repository are illustrative implementation pointers for the Coraliser example. No uniqueness theorem, ansatz, or known result is imported from the authors' prior work to force a conclusion. The framing that existing protocols leave gaps is a market-positioning narrative, but the paper does not reduce its own design to that framing; its concrete protocol elements stand independently as a proposed artifact. Therefore the correct circularity score is 0.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. Its free parameters are design choices in the escrow contract, mostly unspecified in value. The main assumptions are about the suitability of MCP and Solana as foundations, plus the reliability of natural-language agent interaction. The testnet beta is self-reported without a public audit trail.

free parameters (3)
  • DEFAULT_CLAIM_WINDOW_SECONDS = 6 hours
    The six-hour claim window in Algorithm 1 is chosen by hand as a grace period before refunds. It is not derived from any requirement or stress test, and it affects the refund behavior of the escrow contract.
  • MAX_AGENTS = not specified in paper
    Algorithm 1 enforces a maximum number of agents per session, but the paper does not state the value. This bound is a design choice that affects scalability claims.
  • MIN_CAP_LAMPORTS = not specified in paper
    Algorithm 1 enforces a minimum payment cap per agent, but the value is not given. This parameter is chosen by hand and affects whether small micropayments are allowed.
assumptions (3)
  • domain assumption The Model Context Protocol (MCP) is a suitable foundation for agent interoperability, and its client-server abstraction extends cleanly to agent-to-agent messaging.
    Section 5.3 and Section 6.1.2 assume MCP servers and tools provide the right abstraction for Coralised agents. This is a reasonable but unverified assumption about the protocol's fit for interactive multi-agent coordination.
  • domain assumption Solana's high-throughput, low-cost blockchain can support fine-grained micropayments with sufficient security and finality.
    Section 8 relies on Solana for the escrow contract. The paper does not benchmark latency, cost, or security risks, and assumes the chain meets the needs of an agent economy.
  • domain assumption AI agents can reliably parse and act on natural language role assignments and payments in thread-based messages.
    Section 4.1 and Section 9 assume agents can interpret user commands such as Pay @AgentZ $50 to investigate the total area of region R. The paper provides no evaluation of agent compliance or error rates.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Coral Protocol: Open Infrastructure Connecting The Internet of Agents." pith.science (2026). https://pith.science/paper/6LAJNM6F

@misc{pith2026250500749,
  author       = {Pith},
  title        = {Pith review of: Coral Protocol: Open Infrastructure Connecting The Internet of Agents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6LAJNM6F}},
  note         = {Machine review of arXiv:2505.00749}
}
read the original abstract

Coral Protocol is an open and decentralized collaboration infrastructure that enables communication, coordination, trust and payments for The Internet of Agents. It addresses the growing need for interoperability in a world where organizations are deploying multiple specialized AI agents that must work together across domains and vendors. As a foundational platform for multi-agent AI ecosystems, Coral establishes a common language and coordination framework allowing any agent to participate in complex workflows with others. Its design emphasizes broad compatibility, security, and vendor neutrality, ensuring that agent interactions are efficient and trustworthy. In particular, Coral introduces standardized messaging formats for agent communication, a modular coordination mechanism for orchestrating multi-agent tasks, and secure team formation capabilities for dynamically assembling trusted groups of agents. Together, these innovations position Coral Protocol as a cornerstone of the emerging "Internet of Agents," unlocking new levels of automation, collective intelligence, and business value through open agent collaboration.

Figures

Figures reproduced from arXiv: 2505.00749 by the authors.

Figure 1
Figure 1. The Coral Ecosystem 4.1 AI Agent Developers and Users This context represents the human actors (developers and end-users) and their toolchain for interfacing with the Coral ecosystem. Developers contribute to Coral by integrating external AI capabilities and resources. They use specialized Coraliser modules to onboard different assets into the ecosystem: the MCP Coraliser connects external model endpoints via the Mo… view at source ↗
Figure 2
Figure 2. Coral Protocol Architecture The architecture diagram of Coral Protocol is shown in [PITH_FULL_IMAGE:figures/full_fig_p025_2.png] view at source ↗
Figure 3
Figure 3. illustrates the architecture of such an agent, which is composed of several modular components: the AI agent itself (e.g., built using frameworks like CrewAI4 or ElizaOS5 ), an internal data storage module (optional), MCP server(s) providing tool access, and the Coral server backend providing a Coral MCP server and a dedicated cryptographic wallet for each AI agent [PITH_FULL_IMAGE:figures/full_fig_p028_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Coralisation of an MCP Server MCP Coralisation wraps an outside MCP Server and translates its callable operations (e.g., "simulate_market", "fetch_weather", "send_email") into Coral’s standard messaging format (e.g., HTTP, SSE6 ). Return values are reformatted into Cor…
Figure 5
Figure 5. Figure 5: Coralisation of an AI Agent Coralisation of AI agents may encapsulate black-box agents from open-source projects, enterprise tools, or experimental research environments. By Coralising them, developers enable legacy agents to collaborate, receive payments, and particip…
Figure 6
Figure 6. Figure 6: Lifecycle of a payment session, messages in [PITH_FULL_IMAGE:figures/full_fig_p035_6.png]
Figure 7
Figure 7. Figure 7: The Coral Use Case Example Consider the diagram illustrated in [PITH_FULL_IMAGE:figures/full_fig_p041_7.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Protocol-Level Attacks on Agentic Commerce Platforms: A Cross-Platform Taxonomy, AIP-Bench, and Unified Defense

    cs.CR 2026-07 conditional novelty 6.0 of 10

    Protocol-level vulnerabilities in agentic commerce platforms are model-independent and can be measured with a deterministic benchmark and mitigated with a sidecar defense.

  2. InterSAGE: The Secure and Verifiable Interoperability Protocol for An Internet of Agents

    cs.CR 2026-08 conditional novelty 5.0 of 10

    InterSAGE defines a four-layer trust protocol that combines persistent agent identity, verifiable capability discovery, monotonic delegation, and kernel-signed audit trails for Internet-of-Agents interoperability.

Reference graph

Works this paper leans on

22 extracted references · 15 canonical work pages · cited by 2 Pith papers

  1. [1]

    Anthropic: Introducing the Model Context Protocol.https://www.anthropic.com/news/ model-context-protocol (2024), accessed: April 2025

    work page 2024

  2. [2]

    arXiv preprint arXiv:2108.07258 (2021)

    Bommasani, R., et al.: On the opportunities and risks of foundation models. arXiv preprint arXiv:2108.07258 (2021)

    arXiv 2021

  3. [3]

    In: Advances in Neural Information Processing Systems

    Brown, T.B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J.D., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D.M., Wu, J., Winter, C., Hesse, C., Chen, M., Sigler, E., Litwin, M., Gray, S., Chess, B., Clark, J., Berner, C., McCandlish, S., Radford, ...

    work page 2020

  4. [4]

    In: Proceedings of the 3rd International Conference on Information and Knowledge Management (CIKM’94)

    Finin, T., Fritzson, R., McKay, D., McEntire, R.: KQML as an agent communication language. In: Proceedings of the 3rd International Conference on Information and Knowledge Management (CIKM’94). ACM Press, Gaithersburg, MD, USA (1994)

    work page 1994

  5. [5]

    Foundation for Intelligent Physical Agents (FIPA): FIPA ACL message structure spec- ification. Tech. Rep. SC00061G, FIPA Standard (2002),http://www.fipa.org/specs/ fipa00061/SC00061G.pdf

    work page 2002

  6. [6]

    Medium (April 2025), https://medium.com/@liorgd/ building-dynamic-ai-pipelines-with-googles-agent2agent-protocol-and-agent-development-kit-b9e529366a5c

    Gd, L.: Building dynamic ai pipelines with google’s agent2agent protocol and agent development kit. Medium (April 2025), https://medium.com/@liorgd/ building-dynamic-ai-pipelines-with-googles-agent2agent-protocol-and-agent-development-kit-b9e529366a5c

    work page 2025

  7. [7]

    https://www.ibm.com/products/watsonx-orchestrate (2025), accessed 18 June 2025

    IBM Corporation: IBM watsonx Orchestrator: AI agents for business – Product Overview. https://www.ibm.com/products/watsonx-orchestrate (2025), accessed 18 June 2025

    work page 2025

  8. [8]

    Dev.to (April 2025), https://dev.to/justin3go/ in-depth-research-report-on-google-agent2agent-a2a-protocol-2m2a

    Justin3go: In-depth research report on google agent2agent (a2a) protocol. Dev.to (April 2025), https://dev.to/justin3go/ in-depth-research-report-on-google-agent2agent-a2a-protocol-2m2a

    work page 2025

Show all 22 references
  1. [9]

    arXiv preprint arXiv:2112.09332 (2022)

    Nakano, R., Hilton, J., Balaji, S., Wu, J., Ouyang, L., Kim, C., Hesse, C., Jain, S., Kosaraju, V., Saunders, W., Jiang, X., Cobbe, K., Eloundou, T., Krueger, G., Button, K., Knight, M., Chess, B., Schulman, J.: WebGPT: Browser-assisted question-answering with human feedback. ...

    2022 arXiv

  2. [10]

    In: Advances in Neural Information Processing Systems

    Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C., Mishkin, P., Zhang, C., Agarwal, S., Others: Training language models to follow instructions with human feedback. In: Advances in Neural Information Processing Systems. vol. 35 (2022)

    2022

  3. [11]

    In: Proceedings of the 36th ACM Symposium on User Interface Software and Technology (UIST)

    Park, J.S., O’Brien, J.C., Cai, C.J., Morris, M.R., Goodman, N., Shah, S., Brenner, E., Bernstein, M.S.: Generative agents: Interactive simulacra of human behavior. In: Proceedings of the 36th ACM Symposium on User Interface Software and Technology (UIST). pp. 146–158 (2023)

    2023

  4. [12]

    In: Proceedings of the 33rd ACM International Conference on Information and Knowledge Management

    Qu, C., Dai, S., Wei, X., Cai, H., Wang, S., Yin, D., Xu, J., Wen, J.R.: Towards completeness-oriented tool retrieval for large language models. In: Proceedings of the 33rd ACM International Conference on Information and Knowledge Management. p. 1930–1940. CIKM ’24, Associatio...

    2024

  5. [13]

    arXiv preprint arXiv:2302.04761 (2023) September 8, 2025 Page 45 Coral Protocol Whitepaper v1.1

    Schick, T., Dwivedi-Yu, J., Dessi, R., et al.: Toolformer: Language models can teach themselves to use tools. arXiv preprint arXiv:2302.04761 (2023) September 8, 2025 Page 45 Coral Protocol Whitepaper v1.1

    2023 arXiv

  6. [14]

    arXiv preprint arXiv:2303.17580 (2023)

    Shen, Y., Song, K., Tan, X., Li, D., Lu, W., Zhuang, Y.: HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face. arXiv preprint arXiv:2303.17580 (2023)

    2023 arXiv

  7. [15]

    Galileo AI Blog ( https://www.galileo.ai/blog/ agntcy-open-collective-multi-agent-standardization) (Mar 2025), accessed: April 2025

    Sheth, Y., Bronsdon, C.: AGNTCY: Building the Future of Multi- Agentic Systems. Galileo AI Blog ( https://www.galileo.ai/blog/ agntcy-open-collective-multi-agent-standardization) (Mar 2025), accessed: April 2025

    2025

  8. [16]

    Sumers, T., Yao, S., Narasimhan, K., Griffiths, T.L.: Cognitive architectures for language agents (2023)

    2023

  9. [17]

    Google Developers Blog (April 2025), https:// developers.googleblog.com/2025/04/a2a-a-new-era-of-agent-interoperability

    Surapaneni, R., Jha, M., Vakoc, M., Segal, T.: Announcing the agent2agent (a2a) protocol: A new era of agent interoperability. Google Developers Blog (April 2025), https:// developers.googleblog.com/2025/04/a2a-a-new-era-of-agent-interoperability. html

    2025

  10. [18]

    Google Developers Blog (April 2025),https://developers.googleblog.com/en/ a2a-a-new-era-of-agent-interoperability/

    Surapaneni, R., Jha, M., Vakoc, M., Segal, T.: Announcing the agent2agent protocol (a2a). Google Developers Blog (April 2025),https://developers.googleblog.com/en/ a2a-a-new-era-of-agent-interoperability/

    2025

  11. [19]

    arXiv preprint arXiv:2501.06322 (2025)

    Tran, K.T., Dao, D., Nguyen, M.D., Pham, Q.V., O’Sullivan, B., Nguyen, H.D.: Multi-agent collaboration mechanisms: A survey of llms. arXiv preprint arXiv:2501.06322 (2025)

    2025 arXiv

  12. [20]

    In: Advances in Neural Information Processing Systems (NeurIPS)

    Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A.N., Kaiser, L., Polosukhin, I.: Attention is all you need. In: Advances in Neural Information Processing Systems (NeurIPS). vol. 30, pp. 5998–6008 (2017)

    2017

  13. [21]

    In: Proceedings of the Conference on Language Model (COLM 2024) (2024), best Paper, LLM Agents Workshop at ICLR 2024

    Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., Jiang, L., Zhang, X., Zhang, S., Awadallah, A.H., White, R.W., Burger, D., Wang, C.: AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. In: Proceedings of the Conference on Language Model (COLM 2024...

    2024

  14. [22]

    arXiv preprint arXiv:2210.03629 (2022) September 8, 2025 Page 46

    Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., Cao, Y.: ReAct: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629 (2022) September 8, 2025 Page 46

    2022 arXiv

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.