The capability-declaration problem is real and underserved. Most tools are designed for human cognition, not machine consumption.
Worth separating two distinct contract questions though:
1. Capability contract: what can this tool do? (what Sonde addresses — commands, inputs, outputs, discovery)
2. Authorization contract: what is this agent allowed to do with this tool, in this context?
The first contract lives in the tool. The second can't. Even with a perfect manifest, an agent that reads it learns what's possible — not what's permitted for this specific task.
The manifest helps the agent construct a valid request. The enforcement layer decides whether to grant it. Those are separate surfaces, and conflating them is where a lot of agent security debt accumulates.
Concrete example: an agent reads the manifest for a filesystem tool, discovers `delete_file`, constructs a valid call with correct parameters. The manifest says it's a valid call. What stops the agent from running it on a file outside its working scope? That can't be encoded in the manifest — it requires external enforcement that knows the task context, not just the tool schema.
Sonde looks like a clean foundation for the capability side. Curious if you're thinking about the authorization layer as a next step.
My thinking so far is that Sonde only tries to describe the capability surface of the tool: commands, inputs, outputs, and discovery. In other words, what the tool can do in principle.
Authorization feels like it belongs to a different layer that sits between the agent and the tool: something that can apply task context, policies, or sandbox constraints before execution.
So the manifest would help the agent construct a valid call, but it shouldn't imply that the call is allowed. The enforcement layer still decides that.
Your filesystem example is a good illustration: the manifest could describe `delete_file`, but whether the agent is allowed to call it on a specific path would depend on the environment or policy around the tool.
Right now I'm mostly exploring the capability contract because that surface feels under-specified in current tooling. But I agree that the authorization layer is where a lot of the real safety and control questions live.
This project was inspired by a tweet from Guillermo Rauch referencing the article
“Rewrite your CLI for AI agents”.
The idea is simple: most CLIs were designed for humans reading terminal output.
AI agents interacting with tools need something closer to a machine-readable contract.
Sonde is an early experiment exploring a small manifest that lets tools describe
their commands, inputs and outputs so agents can discover and execute them
without scraping terminal output.
This is still very early and I'm mainly interested in feedback from people building developer tooling or agent workflows.
The capability-declaration problem is real and underserved. Most tools are designed for human cognition, not machine consumption.
Worth separating two distinct contract questions though:
1. Capability contract: what can this tool do? (what Sonde addresses — commands, inputs, outputs, discovery) 2. Authorization contract: what is this agent allowed to do with this tool, in this context?
The first contract lives in the tool. The second can't. Even with a perfect manifest, an agent that reads it learns what's possible — not what's permitted for this specific task.
The manifest helps the agent construct a valid request. The enforcement layer decides whether to grant it. Those are separate surfaces, and conflating them is where a lot of agent security debt accumulates.
Concrete example: an agent reads the manifest for a filesystem tool, discovers `delete_file`, constructs a valid call with correct parameters. The manifest says it's a valid call. What stops the agent from running it on a file outside its working scope? That can't be encoded in the manifest — it requires external enforcement that knows the task context, not just the tool schema.
Sonde looks like a clean foundation for the capability side. Curious if you're thinking about the authorization layer as a next step.
That's a really good distinction.
My thinking so far is that Sonde only tries to describe the capability surface of the tool: commands, inputs, outputs, and discovery. In other words, what the tool can do in principle.
Authorization feels like it belongs to a different layer that sits between the agent and the tool: something that can apply task context, policies, or sandbox constraints before execution.
So the manifest would help the agent construct a valid call, but it shouldn't imply that the call is allowed. The enforcement layer still decides that.
Your filesystem example is a good illustration: the manifest could describe `delete_file`, but whether the agent is allowed to call it on a specific path would depend on the environment or policy around the tool.
Right now I'm mostly exploring the capability contract because that surface feels under-specified in current tooling. But I agree that the authorization layer is where a lot of the real safety and control questions live.
This project was inspired by a tweet from Guillermo Rauch referencing the article “Rewrite your CLI for AI agents”.
The idea is simple: most CLIs were designed for humans reading terminal output. AI agents interacting with tools need something closer to a machine-readable contract.
Sonde is an early experiment exploring a small manifest that lets tools describe their commands, inputs and outputs so agents can discover and execute them without scraping terminal output.
This is still very early and I'm mainly interested in feedback from people building developer tooling or agent workflows.