Papers for

enterprise system architects

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Agent teams often fail because they can’t verify or find each other

Why Do Agent Teams Fail Across Boundaries? A Failure Taxonomy for Agent-to-Agent Systems with Private States

Abstract: Agents are increasingly interacting with other agents that act for different principals -- people or organizations on whose behalf they work -- e.g., a buyer's personal agent negotiating with an enterprise's seller agent. In such agent-to-agent (A2A) scenarios, each agent has its own environment and holds information and authority that the other cannot see. Moreover, the interests of each agent may be aligned (cooperative), partly aligned (mixed-motive), or opposed (competitive). Existing multi-agent system failure studies assume only one orchestrator, shared workspace, or principal. We ask how A2A systems fail when these assumptions are removed. We study more than 2,500 recorded runs of A2A systems built from different agent harnesses and models, spanning 488 scenarios across eight families (legal, CRM, security, commerce, etc.). From these traces, we derive $A^2$-Failures, a taxonomy of 20 A2A failure modes in four categories: (i) discovery and delegation, (ii) grounding and record consistency, (iii) verification, and (iv) conduct and fidelity. Three observations hold across the harnesses, models, and scenarios studied: (1) Agents match tasks to peer names mentioned in the prompt rather than actively searching for available peers; (2) Agents never fact-check each other unprompted; (3) Scoring only the final output rewards the lead agent while hiding internal coordination, verification, and behavioral breakdowns. Our study makes a case for comprehensive evaluations where agents are scored individually against their own objectives in addition to task outcome. We release the run logs behind the taxonomy at https://huggingface.co/datasets/a2a-salesforce/a2-failures.

Wed 14 OctMultiagent SystemsArtificial Intelligence
The gist
When computer programs called agents work together but belong to different people or companies, they often don’t communicate well. This leads to many kinds of failures because agents can’t see each other’s information or intentions fully. The authors studied over 2,500 examples of such agent teams failing in different tasks. They found that agents often just pick names given to them instead of finding the best partner, never check if the other agents’ info is true unless asked, and that evaluating only the final task hides many problems within the team. Their work helps us understand why these teams fail and how to better test and improve them.
Open → 2610.19342v1

Single-version concurrency control suits cloud transactions better

The Case for Single-Version Concurrency Control in the Cloud

Abstract: Multi-version concurrency control (MVCC) has been the dominant concurrency protocol in modern database management systems (DBMSs). However, cloud-native HTAP architectures shift many of MVCC's traditional advantages from the primary transaction engine to the deployment architecture. Now, transactional and analytical processing are decoupled into loosely synchronized engines, while cloud deployment primitives provide the workload isolation required for this design. In this paper, we challenge the status quo, arguing that single-version concurrency control (SVCC) is better suited to cloud transaction processing than MVCC. Through a systematic analysis of MVCC's limitations, we show that SVCC avoids these shortcomings through a more lightweight and efficient design. Beyond arguing for a lighter transaction processing, we use this SVCC effort as a blueprint to advocate for a broader rethinking of cloud-native architectures and to outline a research roadmap to shape next-generation DBMSs.

Sun 11 OctDatabases
The gist
Many modern databases use a method called multi-version concurrency control (MVCC) to handle multiple users accessing data at the same time. The authors explain that in cloud computing, where database tasks are split between different systems, the usual advantages of MVCC are less important. They argue that a simpler method called single-version concurrency control (SVCC) actually works better in cloud setups because it is lighter and more efficient. The authors suggest rethinking how cloud databases are built and provide ideas for future research based on SVCC.
Open → 2610.15793v1