Why protocol-first
Why agentsparty separates a fixed communication contract from participant-authored content.
A protocol-first system records the permitted conversation as data before any participant runs. Roles, directions, message classes, branches, recursion, and termination all belong to that value. Projection derives one local contract for each role from the same source.
This makes a narrow class of claims inspectable. The library can reject a malformed loop, an unseen branch, an incomplete cast, or an undeclared payload before those faults become prompt-dependent behaviour. It cannot decide whether the eventual answer is useful or true.
Control and content
The protocol and the participant own different parts of a run:
| Concern | Owner |
|---|---|
| Roles, direction, order, and branches | Protocol |
| What one role can observe | projection |
| Legal message classes | send and choose |
| The selected declared class and its field values | participant |
| Payload admissibility | message codec |
A model may fill a declared field or select one of the classes currently on
offer. It cannot add a role, invent a label, or jump to another step. A
Machine, Policy, Script, or Human works under the same endpoint
contract.
Verification has a boundary
Projection can reject an impossible local view before a model call. It cannot make a model answer, make a human respond, or make an external side effect idempotent.
From declaration to execution
One session passes through four boundaries:
- The application declares roles, messages, and steps.
Protocolcloses the value and checks its recursive and compositional form.Sessionprojects the protocol, checks the cast, and installs run limits.- Participants author one permitted message at a time; the runtime records and delivers each decision.
The error vocabulary follows those boundaries. Invalid topology is a protocol error. An incompatible local view is a projection error. Invalid message data is a content error. Provider availability and refusal remain model errors.
How this differs from adjacent designs
Tool-calling loops, state graphs, and session protocols can all implement the same application. Their main difference is where the communication contract lives.
| Design | Route is primarily expressed in | What agentsparty chooses to make explicit |
|---|---|---|
| Prompt-driven tool calling | instructions plus tool permissions | the complete role-to-role route |
| State graph | executable nodes and transition functions | each role's local view of every branch |
| Session protocol | one projected global value | message ownership, visibility, and continuation |
A tool loop may enforce strict permissions, and a state graph may use typed state. agentsparty does not assume otherwise. Its narrower claim is that a global protocol and endpoint projection make communication structure a separate review artifact rather than an emergent property of prompts, shared state, and transition code.
Use that trade when the route is known in advance and deserves independent review. Avoid it when the model must discover the workflow while it runs or when a single agent with a small tool set already describes the system well.
Relationship to MPST
agentsparty takes its global-protocol and endpoint-projection model from Multiparty Session Types (MPST). It adapts the ideas to ordinary Python and in-process agent execution:
| MPST idea | agentsparty form |
|---|---|
| Global type | Protocol |
| Endpoint projection | one local endpoint per Role |
| Labelled communication | typed Message classes |
| Recursion and branching | loop, repeat, and choose |
The adaptation deliberately stops short of claiming the full results of every academic MPST system. It does not ship linear channel tokens, distributed transport, a general deadlock-freedom proof, or liveness guarantees. Runtime allowances bound work that cannot be proven to make semantic progress.
References
- Honda, K., Yoshida, N., and Carbone, M. (2008). Multiparty asynchronous session types. DOI: 10.1145/1328438.1328472.
- Ancona, D., Ferrando, A., and Mascardi, V. (2023). Global Types for Agent Interaction Protocols. DOI: 10.1145/3586031.
- Hüttel, H., et al. (2016). Foundations of Session Types and Behavioural Contracts. DOI: 10.1145/2873052.
Related
- Protocols and composition: declare the global contract.
- Projection and branch visibility: derive role-local views.
- Guarantees and limitations: see the exact checked boundary.