Ahoy: LLMs Enacting Protocol Interactions

• AHOY is a framework for LLM agents that dynamically selects and enacts declarative interaction protocols in multiagent systems, emphasizing BSPL semantics.
• It decouples protocol constraint enforcement via a Kiko adapter from LLM-based domain reasoning, enabling message selection and parameter binding without specialized training.
• The framework supports concurrent protocols and branching interactions, demonstrated through efficient enactment in e-commerce, health, and finance scenarios.

Searching arXiv for the target paper and closely related uses of “AHOY” for disambiguation. AHOY denotes a framework for LLM agents that dynamically select and enact declarative interaction protocols in multiagent systems, with the explicit goal of achieving user goals without specialized training and without protocol-specific programming. In the formulation introduced by "Ahoy: LLMs Enacting Multiagent Interaction Protocols" (Joshi et al., 3 Jun 2026), an Ahoy agent takes a user goal in natural language, uses a Kiko adapter to maintain protocol state and expose enabled messages, and delegates message selection and parameter binding to a general-purpose LLM whose reasoning is bounded by protocol constraints. The central claim is that the same agent can correctly enact multiple BSPL protocols, including concurrent enactments and branching protocols, while preserving BSPL constraints through adapter-side enforcement rather than model-side memorization (Joshi et al., 3 Jun 2026).

1. Problem setting and motivation

An interaction protocol in a multiagent system specifies the interaction constraints that autonomous agents must respect. In sociotechnical systems such as e-commerce, health, and finance, each agent represents a real-world principal, and no agent is subordinate to a central controller. The paper situates Ahoy in this decentralization-oriented setting, where protocol semantics matter because coordination cannot be reduced to centralized orchestration (Joshi et al., 3 Jun 2026).

The protocol language emphasized in Ahoy is BSPL, described as a declarative, information-based language specifying roles, messages, and parameter constraints. Declarative protocols support asynchronous, flexible interactions, enable higher-level meaning such as commitments, and are amenable to formal verification and model checking prior to adoption (Joshi et al., 3 Jun 2026). This combination of decentralization and formal semantics is the background against which Ahoy is positioned.

Historically, protocol-based agents have required protocol-specific coding. Programming models such as Kiko can structure an agent’s reasoning around messages sent and received, but developers still write decision makers per protocol and role. The paper treats this as the principal bottleneck: agent logic becomes tied to particular message schemas and flows, which limits generality and reuse (Joshi et al., 3 Jun 2026).

Ahoy addresses that bottleneck by separating two concerns. Constraint enforcement is delegated to an adapter that tracks protocol state and validates candidate messages; domain reasoning is delegated to an LLM that does not require BSPL pretraining. This suggests a shift from handcrafted per-protocol control logic toward a reusable execution substrate in which a new declarative protocol can alter interaction behavior without source code modification (Joshi et al., 3 Jun 2026).

2. BSPL protocol semantics and enactment model

Ahoy’s protocol substrate is the Blindingly Simple Protocol Language (BSPL). A BSPL protocol defines roles, message schemas, and parameters, where each message schema specifies a sender role, a receiver role, and the parameters that are transmitted (Joshi et al., 3 Jun 2026).

A central semantic device is the parameter adornment system:

• in: the sender must already know the binding before sending; the value is obtained from prior messages.
• out: the sender generates a new binding upon sending; it appears once per enactment and remains immutable in that enactment.
• nil: the sender must not know the binding; this supports mutually exclusive paths by preventing emission once certain bindings exist (Joshi et al., 3 Jun 2026).

Key parameters uniquely identify an enactment instance, and there is at most one enactment per unique key binding. An agent’s local state consists of the role history together with the set of bindings established so far. In BSPL, an enactment is a complete assignment of bindings to all parameters in all messages, satisfying all adornment constraints (Joshi et al., 3 Jun 2026).

The paper uses Purchase as a running example:

Purchase: Purchase { roles Buyer, Seller, Shipper parameters out ID key, out item, out price, out outcome private address, resp, shipped, satisfaction Buyer -> Seller: rfq[out ID,out item] Seller -> Buyer: quote[in ID, in item, out price] Buyer -> Seller: accept[in ID, in item, in price, out address, out resp] Buyer -> Seller: reject[in ID, in item, in price, out outcome, out resp] Seller -> Shipper: ship[in ID, in item, in address, out shipped] Shipper -> Buyer: deliver[in ID, in item, in address, out outcome] Buyer -> Seller: completed[in ID, in item, in price, out satisfaction] }

This specification illustrates several properties that matter for Ahoy. First, information causality is encoded directly in message schemas: for example, quote depends on an ID and item already established by rfq. Second, out parameters such as ID introduce bindings that persist through the enactment. Third, role termination can be inferred from the protocol specification; for the Buyer in Purchase, termination occurs upon sending completed (Joshi et al., 3 Jun 2026).

Additional protocols in the evaluation include Logistics and FlexiblePurchase. FlexiblePurchase is particularly significant because it uses nil adornments to enforce mutually exclusive branching delivery paths. The framework therefore does not merely support linear message chains; it supports protocol-level branching where exclusion is represented declaratively rather than procedurally (Joshi et al., 3 Jun 2026).

3. Architecture, prompting, and execution loop

Ahoy is organized into three modules: Role Selection Module, Prompt Builder, and LLM Access Function. Its design explicitly decouples protocol constraint enforcement from LLM reasoning (Joshi et al., 3 Jun 2026).

The Role Selection Module presents available protocols and roles, allows selection of one or more protocol-role pairs, infers role termination conditions, maps user natural language input to a user goal, and configures the Kiko adapter with the multiagent system configuration (Joshi et al., 3 Jun 2026). In the current formulation, role selection is user-driven rather than automatic.

The Prompt Builder constructs two prompt types. The system prompt, built once per enactment, contains BSPL semantics, assigned protocol roles, tool interfaces and calling conventions, event-handling instructions, annotated protocol specifications, and the user goal. The user prompt, built per decision event, contains role-specific message history, the current enabled-message set, parameter adornments, and any external event context (Joshi et al., 3 Jun 2026). The paper stresses that models need no BSPL pretraining because BSPL semantics are explained in the prompt.

The LLM Access Function is registered as an adapter callback and is triggered on decision events, namely message arrival, enabled-message set changes, or external events such as JSON events from an Inventory Management System. It calls the LLM, parses the returned selection and parameter bindings, and returns selected message instances to the adapter. The adapter then validates and emits messages over the network, enforcing all BSPL constraints before emission (Joshi et al., 3 Jun 2026).

This execution pattern is illustrated by the response schema given in the paper. To choose an option, the model returns JSON of the form:

{"choice": 0, "params": {"ID": "value", "item": "value"}, "tool_requests": []}

To decline all options, it returns:

{"choice": null, "params": {}, "tool_requests": []}

Tool use is supported through locally implemented functions. The LLM may emit tool_requests, which the runtime executes and then feeds back to the model. The example in the paper includes a request to save_state_to_memory, indicating that Ahoy can support iterative reasoning mediated by tool outputs rather than a single-shot message choice (Joshi et al., 3 Jun 2026).

The runtime itself is an event loop. Initialization selects protocols and roles, instantiates the Kiko adapter, registers the LLM Access Function, and builds the system prompt. During enactment, Kiko monitors local state; when a decision event occurs, Ahoy rebuilds the user prompt from adapter state, the LLM selects messages and bindings, the adapter validates and emits them, and Ahoy updates termination conditions per role (Joshi et al., 3 Jun 2026).

Several invariants are explicit. Constraint enforcement is centralized in the adapter. Decision-making is bounded to enabled messages and current state. Bindings do not leak across protocols. Termination conditions are enforced independently per role (Joshi et al., 3 Jun 2026). These invariants are the mechanism by which the paper distinguishes intelligent reasoning from unconstrained prompt-based conversation.

4. Protocol enactment patterns and evaluated scenarios

The paper evaluates Ahoy in several representative scenarios: a single-protocol Purchase enactment, concurrent enactment of multiple protocols and roles, flexible branching in FlexiblePurchase, and external-event handling during an ongoing enactment (Joshi et al., 3 Jun 2026).

In the end-to-end Purchase example, the Buyer’s user goal is: “I want to buy a pen with a budget of $20 and have it delivered to 123 Main St, Raleigh, NC 27606.” The sequence proceeds through rfq, quote, accept, ship, deliver, and completed. The reported behavior is that Ahoy correctly propagates in bindings, generates out bindings, and terminates the Buyer role upon completed. The evaluation reports that Purchase was enacted in 20 seconds, with 4 LLM calls, and that RFQs and quotes were processed with acceptance of the lowest price (Joshi et al., 3 Jun 2026).

The concurrent multi-protocol scenario configures Ahoy to play Purchase:Buyer and Logistics:Merchant concurrently. The user input specifies three procurement tasks and two redistribution orders. The observed trace contains 20 message instances in total: 10 Purchase and 10 Logistics. The paper emphasizes three findings: independent binding sets, independent termination, and constraint preservation. Purchase binds three IDs while Logistics binds two orderIDs, with no leakage across protocols. Purchase:Buyer terminates on completed, while Logistics:Merchant terminates on receiving packed. The reported metrics are 20 messages total, 20 LLM calls, 2 concurrent roles, and 70 seconds elapsed (Joshi et al., 3 Jun 2026).

In FlexiblePurchase, Ahoy must select between standard_delivery_request and express_delivery_request, while nil adornments ensure mutual exclusion once a branch is chosen. Three scenarios are reported:

• Urgent Delivery: selects express_delivery_request; 35.23 seconds, 3 LLM calls.
• Cost-Conscious: selects standard_delivery_request; 35.24 seconds, 3 LLM calls.
• Ambiguous Input: selects standard as a reasonable fallback; 35.26 seconds, 3 LLM calls (Joshi et al., 3 Jun 2026).

Across these scenarios, the paper states that adornment constraints, including nil, were preserved, and that once a path was selected the enactment advanced along that branch without deadlocks or exceptions (Joshi et al., 3 Jun 2026).

In the external event scenario, Ahoy is already enacting Purchase as Buyer for a pen when an external JSON event—“Purchase Request: Buy a trolley” with metadata including address and budget $29.99—is injected into the queue. The observations reported are that Ahoy incorporates external event context starting from the second decision, handles both transactions in parallel, and uses the same LLM Access Function for protocol and event decisions without special branching code. The scenario completes in 13.99 seconds, with 6 LLM calls and 6 messages sent (Joshi et al., 3 Jun 2026).

Taken together, these scenarios are used to support four evaluated capabilities: programming freeness, concurrent participation, intelligent path selection, and handling external events, all under preservation of BSPL constraints via adapter enforcement (Joshi et al., 3 Jun 2026).

5. Evaluation claims, comparative position, and engineering significance

The evaluation environment reported for Ahoy uses Anthropic’s Claude Haiku 4.5. Across all reported enactments, the paper makes four aggregate claims: no malformed message instances were emitted, no BSPL adornment violations occurred, no adapter-level constraint exceptions were triggered, and no proposed message was rejected by the Kiko adapter (Joshi et al., 3 Jun 2026).

Representative quantitative results reported in the paper are summarized below.

Scenario	Reported result	Salient observation
Purchase	20 seconds; 4 LLM calls	Accepted lowest price
Logistics	63.55 seconds; 11 LLM calls	Coordinated labels and wrapping
Multi-protocol concurrency	20 messages; 70 seconds; 20 LLM calls; 2 roles	Independent terminations
FlexiblePurchase branching	~35.2 seconds; 3 LLM calls	Correct branch selection
External events	13.99 seconds; 6 messages; 6 LLM calls	Parallel handling of transactions

The paper places Ahoy against several existing families of systems. Hard-coded agents, including imperative tool invocation frameworks such as LangChain and scripted multiagent conversations such as AutoGen, are described as having fixed roles and communication patterns, so that adding coordination structures requires code or prompt changes and lacks principled protocol semantics (Joshi et al., 3 Jun 2026). A2A (Agent2Agent) is described as a delegation protocol with orchestrated interactions and a constrained communicative act, namely “delegate,” which the paper regards as unsuitable when agents represent autonomous principals that cannot simply delegate tasks (Joshi et al., 3 Jun 2026).

Against these alternatives, Ahoy’s distinctive position is that each BSPL message schema is a distinct communicative act, protocols are formal, information-based, and verifiable, and loading a new declarative protocol suffices to change interaction patterns without source code modification (Joshi et al., 3 Jun 2026). The significance attributed to this architecture is improved knowledge engineering through the decoupling of formal interaction constraints from LLM-based decision-making.

A plausible implication is that Ahoy should be understood less as a prompt-engineering pattern than as a hybrid execution framework in which protocol semantics remain first-class runtime objects. The paper’s emphasis on model checking, local state, enabled messages, and adapter validation supports that interpretation (Joshi et al., 3 Jun 2026).

6. Practical use, limitations, and disambiguation

The paper includes concrete guidance for extension. To author a new protocol, one defines it in BSPL syntax, including roles, message schemas, parameters, private parameters, and in/out/nil adornments; provides the multiagent system configuration to the Kiko adapter; and annotates the protocol with comments describing each message, because Ahoy incorporates these annotations into prompts (Joshi et al., 3 Jun 2026).

Configuration then proceeds through the Role Selection Module, where protocol-role pairs are selected and termination conditions are inferred at initialization. User goals are supplied in natural language, and no user knowledge of BSPL or Kiko is required. For tool integration, local tools such as save_state_to_memory are implemented and documented in the system prompt; the LLM Access Function executes tool calls and returns outputs to the model for iterative reasoning. External event sources such as JSON queues can be connected directly, and Ahoy treats external events as separate transactions (Joshi et al., 3 Jun 2026).

Prompt design is treated as an engineering concern rather than an incidental implementation detail. The system prompt should include BSPL semantics, assigned roles, tools, event-handling guidance, annotated protocol specifications, and the user goal. The user prompt should include role-specific history, enabled messages, parameter adornments, and external event context, while remaining concise enough to fit context windows (Joshi et al., 3 Jun 2026).

The limitations are explicit. The evidence is limited to the evaluated scenarios, and the paper calls for rigorous evaluation with baselines and ablations. Automatic role selection from user input remains future work because roles are currently user-selected. The authors also propose testing with models of varying sizes and vendors, and suggest that in-context learning, fine-tuning, and reinforcement learning could improve performance. A further open issue concerns human-agent alignment, particularly when agents should seek user confirmation before creating new commitments rather than merely discharging existing ones (Joshi et al., 3 Jun 2026).

Because the acronym AHOY has appeared in unrelated arXiv contexts, disambiguation is warranted. In this usage, Ahoy refers to the multiagent-protocol framework introduced in (Joshi et al., 3 Jun 2026), not to the remote-sensing ship detector CHPDet paper whose title includes “Ahoy!” only as an exclamation (Zhang et al., 2021), nor to "AHOY! Animatable Humans under Occlusion from YouTube Videos with Gaussian Splatting and Video Diffusion Priors" (Mir et al., 18 Mar 2026). In current arXiv usage, the unqualified term is therefore ambiguous across at least these distinct research areas, but the multiagent-systems meaning is the one defined by the title "Ahoy: LLMs Enacting Multiagent Interaction Protocols" (Joshi et al., 3 Jun 2026).