AI-Native Series ยท The Visionboard
Life GPS for a Small Team: Roles, Not Persons; Load as a Solver Constraint; and the Signer Who Never Cooks That Dish
1-minute takeaway โ what you'll walk away with
What this is. The team version of the Life GPS operating contract: what changes when the one human above the loop becomes two to twelve humans and their agents. Four changes, each pinned to a schema field and to a rule: the human-only field becomes a role with separation of duties; the solver gains per-person capacity rows; ownership goes per node with a per-node secret; and the review becomes a one-on-one that can fail.
Why it matters. Most teams that adopt agents keep a one-person design and add people to it, which is how one founder's admin token becomes everybody's back door and how the loudest person's weights silently steer the optimizer. For a founding team or a lab this is the difference between a shared instrument and a shared illusion. For an engineer it is a concrete multi-tenant migration with the trap named.
What you can do. Print your team's autonomy-by-consequence table with an owner column; add the capacity row to your allocator; move the signature off the person who executes the node; and put the board's fired tripwires on the agenda of the next one-on-one, with a rule that the meeting can end in "the objective is wrong."
The Visionboard โ the series spine
- The Visionboard: Life GPS rebuilt with the human above the loop episode 1
- Life GPS, 2019 โ 2026: what the first planner got right and what killed it episode 2
- Life GPS for one person: the daily director's act, and where the agent may not go episode 3
- Life GPS for a small team: roles not persons, load as a constraint this episode
- The Visionboard scoreboard: what moved, what did not, and three futures with falsifiers next
What Life GPS for a small team is, who it is for, and why it is not episode 3 with more chairs
Episode 3 gave one person a contract: agents act inside bounded autonomy, one human signs, and a timed protocol keeps that human's judgment from rusting. The obvious next step is to hand the same contract to a team. This episode is about why that is a mistake, and what the team version actually is.
The short version: four parts of the loop change kind, not size. The field that grants authority stops being a person and becomes a role, and the role must not sit with the person who executes. The solver, which for one person could leave capacity implicit, needs a row per person, and those rows turn out to be the floors and caps from the 2019 program, one level up. Ownership, which for one person is a single admin token, becomes per node with a per-node secret, because the moment a second person exists the single token is a privilege bug. And the review cadence, a cron that opens a pull request, becomes a one-on-one whose agenda is the board's fired tripwires and which is allowed to end by declaring the objective wrong.
It is for founding teams, small labs and cohorts of two to twelve people who share agents, and for the engineer who has to migrate a one-owner board to many. The picture is the same kitchen as episode 1, one rung up the ladder.
One picture: the restaurant becomes a chain
An executive chef running one restaurant writes the menu, sets the standards, tastes and signs. Now the same chef runs three. The failure mode is instant and everyone in food has seen it: the chef tries to taste every plate in every kitchen, and either the plates wait or the tasting becomes a rubber stamp. The chain survives only when three things change. Each kitchen gets a head who signs for that kitchen. The chef signs the standard, not the plate, and never signs their own cooking. And the weekly meeting between chef and heads has a fixed agenda, the inspection reports, and an allowed outcome: the menu was wrong.
| The chain | Life GPS for a small team โ the handle |
|---|---|
| Each kitchen has a head who signs for it | nodes[].owner: every node has one owner; a weight is signed by signed_by: <owner> |
| The chef never signs their own cooking | separation of duties: the signer of a node's weight is not that node's executor; enforced in goal-edits, refused otherwise |
| Three hats in the building: menu-writer, head, cook | designer ยท director ยท executor as roles; the same person may hold different hats on different nodes, never two on one node |
| Each kitchen has so many hands | people[].capacity: a per-person capacity row in the integer program; a per-person floor so nobody is left with nothing |
| Each kitchen's keys | a per-node secret minted at creation, only its hash stored; verified against that node's hash; the admin token overrides, never gates |
| The weekly heads' meeting | Grove's one-on-one, frequency by task-relevant maturity, agenda = the board's fired tripwires; may end in "re-write the objective" |
| The health inspector still writes tickets | checkTripwires() unchanged; tripwires may now name a person as well as a track |
Four horizons: the team problem is older than the software
[EVIDENCE]300 years. In 1727, a year after the virtue chart, Franklin founded the Junto: twelve members, Friday nights, and a list of standing queries read at every meeting, on reading, business, civic service, character and whether the club itself should change. The design is the one this episode needs: a small group with a fixed agenda that is asked every week, whether or not anyone feels like it, and that includes a question about the group itself. The virtue chart died alone. The Junto ran for decades.
[EVIDENCE]30 years. Drucker's 1954 chapter is titled "Management by Objectives and Self-Control," and the second half of the title is the half people drop. His argument is that specialization misdirects effort toward the specialty and away from the whole, and that the corrective is objectives set by the person who will execute them, with decisions made at the lowest level and as close to the action as possible. The coverage constraint in the Visionboard's solver is that corrective in code: every track with a milestone gets a move, so no specialty starves the others. Grove's 1983 book supplies the mechanism for the review: one-on-ones whose frequency follows task-relevant maturity, and the rule that delegation without follow-through is abdication, which is a tripwire described in prose.
[EVIDENCE]30 months. The AWS lens names autonomy levels (observer, assistant, autonomous, orchestrator) and asks that human review depth scale with consequence by design. For a team, the level is set per agent and per person-node pair, which is Grove's task-relevant maturity wearing a new badge. Gaube et al.'s architecture separates the task layer from the oversight layer and asks who in the oversight organisation has authority; Dhanorkar et al.'s co-planning is the team-scale version of episode 3's pre-commitment.
[EVIDENCE]30 days. Mitchell, Ghosh and Passi's organisational protocols include role design that separates roles so decision-makers do not benefit from approvals, removing the structural incentive against intervention. That is the sentence behind rule 1 below: the person who signs a node's weight must not be the person whose work the weight promotes.
The design: four rules, one schema
Rule 1. The human-only field becomes a role, with separation of duties
[DESIGN]For one person, weight_signed: true was enough. For a team, a signature has to say who, and the who has to be constrained. Every node gets an owner. A weight on a node is signed by someone who is not that node's owner-executor; the edit vocabulary refuses a self-signature the way it already refuses a re-grade. The three hats, designer (writes the objective), director (signs weights and metrics), executor (works the node and files cards), are roles a person holds per node, and the rule is that no one holds director and executor on the same node. The chef may cook in kitchen two; the chef does not sign kitchen two's standard while cooking there.
Rule 2. Load is a row in the integer program
[DESIGN]The one-person solver picks the best three moves under per-track coverage. The team solver picks moves and assigns them: the decision variable becomes x[node, person], each person carries a capacity cap for the cycle and a floor of at least one move, and coverage still holds per track. Anyone who read episode 2 will recognise these rows. They are the 2019 program's weekly floors and caps per task, re-appearing as per-person floors and caps one level up. The same seven constraint families, applied to hands instead of hours. And the same honesty rule: when the coverage-plus-capacity model is infeasible, the solver says so with a labelled method and drops the constraint it could not meet, rather than silently over-assigning the most capable person.
Rule 3. Ownership goes per node, and the gate fails closed
[DESIGN]The one-person Visionboard is gated by one owner token. That is correct for one person and becomes a privilege bug the moment a second person owns a node: either they cannot manage their own node or they can manage everyone's. The migration is a known shape: mint a random secret per node at creation, store only its hash, hand the raw token to the owner once, and verify a presented token against that node's hash in constant time. Keep the admin token as an override for moderation, never as the only gate. And close the trap that catches real deployments: a helper that returns "owner" when the admin token is unset will open every node on a deploy that skipped the optional secret, so the admin bypass must require the token to be configured, and each node's gate must stand on its own hash. I have shipped this bug once on another surface of this site; it is in the design because it was found live, not in review.
Rule 4. The review is a one-on-one that can fail
[DESIGN]The board already has a review that can fail: a cron that opens a pull request and opens an issue when it cannot. For a team the review becomes Grove's one-on-one between director and executor, and three things are fixed about it. Its frequency follows task-relevant maturity: weekly for a person new to a node, monthly for a veteran, exactly as Grove prescribes. Its agenda is the board's output for that person's nodes: fired tripwires first, then unsigned proposals, then the disagreement log from episode 3's pre-commitment. And it has an allowed failure: the meeting may conclude that the objective, not the effort, is wrong, in which case the director re-writes the problem in a commit. Franklin's Junto had the question "whether the club itself should change" on its standing list for the same reason.
The worked case: three people, sixteen nodes, one board
content/goals.json, with three hypothetical people assigned as owners. Nothing below was run on a team; episode 5's scoreboard is measurement, this is design.[DESIGN]Take the real graph and add two people. Paul owns the objective (designer) and signs weights (director) on the nodes he does not execute. A second person owns and executes the FDE-os and loop nodes, the two closest to revenue. A third owns the research nodes, FM-os and longevity-loop. The rules produce the following immediately, without anyone having to remember them.
- Paul may not sign weights on anyagent, the node he executes most; the second person signs those, and the disagreement is logged in their one-on-one. The board's largest single node stops being weighed by its own cook.
- The solver's capacity row stops the failure the one-person board could not see: with three financial nodes on the revenue track and one person owning two of them, coverage would otherwise route all three moves through one pair of hands. The per-person cap forces the third move to the research owner or reports infeasibility, labelled.
- The relationship track, which had zero cards in month one, gets an owner whose one-on-one agenda opens with that tripwire every week until it clears. A silent track is now a named person's standing question.
- Each person's node tokens are theirs; Paul's admin token can moderate but cannot be the way anyone signs, and an unset admin token opens nothing.
What the worked case does not solve is worth saying: it does not tell you who the three people should be, and it does not make the $1M objective more likely. It makes the board an instrument three people can share without one of them steering it in silence.
Build it in 30 minutes: the schema and the contract
SCHEMA (additions to the one-person board)
people[] : {id, capacity_moves_per_cycle, maturity_by_node{node: low|medium|high}}
nodes[].owner : person id # the executor of record
nodes[].signed_by : person id | null # the director who signed the weight; โ owner
metrics[].signed_by : person id | null
access : per-node secret hash; admin token = override only, and only when configured
SOLVER (the team BILP)
x[node, person] โ {0,1}
maximise ฮฃ score[node] ยท x[node, person]
ฮฃ_person x[node, person] โค 1 # a move has one pair of hands
ฮฃ_node x[node, person] โค capacity[person] # nobody drowns
ฮฃ_node x[node, person] โฅ 1 # nobody starves
per-track coverage โฅ 1 where a milestone and a candidate exist
method labelled: bilp | bilp-nocapacity | bilp-nocoverage | greedy-fallback
INVARIANTS (tests first)
signed_by โ owner on every node; a self-signature is refused with a message
an unset admin token opens nothing (probe: visitor GET โ 403, never 200)
a person's token verifies only against that person's nodes
the 1:1 agenda is generated from the board, not typed: fired tripwires โ unsigned โ disagreements
STOP RULE
a 1:1 may end in "re-write the objective"; the director does it in a commit
DELIBERATELY MISSING
any auto-assignment of owners; any signature by an agent; any re-gradeSame story, five exits
| Reader | The decision this episode hands you | The one action |
|---|---|---|
| Student | Adding a person to an allocation problem adds a constraint row, not a copy of the solver | Add x[node, person] and a capacity row to the 12-line week from episode 2 |
| Engineer | One admin token plus two users is a privilege bug, not a setting | Mint per-resource secrets; make the admin bypass require the token to be configured |
| Founder | Whoever signs a node's weight must not be its cook, including you | Hand the signature on your own biggest node to someone else this week |
| Executive | A one-on-one with a generated agenda is an oversight process; one without is a chat | Put fired tripwires at the top of every one-on-one, in that order |
| Investor | A team that can end a review with "the objective was wrong" is running the loop, not performing it | Ask when the team last re-wrote an objective, and what tripped it |
Patterns, anti-patterns, and the mechanism
Patterns. One owner per node. Signer is never cook. Capacity as a row. Per-node keys, fail closed. A generated one-on-one agenda. A review allowed to fail upward.
Anti-patterns. The founder signs everything. "We share the admin token." The most capable person absorbs every move. A one-on-one with no agenda from the instrument. A team that has never re-written an objective.
The mechanism. Separation of duties removes the incentive not to intervene; capacity constraints remove the solver's ability to over-assign; per-node secrets remove the shared back door; and a generated agenda removes the option of not looking.
The first principle, in one sentence. A team's roadmap is honest exactly when no one can sign for their own cooking and no one can be assigned more than their hands.
Exit test
- Which 2019 constraint family returns in the team solver, and as what? (per-task floors and caps โ per-person floors and caps)
- Why may the person who executes a node not sign its weight, and which 2026 paper says so in organisational terms?
- What is the one condition under which the admin token may open a node? (configured, and only as an override, never as the sole gate)
Reality Mission
Mine: the schema above is a design, and the board today has no owner field. Before episode 5, the goal graph gets owner and signed_by on every node, with the self-signature refusal in the edit vocabulary and a test that proves it. That is the smallest change that makes the team version real rather than argued.
Yours: name the one node in your system whose weight is signed by the person who works it. Move the signature. If there is no one else to move it to, you have found the reason your board is still a one-person board.
Read next
Episode 4 of The Visionboard. Claims are tagged by class โ definition, design choice, evidence, measurement, open question; the worked case is explicitly a design, not a measurement. Sources are logged in the repository's research dossier under docs/plans/.
References
- Peter F. Drucker, The Practice of Management, Harper, 1954 โ ch. 11, "Management by Objectives and Self-Control": misdirection by specialization; decisions at the lowest possible level; objectives set with the person who executes.
- Andrew S. Grove, High Output Management, Random House, 1983 โ one-on-ones, task-relevant maturity, "delegation without follow-through is abdication," managerial leverage.
- Benjamin Franklin, Standing Queries for the Junto, 1732 (the club founded 1727), Founders Online, National Archives; and the Autobiography, Part One, on the Junto's rules. Verified 2026-09-07.
- Margaret Mitchell, Avijit Ghosh, Samir Passi, "AI Agents Push Humans Out of the Loop," arXiv:2608.23642, 2026 โ organisational protocols: role design that separates decision-makers from beneficiaries of approvals. Full text fetched 2026-09-07.
- Susanne Gaube et al., "Keeping an Eye on AI," arXiv:2605.16278, 2026 โ the oversight organisation and its authority, ยง3.1.
- Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu, "Human oversight of agentic systems in practice," arXiv:2606.05391, 2026 โ co-planning.
- AWS Well-Architected Framework, Agentic AI Lens โ Design principles, docs.aws.amazon.com โ autonomy levels; review depth by consequence.
- This site: episode 2 for the 2019 constraint families C1โC7; episode 3 for the one-person autonomy table; this repository's
lib/owner.tsandlib/gps.mjsfor the one-person gate and solver the team version extends. The per-resource ownership pattern and its fail-open trap were earned on this site's hosted-portfolio feature and are recorded in the project's memory notes.