Re: Toward Engineering Agentic Systems Based on Interaction Protocols

Thanks for the links!
This model of MAS provides answers to most of my questions in the previous
thread about fail-safeness of the concurrent computation involved in a
decentralised network. It could be a good starting point (as FIPA) for a
"layer 0" for LLMs to work on top of it.

Some questions:

Have you considered attaching a piece of syntax for semantic referencing
(links to public ontologies)? An LLM may find it difficult to parse a
message into a context without the semantic linking or links to NL
documents from which to assess a context. Also, for example, different
markets (in the case of the buy-sell example in the papers) may apply
different nuances to a transaction that are not embeddable using a formal
language, thus the more expressive hints provided by the semantic linking
that the LLM can leverage. For example: parameters adornments could
leverage semantic linking to explain themselves to a context reader that
can dereference the link and go acquire its description.

Would it be an easy implementation to have a mapping between the protocol
and existing standards for Web (HTTP, RPC) payloads and formats (JSON-LD,
W3C Hydra)? While for lower levels efficiency is priority, for a shared
layer interoperability takes priority.

Notes for the sake of the discussion:
* the protocol described looks like Protobuffer at first sight. This
implies providing an ecosystem of parsers and validators, LLMs are usually
good at porting natural languages to formal specification (provided by the
authors in the Gitlab repo). One of the first things I would try is some
context engineering to develop an agent for accurate translation from
protocols to NL.
* it is quite compact but may require too much overhead to learn and too
much preparation to be interpreted, this makes it less human readable than
a NL description. There is too much syntax involved as required by the
machine-readability but it doesn't mean an LLM cannot handle it correctly
and bypass this overhead.
* the main blocker with formal languages in my opinion is that they are an
arbitrary pick among possibilities so they require to be widely accepted in
usage, thing that may require too much consensus-building costs to be
accepted by the majority of industry-players, while NL is already there for
every player doing the job and can be leveraged for a standard. But again,
if the process of translation between NL and the protocol is effortless...
If we accept this point of view, *the best protocol may be the one
optimised for accurate translation from machine-readable to NL*.
* the papers already provide a verifiable concurrency model, very important.
* My take at first reading, this solution can be a good intermediate
representation at some layer of the stack that does the translation into a
machine readable layer (similar to FIPA).
* In my experience causality in human-machine interaction is too wide of a
concept to be covered by a formal implementation. Maybe LLM will be a good
pick to let agents infer causality from semantic clues mixed in with formally
structured data about the flow of information. In the paper a narrow
definition of causality is given, good for machine readable messages but
maybe too narrow for the "open-endedness" of NL-based systems and all the
possible occurrences of meaning (again, this can be improved using
semantic referencing/dereferencing).
* keep in mind that once a standard is in place, it will be possible to
test if LLMs themselves can generate client/server implementations in a
given language/tool; so defining client servers parsers and tooling in
general may take less work than doing it via traditional software
engineering.

In general adding an "LLM-aware layer 0" to a formal protocol (like BSPL in
the papers or FIPA) would require:
1. Maps Natural Language to Protocol Parameters: Use LLMs to extract
structured information (parameters) from unstructured agent messages or
user input. This should be quite straightforward for an LLM but the
protocol may need semantic annotations to infer contexts from messages.
2. Enforces Protocol Semantics: The layer checks that the information
dependencies and causality constraints of the BSPL protocol are respected,
ensuring agents only send messages when required inputs are available.
Again, this could be difficult to assure for every LLM on the market if the
protocol is too complex.
3. Handles Meaning and Commitments: LLMs can interpret or generate
explanations of the protocol’s business meaning, commitments, or
intentions, providing transparency and facilitating negotiation or
clarification between agents. This is the main advantage of using NL-based
systems and also what makes their leverage on software so convenient.
4. Supports Protocol Composition: For more complex interactions, the layer
can use LLM reasoning to compose or decompose protocols dynamically, this
may happen at the machine readable level or at the NL level (or it is
possible to decide they should happen at one and only level to avoid
mismatch in translations).

No.2 is the most challenging in my opinion considering all the challenges
already evident in alignments for the many LLMs on the market.

Hope these can help the discussion.

On Sun, Jul 6, 2025, 22:50 Amit Chopra <akchopra.mail@gmail.com> wrote:

> Dear all
>
> It's great to see interest in applying approaches developed in the
> multiagent systems (MAS) community toward building Agentic systems.
>
> My colleagues (Munindar Singh, Samuel Christie, and Matteo Baldoni) and I
> have been working on approaches for specifying interaction protocols
> between agents.  Our approaches are formal and declarative; support
> interaction meaning (which facilitates intelligent decision making by
> agents); and enable realizing loosely-coupled, decentralized systems of
> asynchronously communicating agents.  Moreover, our approaches support
> maximally flexible interactions between agents.  These features make our
> approach, which we call Interaction-Oriented Programming (IOP), ideally
> suited to the Agentic paradigm.
>
> Below are some papers describing our approach.
>
> 1. (AAMAS) The BSPL Protocol language:
> https://www.csc2.ncsu.edu/faculty/mpsingh/papers/mas/AAMAS-11-IBIOP.pdf
> 2. (AAMAS) BSPL Semantics and Verification:
> https://www.csc2.ncsu.edu/faculty/mpsingh/papers/mas/AAMAS-12-BSPL.pdf
> 3. (Services Computing) Methodology for specfiying protocols:
> https://www.csc2.ncsu.edu/faculty/mpsingh/papers/mas/SCC-14-Bliss.pdf
> <https://www.csc2.ncsu.edu/faculty/mpsingh/papers/mas/SCC-14-Bliss..pdf>
> 4. (JAIR) Advantage of our approach over alternative protocol
> specification approaches, both formal and informal:
> https://www.lancaster.ac.uk/staff/chopraak/pdfs/langeval..pdf
> <https://www.lancaster.ac.uk/staff/chopraak/pdfs/langeval.pdf>
> 5. (AAMAS) A Python programming model for BSPL:
> https://www.lancaster.ac.uk/staff/chopraak/pdfs/Kiko.pdf
> 6. (JAAMAS) A programming model for fault tolerance:
> https://www.lancaster.ac.uk/staff/chopraak/pdfs/mandrake.pdf
> 7. (IJCAI) Efficient verification:
> https://www.csc2.ncsu.edu/faculty/mpsingh/papers/mas/IJCAI-21-Tango.pdf
> 8. (AAAI) A belief-desire-intention programming model for BSPL:
> https://www.lancaster.ac.uk/staff/chopraak/pdfs/orpheus.pdf
> 9. (AAMAS) Meaning-based programming model:
> https://www.lancaster.ac.uk/staff/chopraak/pdfs/azorus.pdf
> 10. (IJCAI) Langshaw, an even higher-level protocol language that compiles
> into BSPL: https://www.lancaster.ac.uk/staff/chopraak/pdfs/langshaw.pdf
>
> There's a lot more here: https://www.lancaster.ac.uk/staff/chopraak/ and
> even more here: https://www.csc2.ncsu.edu/faculty/mpsingh/papers/
>
> Our ever-growing software repository is available here:
> https://gitlab.com/masr
>
> FIPA standards and KQML are unsuited to engineering multiagent systems.
> FIPA ACL's and KQML's semantics are ill-conceived. FIPA Interaction
> Protocols capture only a handful of interaction patterns via informal
> notations such as UML.  These shortcomings are well-known in the MAS
> community. For more details, see
> https://www.csc2.ncsu.edu/faculty/mpsingh/papers/mas/computer-acl-98.pdf
> and https://www.lancaster.ac.uk/staff/chopraak/pdfs/ac-directions-2013.pdf
> (especially Singh's on page 15).  IOP addresses the shortcomings of the
> FIPA standards and KQML.
>
> I hope my post leads to a more informed discussion of agent communication
> approaches.  As we seek to establish the relevance of multiagent systems
> work for Agentic, let us not repeat the mistakes of the past.
>
> Best
> Amit Chopra
>
Lorenzo Moriondo
ロレンツォ・モリオンドオ
https://linkedin.com/in/lorenzomoriondo