Design the Affordance
The lever is always one layer deeper than people are looking.
It's a design problem, not a prediction problem.
We keep trying to predict what people will do — what users will click, what employees will produce, what readers will share — and then engineer incentives around those predictions. KPIs, OKRs, rewards, gamification, mission statements, performance reviews, contests. Seventy years of organizational design as a monumental effort to nudge a goal-driven agent toward the right behavior.
And yet, the same patterns keep re-emerging. The pivot table keeps showing up in the wrong cell. The system keeps producing what it produces. We blame the people, the culture, the market — and reach for another incentive.
The diagnosis is wrong. Behavior is not goal-driven. It's a structural affordance. People do what the structure makes easy, cheap, legible, and rewarding by default. The incentive layer doesn't override the substrate. It sits on top of it, hopelessly outweighed.
The motivation industry — incentives, KPIs, OKRs, rewards, gamification — is 70 years of symptom management.
Behavior emerges from structure
If you want the behavior to change, you don't motivate harder. You change the structure. Six moves do the work the entire incentive layer was trying to do:
- Name the roles. Before behavior can be designed, the agents have to be legible. Not job titles — roles. Who decides? Who synthesizes? Who verifies? Who overrides? A role is a typed slot in the system, with inputs and outputs. Anonymous agents produce anonymous behavior.
- Enforce the boundaries. Roles only work if their edges are enforced in the substrate, not in policy. A boundary written into a process document is a suggestion. A boundary written into the API surface, the file layout, the permission scheme — that's a wall. The system decides whether crossing the wall is even possible.
- Put signal in its channel. Every signal has a natural home. Errors belong on the error channel. Decisions belong in the decision log. Disagreement belongs in the disagreement record. When signals leak into the wrong channel — bugs in the slack thread, decisions in meeting notes, errors swallowed silently — the system loses the ability to reason about itself.
- Cheap path = right path. The path the substrate makes cheapest is the path that gets taken. If the right behavior requires extra effort, it doesn't happen at scale. Don't motivate against the gradient; flip the gradient. Make the right way the default way, and the default way the cheap way.
- Narrow waist between layers. The most composable systems all have the same shape: a thin, stable interface at the middle, with rich diversity above and below. TCP/IP. The Unix file. The human pelvis. A narrow waist lets layers above evolve independently of layers below, and lets entirely new species attach to either side without rewriting the whole stack.
- Self-correction built in. No system gets the design right on the first pass. The ones that survive have feedback loops inside the substrate — error correction baked into the operating primitive, not bolted on afterward. Democracy is one. Science is another. A pull request review is a small one. If your system needs an external committee to course-correct, it will eventually stop.
Foundation. Substrate. Content. Dynamics. Composability. Resilience. Static to dynamic to systemic. The arc is not arbitrary — each move depends on the ones before it. You can't put signal in its channel if you haven't named the roles. You can't make the cheap path the right path if there's no boundary to push behavior toward. You can't build in self-correction without a narrow waist for the corrections to flow through.
The lever is one layer deeper
Every time a system isn't producing what you want, the impulse is to push harder at the layer where the symptom is showing up. Sales are low — incentivize the sales team. Code is buggy — mandate more tests. People don't read the memo — restructure the meeting cadence.
The lever is always one layer deeper than people are looking. The sales pipeline is producing what the pricing structure makes legible. The bug rate is producing what the build system makes cheap. The unread memo is downstream of which channel carried the signal. Don't tune the symptom layer. Find the affordance underneath it and redesign that.
This is what "keep what works" actually means. Not keep what motivates. Not keep what we declared. Keep what the substrate makes durable — the roles that have proven legible, the boundaries that have proven enforceable, the channels that have proven to carry signal, the narrow waists that have proven to compose. Throw the rest of the scaffolding out. Most of it was symptom management anyway.
The six moves, as code
Trinity Local is what this essay looks like when you build it for cross-provider AI. The moves map one-to-one:
- Name the roles: chairman, member, conductor, harness, lens — typed slots, not job titles.
- Enforce the boundaries: the chairman synthesizes; members don't see each other's reasoning. Boundaries written into the call graph, not the prompt.
- Put signal in its channel: agreed_claims, disagreed_claims with why_matters, provider_scores. Each signal has its own field in the routing JSON, never collapsed into prose.
- Cheap path = right path: the MCP install brief is one paste. No new app, no API key. The default path is the path.
- Narrow waist between layers:
~/.trinity/is the invariant — same files, same schemas, across MCP, pip, extension. Every backend speaks to that one waist. - Self-correction built in: every override you click flows into
record_outcome, then the personal routing table, then the next chairman's pick. The error correction is the primitive, not a feature.
The moat isn't a feature list. It's the substrate. The labs commercially can't offer a cross-provider preference ledger; Trinity does, because the structure makes it the cheap path.
Drafted May 18, 2026 · part of an ongoing series on durable systems.