---
title: 'Ahoy: LLMs Enacting Protocol Interactions'
url: https://www.emergentmind.com/topics/ahoy
type: topic
---

# Ahoy: LLMs Enacting Protocol Interactions

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" [2606.05390], 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 [2606.05390].

## 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 [2606.05390].

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 [2606.05390]. 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 [2606.05390].

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** [2606.05390].

## 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 [2606.05390].

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 [2606.05390].

**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 [2606.05390].

The paper uses **Purchase** as a running example:

```text
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` [2606.05390].

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 [2606.05390].

## 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** [2606.05390].

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 [2606.05390]. 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 [2606.05390]. 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 [2606.05390].

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

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

To decline all options, it returns:

```json
{"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 [2606.05390].

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 [2606.05390].

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** [2606.05390]. 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 [2606.05390].

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** [2606.05390].

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 `orderID`s, 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** [2606.05390].

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** [2606.05390].

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** [2606.05390].

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** [2606.05390].

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** [2606.05390].

## 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** [2606.05390].

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 [2606.05390]. **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 [2606.05390].

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** [2606.05390]. 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 [2606.05390].

## 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 [2606.05390].

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** [2606.05390].

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 [2606.05390].

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 [2606.05390].

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 [2606.05390], not to the remote-sensing ship detector **CHPDet** paper whose title includes “Ahoy!” only as an exclamation [2101.11189], nor to **"AHOY! Animatable Humans under Occlusion from YouTube Videos with Gaussian Splatting and Video Diffusion Priors"** [2603.17975]. 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"** [2606.05390].

Source: https://www.emergentmind.com/topics/ahoy