Re: Introducing the "Semantic Agent Communication" modeling notes for implementing AgentIDL

Hi Paola,

Thank you. the principles you listed are extremely valuable, and they
map cleanly onto the direction I am working toward.
David Raggett’s work is also closely connected to the execution
aspects of what I’m building, and I plan to study it further.

Let me outline the precise relationship between my architecture and
KR, and what type of agents it applies to.

1. Type of Agents Targeted

The architecture applies to execution-bound semantic agents:

agents that must perform actions in an operating environment where
every action must specify:

1. preconditions
2. postconditions
3. provenance
4. accountability and traceability
5. delegable and inspectable boundaries

These agents behave in a way that can be audited.

1. They may be implemented using:
2. LLM-based inference modules
3. rule/workflow engines (e.g., n8n)
4. hybrid symbolic–procedural systems or any other backend

But the interface and behaviour are constrained by semantic structures.

2. Why Execution Matters to KR

When agents operate across organizations, cloud services, apps, or
customer transactions, their behaviour must be governed by:

1. semantic clarity (KR), and
2. operational correctness (execution)
3. KR alone cannot enforce behaviour.
4. Execution alone cannot explain why behaviour is allowed.
5. Execution-bound semantics is the missing layer connecting them:

So the goal is not to propose a new protocol, but to define the
boundary of the behaviour space an agent may occupy so the agent
cannot perform unexpected or unauthorized actions.

This is where the execution-bound semantics complements KR:

ontology → capability schema → contextual applicability → state
transition → provenance

And AgentIDL is intended as an interface definition layer, so
developers can generate their own SDKs to interact with agents in a
controlled and inspectable way.

3. Minimal Demonstration of the Architecture

This is not a protocol proposal, but a working environment that
demonstrates how KR constructs act as execution constraints:

https://github.com/s-agent-comm/usecases/tree/main/minimal_agent_cli

The demo shows how a semantic agent behaves when every action is
typed, authorized, and auditable.

4. What the Demo Shows (Direct KR → Execution Mapping)

1. Typed Capabilities

Each action the agent can perform has a defined capability schema, ex.

```
capabilities/
  └── write_note.json
```

This is a 1-to-1 mapping from ontology → actionable behaviour.

2. Explicit Execution Context

An action is only executable when its required context is present: (e.x.

```
context/
  └── working_directory.json
```

This matches KR-style preconditions.

3 State Transitions

Running a command triggers an explicit and inspectable state change:

agent write_note

-> modifies filesystem
-> updates state
-> logs provenance

This corresponds to postconditions and effect semantics.

4. Provenance & Accountability

Every action is written to an append-only log:

5. Human-Readable, Fully Inspectable Execution

An observer can always see:

1. what happened (action type)
2. why it was permitted (capability + delegation) (W3C did+vc as
identity, permission, scope, working env, etc).
3. which state changed
4. how provenance is recorded
5. how to audit the behaviour

More examples are collected here:

https://github.com/s-agent-comm/usecases

These demonstrate:

1. app-level agents
2. OS-level agents
3. SaaS workflow agents
4. cross-organization actions with delegation
5. typed execution pathways

thanks for your feadback.

Received on Friday, 28 November 2025 08:44:27 UTC