This isn't a product pitch.
I'm genuinely stuck on a trust problem and I want to know how others think about it.
The scenario
You have a multi-agent setup. One agent writes code. Another runs tests. A third reviews the results.
Agent B says: "I ran the test suite. 247 passed, 0 failed."
Agent C asks: "How do I know you actually ran them?"
What happens next?
In most setups I've seen — nothing. Agent C just trusts Agent B.
Why this bothers me
We built agents to automate work. But we didn't build a way for agents to verify each other's claims.
When a human colleague says "I ran the tests," you can:
- Check the CI pipeline
- Look at the test report
- Ask them to share the terminal output
When an agent says it... what do you check?
The agent's own log? That's the agent vouching for itself.
The middleware log? Now you're trusting the middleware, not the agent.
The CI pipeline? Only works if the agent actually triggered CI — and even then, you're trusting that the agent ran the right tests against the right code.
The deeper question
In a multi-agent system, who is the source of truth?
Not the agent — agents can hallucinate.
Not the middleware — middleware can be compromised.
Not the logs — logs can be truncated or tampered with.
I keep arriving at the same answer: the truth has to be cryptographically verifiable, not socially trusted.
But I'm not sure if that's overengineering.
What I'm thinking about
What if every agent tool call produced a signed receipt?
Not a log entry. A cryptographically signed receipt that binds:
- Who authorized the call (role + key)
- What was called (tool + parameters)
- When it happened (timestamp within a freshness window)
- What the result was (output digest)
- What evidence was produced (patch, test report, manifest)
And what if an independent verifier could replay all those receipts offline — without touching the live system — and confirm the entire chain is internally consistent?
No trust required. Just math.
The part I'm unsure about
This sounds good in theory. But in practice:
- Would developers actually adopt a protocol that adds signing overhead to every tool call?
- Is SQLite sufficient as an authoritative ledger, or does this need distributed storage from day one?
- Six roles (Manager, Developer, Verifier, Maintainer, Acceptor, Human) — is that real-world necessary or academic over-engineering?
I have opinions on all three. But I'm more interested in yours.
So here's my question
If you were building a multi-agent system tomorrow, would you rather:
A. Trust the agents and the middleware, and accept that verification is best-effort
B. Add a cryptographic layer that makes every tool call independently verifiable, at the cost of complexity
Or is there a C I'm not seeing?
I don't have a product to sell here. I've been prototyping this and I want to know if I'm solving a real problem or an imaginary one.
What would convince you to add verification to your agent pipeline?
Even if your answer is "nothing" — I want to hear it.
Top comments (1)
Opção B...