PaperlayerView exact revision on arXiv

Source-linked AI summary

Kiko: Programming Agents to Enact Interaction Protocols

Samuel H. Christie, Munindar P. Singh, Amit K. Chopra

arXiv:2606.26156v1cs.MA

TL;DR

Existing agent programming models provide weak abstractions for decentralized decision making and do not adequately connect internal logic with public decisions. Kiko uses decision makers and a protocol adapter to structure agent behavior around protocol roles while abstracting communication. Its formal results establish protocol compliance and the ability to realize any reachable protocol enactment, with limitations including atomic decision-maker execution and reliance on a protocol specification language.

  • Problem

    Existing agent programming models poorly abstract decentralized decision making and fail to adequately bridge internal decision logic with public decisions.

  • Method

    Kiko structures agents around protocol roles, decision makers, and a generic adapter that applies protocol semantics to business decisions and message emissions.

  • Results

    Kiko guarantees protocol-compliant agents and provides decision makers capable of simulating any reachable protocol enactment under the stated message-reception assumption.

  • Takeaways & Limitations

    Kiko lets agent developers focus on business decisions while the adapter handles protocol-valid communication and compatibility.

  • Takeaways & Limitations

    Kiko’s current semantics execute decision makers atomically, while concurrent execution would require additional validity checks for conflicting emission sets.

Abstract

from arXiv · show

Realizing a multiagent system involves implementing member agents who interact based on a protocol while making decisions in a decentralized manner. Current programming models for agents offer poor abstractions for decision making and fail to adequately bridge an agent's internal decision logic with its public decisions. We present Kiko, a protocol-based programming model for agents. To implement an agent, a programmer writes one or more decision makers, each of which chooses from among a set of valid decisions and makes mutually compatible decisions on what messages to send. By completely abstracting away the underlying communication service and by supporting practical decision-making patterns, Kiko enables agent developers to focus on business logic. We provide an operational semantics for Kiko and establish that Kiko agents are protocol compliant and able to realize any protocol enactment.

1 Introduction

Kiko is a decision-oriented programming model for decentralized multiagent systems whose agents enact protocols through private decision logic and public message decisions. It abstracts communication details while supporting protocol compliance, practical decision-making patterns, and formal guarantees about protocol enactments.

  • 1 Introduction: Agents implement protocol roles by using private decision logic that produces public decisions as messages.For example, sellers choose quotes and buyers accept quotes according to their business logic.
  • 1 Introduction: Traditional protocol languages and agent programming models constrain flexibility by focusing on message ordering and limited interaction patterns.The paper identifies this as a challenge for separating business logic from communication components.
  • 1 Introduction: Kiko’s decision makers select and make sets of currently available, mutually compatible decisions for an agent’s protocol roles.The programmer’s primary task is to write these decision makers.
  • 1 Introduction: Kiko abstracts away the communication service and supports correlation, cross-enactment reasoning, emission sets, and multiprotocol reasoning.Decision making does not require handling the order in which messages are received, and message emission is handled transparently.
  • 1 Introduction: Kiko formalizes its programming model and proves soundness and completeness with respect to possible protocol enactments.The model is intended to guarantee compliant behavior while retaining the ability to realize valid enactments.

2 Information Protocols Introduced

Kiko adopts BSPL information protocols, which define roles, messages, and information constraints rather than message ordering. These constraints govern when emissions are valid through causality and integrity requirements.

  • 2 Information Protocols Introduced: BSPL specifies protocol roles, messages between roles, and information constraints that determine valid message emissions.It uses information causality and integrity rather than ordered message delivery.
  • 2 Information Protocols Introduced: The Purchase protocol assigns Buyer and Seller roles and permits RFQ, Quote, Buy, and Reject messages with specified parameters.RFQ goes from Buyer to Seller, Quote returns to Buyer, and Buy or Reject completes the interaction.
  • 2 Information Protocols Introduced: Information integrity prevents conflicting bindings within the same protocol enactment, with key parameters identifying message instances and enactments.A Quote that changes an already bound item would violate integrity.
  • 2 Information Protocols Introduced: Information causality requires in parameters to be known before emission, while out parameters must be newly bound and nil parameters must remain unknown.These adornments constrain which message instances an agent can send from its local history.
  • 2 Information Protocols Introduced: In the Purchase example, Seller must know item before sending Quote, thereby producing a binding for price.The protocol’s parameter line also supports composition with other protocols.

3 The Kiko Programming Model

Kiko separates agent decision logic from protocol enforcement through decision makers and a generic protocol adapter. The adapter exposes valid forms, validates emission attempts, and supports decentralized enactment over asynchronous communication.

  • 3 The Kiko Programming Model: The architecture separates programmer-provided MAS information and decision makers from Kiko’s generic protocol adapter and the communication service.The adapter understands information protocols and provides the decision-maker API; the implementation uses unordered, unreliable UDP.
  • 3 The Kiko Programming Model: Kiko can enact BSPL protocols over unordered, lossy transport because protocol validity constrains message emission and message reception is idempotent.TCP or ordered message queues are therefore not required for correct enactment under these semantics.
  • 3 The Kiko Programming Model: A decision maker fills the out parameters of enabled message forms, while the adapter validates and emits the resulting instance set.An inconsistent attempt is rejected as a whole rather than partially emitted.
  • 3 The Kiko Programming Model: Decision makers can generate multiple RFQs or choose between Buy and Reject forms based on observed history and business conditions.For example, Bob can bind RFQ identifiers and items, then choose Buy when a quoted price is acceptable or Reject otherwise.
  • 3 The Kiko Programming Model: The adapter rejects emission sets containing incompatible instances, preventing noncompliant emissions even when each instance is individually valid.Buy and Reject are mutually exclusive in the same enactment because both bind done.
  • 3 The Kiko Programming Model: Event-based invocation avoids polling and can directly locate an enactment from communication-event keys, while custom events support decisions outside message reactions.This supports both reactive and batch-oriented behavioral patterns.

3.1 Decision-Making Challenges and Solutions

Kiko supports decision making across concurrent and unrelated protocol enactments while preserving compatible, flexible message emissions. Its information-based adapters can absorb protocol changes without necessarily requiring changes to agents’ decision logic.

  • Correlation: Kiko automatically derives correlated forms and lets decision makers coordinate communications across concurrent protocol enactments.Correlated forms can be found using identifiers such as Buy-form IDs.
  • Cross-enactment reasoning: Kiko exposes forms from all active contexts together, enabling an agent to choose a Buy for the lowest-priced Quote across multiple systems.This supports cross-enactment reasoning when an agent participates in several instances of a protocol.
  • Multiprotocol reasoning: Kiko lets agents map information between unrelated protocols, such as requesting Approval for each Purchase through a separate Approval protocol.Decision makers can access forms from all protocols the agent is enacting concurrently.
  • Emission sets: Emission sets atomically emit multiple mutually compatible messages and emit none when the set conflicts, allowing coordinated decisions across contexts.This supports combinations such as Buys with Rejects or front-end Deliver messages with back-end Reorder messages.
  • Flexible reception: Kiko receives messages as they arrive and exposes resulting forms to decision makers, allowing flexible responses without requiring message reception order.In the Rescind example, an arriving Rescind disables the matching Buy before the decision maker considers it.
  • Loose coupling: Because Kiko is information-based, protocol changes do not necessarily require changes to an agent’s decision-making logic.Indirect bank transfer can change how Seller receives payment while leaving Seller’s emitted messages and decision logic unchanged.

3.2 Adapter Implementation

Kiko’s adapter mediates between decision makers, protocol constraints, local history, and the communication service. It computes enabled forms incrementally and validates both emissions and receptions before updating the agent’s history.

  • Adapter architecture: Figure 2 expands the adapter to show its internal components, including the Local Store, Enablement, Checker, Emitter, and Receiver.The adapter’s components support protocol enactment between programmer-provided decision makers and the communication service.
  • Adapter architecture: The Emitter and Receiver send and receive messages through the communication service, while the Local Store records the agent’s emission and reception history.The Checker validates protocol constraints before accepted messages enter the Local Store and proceed through the architecture.
  • Validation: Send-Check accepts an emission set only when every message is enabled and the set satisfies out- and nil-compatibility constraints.A passing check makes the set a valid extension of the agent’s history.
  • Validation: Receive-Check accepts a message only when it is receivable, consistent with the history, and out-compatible; otherwise integrity validation discards it.Valid received instances extend the agent’s history.
  • Enablement: For each context, Enablement incrementally computes the forms the agent can send using newly observed information and shared key bindings.The computation checks whether schema out and nil parameters have already been satisfied.

4 Operational Semantics

Kiko’s operational semantics formalize MAS states, transitions, protocol matching, and simulation to establish correctness and completeness. The semantics also support an optimized decision rule that checks internal compatibility rather than full validity.

  • The semantics model message reception, delivery, and decision-based emission, with invalid emissions producing no transition.Receive requires input availability, non-duplication, and validity; Decide derives instances from enabled forms and adds valid emissions to history and output.
  • MAS states are sets of agent histories, and reachable states are those produced by sequences of transitions under the operational semantics.
  • A MAS state simulates a protocol enactment when it matches the enactment and every transition reaches a state matching a finitely reachable extension.
  • Every reachable state of a MAS implementing a protocol simulates some reachable protocol enactment, establishing operational-semantic correctness.
  • Decide2 is equivalent to Decide because enabled forms remain valid during atomic transitions, so selected emissions only require internal compatibility checking.The optimized rule can avoid rechecking consistency with the agent’s history.
  • The semantics are complete: suitable decision makers can simulate any reachable protocol enactment, assuming all sent message instances are received.This establishes that the operational semantics themselves do not restrict reachable enactments, not that every implementation is complete.

5 Discussion

Kiko connects declarative business decisions to protocol-constrained communication while supporting information-based features and decentralized deployment. Its discussion identifies tradeoffs in concurrency and boundaries involving norms, performance evaluation, microservices coordination, and environment events.

  • Kiko lets agents provide business decisions while an adapter applies protocol semantics to determine viable messages.Its causal information semantics captures information flow without requiring generated guards.
  • Kiko’s discussion identifies open directions for norms-based decisions, microservice coordination, and environmental events that do not map naturally to messages.Examples include commitments, accountability protocols, loose-coupled microservices, and sensing shipment arrival.
  • Kiko can operate directly over unordered, unreliable services such as UDP, but its performance against traditional architectures remains to be established.The paper cites preliminary high-performance evidence from Mandrake and PoT, not Kiko itself.
  • Kiko supports correlation, cross-enactment reasoning, multiple protocols, and atomic emission sets that can span protocols and agents.These features rely on querying information, while emission sets provide atomic multi-message decisions.
  • Concurrent decision-maker execution could exploit multicore and cloud architectures, but conflicting emission sets would require more expensive validity checks.The current atomic semantics simplifies internal compatibility checking by executing decision makers with respect to the history.
  • Kiko’s appendix and software are available in supplementary material.The repository is linked in the paper.
Loading 2606.26156v1…