Results of the research on BSPL and possible scenarios

Hello,

After talking to Amit and Samuel (the engineer for BSPL's masr and kiko), I
have reached a good point of understanding about what may be needed to
start, so here it is.

## General approach
In my experience any standard to reach support in the industry needs to be
highly streamlined and easily pluggable to existing solutions, in practical
terms:
1. have *agnostic syntax* that allow parsing in any language thanks to the
reuse of widely used standards (JSON, etc.) so a language-specific
implementation won't be widely received; we need a minimal interoperability
protocol that can be easily pluggable to any customised system and that can
work with anything widely adopted in the market. So the dimensions to
reduce are many: kind of systems, languages, developer tools, cloud tools.
I have tried to minimise these ranges to the minimum commonalities.
2. Provide code generation libraries that allow code generation in any
language (these could be worked on in *collaboration with the different
ecosystems* all along the drafting phase, so it may be needed to contact
the main languages communities, submit our ideas and see if they are
interested in defining code generation libraries for their own language. I
am working with Rust but the same should be done by C++, Java, Python ...
communities). For example, in the case of BSPL, the adaptors or their
boilerplates should be generated automatically from the definition.
3. aim to provide a better *developer experience* compared to what is on
the market (MCP, A2A, etc) to allow transparency, interpretability and
maintenance, or at least easily integratable with those; I agree that the
client-server model is not advisable for example.

I have done preliminary work on points 1. and 3, and some work for 2. for
the Rust programming language. I have developed an "annotated BSPL" that
can be considered a dialect so to have a reference for the characteristics
needed: I called it BMPP Blindly Meaningful Prompting Protocol. If you want
details about how it relates to BSPL, please see below for links to the
draft paper and repository.

## Layers that need to be addressed by a standard-to-be
Another dimension is the scope of the processes we need to standardise, in
particular we have different layers that I try to summarise here:
A. Governance: how requirements are passed to the principals via LLMs
(prompting, how to use LLMs to generate requirements, how the organisation
defines rules for prompt architecting, agentic committees, etc).
B. Principals and Systems: how systems among different organisations
interact (so here Interactions-oriented Programming) and how they generate
the code from messages in/out their system's boundaries to allow
interoperability (code generation from interactions protocols). This is
definitely the layer for interoperability.
C. Software Engineering: what agents do and how code generated is
integrated with implementation details from the standard definitions is
executed (effectiveness, efficiency, sustainability, correctness, security,
etc)
These layers have to be provided in an agnostic way so that everything
is streamlined and easily pluggable with most of the products widely used
in the market by market players.

In standard definition terms we may want to focus only on A. and B.:
A.: Guidelines about how to define a prompt (or a context engineering
process) to properly generate a protocol definition, how the consensus
mechanism inside an organisation has to be carried on to minimise risk and
leverage the technology properly according to ethical-technical standards
(what Amit calls socio-technical domain). This may be of some novelty
compared to other major W3C standards, probably it will be something more
similar to what the SWEBOK does but for guidelines about how to deal-in
with LLMs?
B.: A protocol in any form that bases its characteristics on BSPL,
considering the research done on BMPP for making BSPL LLM-friendly; this is
a more typical challenge for a W3C working group probably as it is the
formal and structured definition of a protocol as already historically
successfully delivered for major efforts like HTTP, JSON, ...

If you find this interesting, please give feedback and integrate with
points that may have gone missing. Hope this is useful for your reasoning
and to develop shared knowledge about what is needed to achieve the
objectives of the working group.

Thanks for your attention,

[Link to the BMPP draft] https://github.com/Mec-iS/bmpp-paper
[Link to the repository] https://github.com/Mec-iS/bmpp-agents-rs

Lorenzo Moriondo
ロレンツォ・モリオンドオ
https://linkedin.com/in/lorenzomoriondo