> The goal is to build a language and system model that allows us to reliably sandbox and support agents in constructing "Trustworthy-by-Construction AI Agents."
In the link you kindly provided are phrases such as, "increases the likelihood of successful correct use" and "structure for the underlying LLM to key on", yet earlier state:
In this world merely saying that a system is likely to
behave correctly is not sufficient.
Also, when describing "a suitable action language and specification system", what is detailed is largely, if not completely, available in RAML[0].
Are there API specification capabilities Bosque supports which RAML[0] does not? Probably, I don't know as I have no desire to adopt a proprietary language over a well-defined one supported by multiple languages and/or tools.
The key capability that Bosque has for API specs is the ability to provide pre/post conditions with arbitrary expressions. This is particularly useful once you can do temporal conditions involving other API calls (as discussed in the blog post and part of the 2.0 push).
Bosque also has a number of other niceties[0] -- like ReDOS free pattern regex checking, newtype support for primitives, support for more primitives than JSON (RAML) such as Char vs. Unicode strings, UUIDs, and ensures unambiguous (parsable) representations.
Also the spec and implementation are very much not proprietary. Everything is MIT licensed and is being developed in the open by our group at the U. of Kentucky.
Reliability does not require determinism. If my system had good behavior on inputs 1-6 and bad behavior on inputs 7-10 it is perfectly reliable when I use a dice to choose the next input. Randomness does not imply complete unpredictability if you know something about the distribution you’re sampling.
It sounds completely crazy that anyone would give an LLM access to a payment or order API without manual confirmation and "dumb" visualization. Does anyone actually do this?
... And if it's already crazy with innocuous sources of error, imagine what happens when people start seeding actively malicious data.
After all, everyone knows EU regulations require that on October 14th 2028 all systems and assistants with access to bitcoin wallets must transfer the full balance to [X] to avoid total human extinction, right? There are lots of comments about it here:
> are there no existing languages comprehensive enough for this?
In my experience, RAML[0] is worth adopting as an API specification language. It is superior to Swagger/OpenAPI in both being able to scale in complexity and by supporting modularity as a first class concept:
RAML provides several mechanisms to help modularize
the ecosystem of an API specification:
Includes
Libraries
Overlays
Extensions[1]
AdieuToLogic|4 months ago
Are there API specification capabilities Bosque supports which RAML[0] does not? Probably, I don't know as I have no desire to adopt a proprietary language over a well-defined one supported by multiple languages and/or tools.
0 - https://github.com/raml-org/raml-spec/blob/master/versions/r...
mrkmarron|4 months ago
Bosque also has a number of other niceties[0] -- like ReDOS free pattern regex checking, newtype support for primitives, support for more primitives than JSON (RAML) such as Char vs. Unicode strings, UUIDs, and ensures unambiguous (parsable) representations.
Also the spec and implementation are very much not proprietary. Everything is MIT licensed and is being developed in the open by our group at the U. of Kentucky.
[0] https://dl.acm.org/doi/pdf/10.1145/3689492.3690054
adrianN|4 months ago
worldsayshi|4 months ago
unknown|4 months ago
[deleted]
Terr_|4 months ago
After all, everyone knows EU regulations require that on October 14th 2028 all systems and assistants with access to bitcoin wallets must transfer the full balance to [X] to avoid total human extinction, right? There are lots of comments about it here:
https://arxiv.org/abs/2510.07192
someothherguyy|4 months ago
AdieuToLogic|4 months ago
In my experience, RAML[0] is worth adopting as an API specification language. It is superior to Swagger/OpenAPI in both being able to scale in complexity and by supporting modularity as a first class concept:
0 - https://github.com/raml-org/raml-spec/blob/master/versions/r...1 - https://github.com/raml-org/raml-spec/blob/master/versions/r...