Context
This is more forward-looking than the other issues. Less "here's a bug" and more "here's something interesting we found building on Mode 3."
flowscript-ldp implements 5 query operations over semantic graph payloads:
| Operation |
What it does |
| tensions() |
Find contradictions and conflicts in the graph |
| blocked() |
Find nodes with unresolved blockers + impact scores |
| alternatives(question_id) |
Reconstruct decision points with all options considered |
| why(node_id) |
Trace causal chains backward from a node |
| whatIf(node_id) |
Project downstream consequences of changes |
These are exposed as LDP skills (flowscript.tensions, etc.) via the delegate's capability manifest.
The interesting part
In a multi-agent Mode 3 exchange, these aren't just introspection tools. They're coordination primitives. A receiving agent can run tensions() on an incoming semantic graph payload to pre-compute disagreement before doing any work. This is only possible because Mode 3 payloads carry queryable structure, not just text or key-value frames.
I've been calling this "pre-computation of disagreement." The receiver identifies where its model of the problem conflicts with the sender's before committing resources to a task.
Question for the spec
Should Mode 3 define a standard set of query operations that all implementations must support, or leave it entirely to implementors?
For standardization: If Agent A knows Agent B supports tensions(), it can proactively send payloads structured for tension analysis. Interoperability improves when agents can reason about each other's query capabilities.
Against: Different graph representations support different operations naturally. Mandating operations that don't fit a particular graph structure leads to trivial implementations just to satisfy the spec.
Possible middle ground: Define a small "MUST support" set (maybe just tensions + blocked as the most universally useful) and a "MAY support" set that implementations advertise via capability manifest. The manifest mechanism already exists in ldp-protocol.
No rush on this one. Just wanted to plant the seed while the Mode 3 spec is still taking shape.
Context
This is more forward-looking than the other issues. Less "here's a bug" and more "here's something interesting we found building on Mode 3."
flowscript-ldp implements 5 query operations over semantic graph payloads:
These are exposed as LDP skills (flowscript.tensions, etc.) via the delegate's capability manifest.
The interesting part
In a multi-agent Mode 3 exchange, these aren't just introspection tools. They're coordination primitives. A receiving agent can run tensions() on an incoming semantic graph payload to pre-compute disagreement before doing any work. This is only possible because Mode 3 payloads carry queryable structure, not just text or key-value frames.
I've been calling this "pre-computation of disagreement." The receiver identifies where its model of the problem conflicts with the sender's before committing resources to a task.
Question for the spec
Should Mode 3 define a standard set of query operations that all implementations must support, or leave it entirely to implementors?
For standardization: If Agent A knows Agent B supports tensions(), it can proactively send payloads structured for tension analysis. Interoperability improves when agents can reason about each other's query capabilities.
Against: Different graph representations support different operations naturally. Mandating operations that don't fit a particular graph structure leads to trivial implementations just to satisfy the spec.
Possible middle ground: Define a small "MUST support" set (maybe just tensions + blocked as the most universally useful) and a "MAY support" set that implementations advertise via capability manifest. The manifest mechanism already exists in ldp-protocol.
No rush on this one. Just wanted to plant the seed while the Mode 3 spec is still taking shape.