New post on EthResear.ch!
Treating autonomous agents as untrusted participants: what the Claude Code harness suggests for on-chain mechanism design
By:
- WGlynn
🔗 ethresear.ch/t/25202
Highlights:
- Most real-world “agent” systems rely far more on constraint/guardrail infrastructure than on the model itself (permissioning, isolation, context management, approvals).
- The harness architecture maps cleanly to mechanism design: default-deny permissions act like clearing rules, isolation prevents cross-agent interference, and approval checkpoints function as commitment devices.
- To narrow the on-chain/off-chain enforcement gap, protocols shouldn’t depend on participant honesty; they should change incentives and constraints so defection is unprofitable ("augmenting the invariant").
- As autonomous agents become major on-chain participants, modeling them as perfectly rational and well-specified may be wrong; mechanisms may need to account for fallibility (agents sometimes take non-best-response actions with meaningful probability).
- A key open design question is how to align enforcement domains: can an agent’s off-chain permission envelope be committed/enforced on-chain, and what can mechanism design teach agent-harness engineering (and vice versa) about building robust constraints around untrusted actors?
ELI5:
Imagine you have a very smart robot helper, but sometimes it confidently does the wrong thing. Instead of hoping it behaves, you put it in a playpen with rules: it can’t touch dangerous buttons, it has to ask before doing big actions, and it can’t mess with other robots. The article says blockchain mechanisms should treat AI agents the same way: assume they can be wrong or selfish, and design the system so bad actions don’t pay and are hard or impossible to execute.
Treating autonomous agents as untrusted participants: what the Claude Code harness suggests for on-chain mechanism design
By:
- WGlynn
🔗 ethresear.ch/t/25202
Highlights:
- Most real-world “agent” systems rely far more on constraint/guardrail infrastructure than on the model itself (permissioning, isolation, context management, approvals).
- The harness architecture maps cleanly to mechanism design: default-deny permissions act like clearing rules, isolation prevents cross-agent interference, and approval checkpoints function as commitment devices.
- To narrow the on-chain/off-chain enforcement gap, protocols shouldn’t depend on participant honesty; they should change incentives and constraints so defection is unprofitable ("augmenting the invariant").
- As autonomous agents become major on-chain participants, modeling them as perfectly rational and well-specified may be wrong; mechanisms may need to account for fallibility (agents sometimes take non-best-response actions with meaningful probability).
- A key open design question is how to align enforcement domains: can an agent’s off-chain permission envelope be committed/enforced on-chain, and what can mechanism design teach agent-harness engineering (and vice versa) about building robust constraints around untrusted actors?
ELI5:
Imagine you have a very smart robot helper, but sometimes it confidently does the wrong thing. Instead of hoping it behaves, you put it in a playpen with rules: it can’t touch dangerous buttons, it has to ask before doing big actions, and it can’t mess with other robots. The article says blockchain mechanisms should treat AI agents the same way: assume they can be wrong or selfish, and design the system so bad actions don’t pay and are hard or impossible to execute.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
