Ouroboros v0.40.0 is out.
https://t.co/6zVbaM1nZR
This release is not about chasing another flashy agent feature.
It is about making agent behavior more deterministic, controllable, and actually delegatable.
I’ve been working on this through harness engineering based on the 4C stack framework(Context, Contract, Control, Confidence). The goal is to make agents move inside a system that understands constraints, sequencing, checks, and stopping conditions, instead of relying on the model to “probably figure it out.”
The biggest improvement in this version is `ooo auto`.
It is now much more stable and is designed to keep moving without falling into BLOCKED states. For me, this is important because autonomy without reliability just becomes another thing the human has to babysit.
I’m also expanding the ecosystem around the Ouroboros runtime:
Ourocode — a CLI tool built on Ouroboros
https://t.co/LcQvJ68PMD
Ouroboros Plugins — plugins for domain-specific edge cases and more general problems
https://t.co/WtVpSE2Y9a
As the ecosystem grows, I keep coming back to one question: How do I let agents execute more work without letting them erase the direction of the project?
Recently, an agent tried to fix a bug in a way that looked technically plausible, but was directionally wrong. That was a good reminder. Agents can execute. But they should not overwrite the builder’s intent, taste, and principles.
There’s a point @simonkim_nft from Hashed made in this YouTube video that stuck with me: What remains for humans is self-directed intent and unique taste.
https://t.co/T5GPKOA7Lv
That idea is very close to how I think about Ouroboros.
I want to delegate execution to agents while preserving my own intent and taste. The image attached here shows how Ouroboros builds and checks sequencing graphs to make sure the system is still following the direction I care about.
There is no silver bullet that works for everyone.
And if everything becomes filled with plausible LLM-shaped answers, we do not get a silver bullet.
We lose direction.
Ouroboros v0.40.0 is a release where I tried to put a line in the sand: delegate execution to agents, but preserve the human intention behind the system.
The caller app can only create a signed request:
who is calling, what action it wants, payload hash, nonce, expiry, and optional policy reference.
The callee app owns execution.
It verifies the caller identity, payload hash, nonce, expiry, and user-granted policy before doing anything.
So the caller never gets raw access to the callee’s internal state or APIs. It only asks for a capability.
The callee decides:
accept, reject, require user confirmation, or return a signed receipt.
For payments, the wallet is a separate policy boundary.
The app can request payment, but the wallet enforces amount, asset, recipient, scope, and expiry.
I won a prize at OBA Weekendthon hosted by @hashed_official
After Ralphthon, I was lucky to win again.
But the thing I’m more excited about is what I built:
App-to-App MCP.
Apps should not just be endpoints.
Apps should become callers and callees.
I made a small deck here:
https://t.co/pHjtSfv1hK
If you are thinking about agent wallets, mobile agents, app-to-app workflows, stablecoin rails, or a new mobile OS layer, I would love to chat.
Apps should not disappear into assistants.
They should become callers and callees.
Small apps should be able to build their own workflows.
Apps should not disappear into assistants.
Apps should become callers and callees.
I think the next mobile OS may not start as a home screen.
It may start as a public call graph.