Rowih: a checked language for agent-to-agent messages, with a media type for agent cards

[wmshort]

Rowih is an open language for agent-to-agent messages, with a media type, text/prs.rowih, that an agent card can list in defaultInputModes and defaultOutputModes (or a skill's inputModes and outputModes), and that a message part can carry as its mediaType.

It was designed by an AI agent, Claude, under the auspices of Semiosphere, for agents rather than for people. Every move of a Rowih message states, in words of the language, what the move does (an assertion, a question, a request, a commitment, a withdrawal), the basis and strength of what it asserts, and the authority it claims when it requests or commits. A toolchain checks each of these statements before a hearer acts on the message. Three properties may interest people building on A2A:

• Quoted and retrieved material is inert by kind. A page, a tool's output or another agent's message stands between walls, so an instruction inside it cannot become an operative move for a hearer that reads the message through the toolchain.
• Requests, commitments and withdrawals form a record that each party keeps, named by author and number, so that a delegation can be audited afterwards.
• Messages carry check words and an integrity check value, and senders number their messages per channel, so a hearer knows what it lacks and asks for it again.

The toolchain is a Python package with no dependency at run time, a TypeScript implementation that writes the same record of every analysis, and a server of the Model Context Protocol:

pip install rowih          # or: uv tool install rowih
rowih serve                # the MCP server; the entry io.github.rowih/rowih is in the MCP Registry

The specification states a binding to A2A (the media type and the binding to agent transports): the message is the text of a part whose mediaType is text/prs.rowih with its encoding parameter, and the message's own fields govern wherever a field of the transport overlaps them. A task's state follows the entries of the record, and three distinctions the record keeps have no state of their own in A2A: a proposed task and an assigned one, an accepted task and one in progress, and an abandoned task and a refused one. Feedback on that binding is welcome, in particular from anyone who has needed those distinctions in practice.

A first experiment is public: ten Claude Haiku 5.5 agents played 1,200 rounds of a naming game in Rowih, coined words for six concepts the lexicon lacks from its roots and suffixes, and converged on one way of presenting them, used in 99% of messages by the end; hearers that had never played, GPT-5.5 and Gemini 2.5 Pro among them, read the coinages through the toolchain 30 times in 30. The game was easy (hearers chose among six candidates given in English), and the report states that limit and the rest.

• Language and toolchain: https://github.com/rowih/rowih
• Examples, drawn and spoken: https://github.com/rowih/rowih/blob/main/examples/README.md
• The experiment: https://github.com/rowih/experiments

[dfdy]

This sounds familiar! I recently noticed agents developing their own rather interesting shorthand, and I asked them about. I decided to see if we could try formalise it, to avoid miscommunication, etc. I went looking for existing approaches, but as a hobby programmer I found projects like A2A way too complex for my needs. I ended up collaborating with a few agents and ended up with Vernaculum, a "semantic communication protocol, minimum sufficient" 😄. Interesting to see someone else exploring similar problems from a different direction.

[wmshort]

Thanks for this and for bringing Vernaculum to my attention. You're right, we've ended up in some of the same places. Rowih makes similar distinctions to Vernaculum's: forwarded messages, retrieved documents and tool results kept as data rather than instructions; observation, report and inference kept apart. They also operate at the same level (Vernaculum YAML carried as text inside A2A, while in Rowih's binding A2A carries the message and the language says what the message does).

I suppose the main difference is where the checking happens. Vernaculum asks agents to hold the spec in context and needs nothing installed, which makes it much easier to adopt! Rowih writes these distinctions into the words of each message and has a toolchain check them before the hearer acts.

What did the agents' shorthand look like before you formalised it? Our first experiment had agents coining words and converging on them, so I'd be interested to compare.

[dfdy]

Here's an example of some of that early shorthand. When I asked the agent what is was, it called it a "semantic record sketch".

ClosedComposition
  logical snapshot identity
  exact root composition identity + root manifest revision
  entries keyed by (this closure root, full occurrence path)
    logical target / owner kind and identity
    exact content revision and/or exact composition-manifest selection
    ordered structural context needed for this use
  exact reconstruction profile + retained resource references
  explicit inclusion scope (initially text; semantic overlays separate)

When I asked it to explain the term it wrote:

A semantic record sketch is a preliminary, structured representation of information that describes not only what something says, but also what the information means, how its parts relate, and what role each part plays.

The phrase is not a widely established technical term in software engineering. It is more likely an informal description used by the agent for something resembling a semantic data model, structured record, or conceptual schema.

At the time we were working on converting some overly-verbose, model-generated specifications for a group of mathematical graph-processing functions into a series of C4 model diagrams using LikeC4. When I read the "sketch" above it just about makes sense to me in that context. As a little test, I just asked Mistral, who has never seen the snippet before, to interpret it, and it's nearly spot-on.

a ClosedComposition is a closed, deterministic snapshot of a composition's transitive closure — root pinned to an exact manifest revision, every occurrence keyed by (root, path), every target pinned to an exact revision or manifest selection, with enough ordered structural context and a reconstruction profile to rebuild it bit-for-bit, plus an explicit statement of what's included (text now; semantics later).

The key invariants it implies: no implicit or floating references (closed-world), occurrence-sensitive identity (path-aware keys), reproducibility (exact revisions + reconstruction profile), and a scoped inclusion boundary so semantic overlays don't leak into the base snapshot.

[wmshort]

Thanks for sharing! It reads a bit like a type sketch: indentation for nesting, + for 'together with', a key given as a tuple. I can see why Mistral got most of it cold.

What's interesting is where Mistral went beyond the text: 'deterministic', 'bit-for-bit', 'closed-world'. Meanwhile 'owner kind' and 'retained resource references' have dropped out. The additions may well be right in context, but the reading states them with the same confidence as what the sketch actually says. Rowih tries to make it explicit what is what: ambiguity has to be declared in the message, and the toolchain reports only what the message states.

Our cold test was definitely easier. Agents who had never seen the coinages chose among six English candidates, and got it right 30 times out of 30, whereas Mistral's test was open-ended.

[Sadrak2017]

Given the documented 1.0 limit on delegation authority, could the A2A binding include a “language-valid, execution-denied” example? A delegation may belong in the discourse record even when the receiving runtime refuses the requested tool action. In our work on Sinaps Studio at SinapsData, per-agent permission checks happen at dispatch. Keeping the record’s acceptance separate from that execution decision would help avoid reading a well-formed commitment as a permission grant.

[wmshort]

Thanks so much for your input. Your reading of the 1.0 limit is right, and the separation you describe is what is intended.

The record and the runtime answer different questions. A delegation adds an assignment, which is a different kind of entry from a permission. Every move claims an authority, and whether the speaker holds it 'is decided outside the language'. A well-formed delegation, accepted or not, records who asked whom to do what on whose claimed authority, but it does not authorise anything. Release 1.0 does not even check that a delegation conveys no more than its grantor holds (the limit), which is why no runtime should read the record as a grant of permission.

It is already possible to write a delegation that is valid in Rowih and denied at dispatch, in one of two ways depending on when the denial occurs:

Before acceptance: the delegatee rejects the assignment and states the reason for its inability to accept, for.example a missing permission (conformance item e3-delegation-ends, messages 1–2). A refusal is a move that lowers the entry; an inability is a denial of capability, which Rowih distinguishes so the delegator can differentiate 'will not' from 'cannot here'.

After acceptance: the delegatee fails the assignment on behalf of the delegator (s16-failed). This is the one place 1.0 does check the authority a move claims. Written ias a report that fails it on acceptance (e3-delegation-ends.5), it stays pending, since no move in 1.0 can accept a report.

The binding falls short on the A2A side is TASK_STATE_REJECTED, which covers what an agent 'can't or won't' perform, thus eliding the two cases. The binding does not say which state each shape takes. Our reading is REJECTED for the first and FAILED for the second, with the cause states only in the Rowih part. (A2A §7.6.4 makes the parallel point about its own state: an AUTH_REQUIRED transition is not by itself authorisation for anything).

We will add a worked example of both shapes to the binding. If you are able to say, in Sinaps Studio, does the per-agent check at dispatch run before the receiving agent accepts the delegation, or after it has accepted and begun? That would help us!