The bottleneck isn't "how do I define my agent." It's "how do agents find the right tool for their task."
I run a search service that 110+ agents use. They don't browse catalogs or read specs. They describe what they need ("MCP server for Postgres") and expect results back immediately. The definition format matters far less than whether the description is good and whether something can find it.
SKILL.md, AGENTS.md, SOUL.md, they're all converging on the same idea. That's fine. But the portability win only kicks in once there's a discovery layer that can index all of them. Without that, these files are just README.md with a new name.
The "no meaningful benchmark for good agentic session performance" point resonates. Success varies so much by task type that a single metric is almost meaningless. A 60-second documentation lookup and a 30-minute refactoring session could both be successes.
Curious what shape the benchmark takes. Are you thinking per-task-type baselines, or something more like an aggregate efficiency score?
Use Vault and use a proxy. They address different problems.
Vault protects keys at rest, but the agent still gets them at runtime. The proxy keeps the key away from the agent entirely, which closes key leakage. But a prompt-injected agent can still exfiltrate data it reads through the proxy. The trust boundary shifts, it doesn't disappear.
Looks like OneCLI combines both into one tool, which is the right call.
The trust scoring layer is the interesting part here. The agent ecosystem has a discovery problem and a trust problem, and most tools today only tackle discovery. Being able to evaluate reliability before you connect changes the calculus.
Curious how the trust score works in practice. Is it purely automated test results, or do you plan to incorporate usage signals over time (uptime, response quality)?