I have been thinking a lot about coding agents lately.
Not really about whether they can write good code, because usually they can, sometimes they can't. That part is obvious. But the risk is shifting from wrong answers to wrong outcomes.
The part that feels more important to me is this:
should the agent actually own the write authority?
We already don't trust humans without roles, limits, reviews, and accountability. Developers use PRs, pilots use checklists, bank clerks have transfer limits. Capable agents need the same structure, but machine-readable.
Right now a lot of setups still look roughly like this:
- agent reads the repo
- agent decides what to change
- agent has a GitHub token
- agent creates commits, branches, or PRs
I don't think this is the right default.
The agent can reason.
The agent can inspect files.
The agent can propose changes.
But the moment it can directly create external impact, the problem changes.
It is no longer just:
did the agent say something wrong?
It becomes:
did the agent create the wrong outcome?
That is a much more expensive failure mode.
Intent is not authority
The pattern I like more is simple:
- agent reads directly
- agent proposes intent
- a boundary decides
- an adapter materializes only admitted work
So the agent does not get the write credentials.
It submits a structured intent instead, which could look like:
{
"operation": "write",
"target": {
"repo": "example/app",
"branch": "main",
"path": "docs/config/agent-policy.md"
},
"source_state": {
"blob_sha": "8f31c2..."
},
"requested_effect_hash": "sha256:..."
}
This is then not a command anymore, it is a suggestion, or an intent.
The system still has to decide whether this proposed outcome should exist.
That decision layer can check things like:
- is this actor allowed?
- is this repo allowed?
- is this path in scope?
- does the source state still match?
- is this operation allowed?
- was the same effect already created?
- should this become a reviewable PR?
Only after that should there be an outcome.
For example:
{
"decision": "admitted",
"checks": {
"scope": "pass",
"source_state": "pass",
"policy": "pass",
"idempotency": "pass"
},
"outcome": {
"type": "pull_request",
"status": "created",
"reviewable": true
}
}
The core rule is:
No impact without admission.
The flow would look like this:
SOCIAL SHARE CARD GENERATOR