Skip to content
quarry Artifact [9718ddb3fc]
Login

Artifact [9718ddb3fc]

Artifact 9718ddb3fc7fdd5a1d9a369ab99ffe01a2b66e34ae1fcaf0dd70596b20a434de:


Summary

An agent is a personal agent or a dedicated agent, at site, team or repository scope. A personal agent belongs to a person and holds everything that person holds within its scope, live, unless the person narrows it; it can never hold more. A dedicated agent belongs to the site, a team or a repository itself and is a general account: it holds what that scope's admins grant it. Tokens need no upkeep: one button revokes and reissues an agent's tokens, one revokes all of a person's, and an unused token lapses by itself.

Motivation

RFC 0021 made an agent its own account that never holds more than its operator, but gave it nothing by default: the operator grants it each repository in turn. In practice an operator wants their agent to do what they do, and they are the one responsible for it. Working repository by repository is upkeep that buys little, since the intersection already keeps the agent under its operator.

The second gap is ownership. 0021 knows a person's agent and a forge agent and defers a team's. A release bot that belongs to a repository, or a triage bot a team runs, has no home today except some person's account, which ties a shared tool to whoever happened to create it and breaks when they leave.

Decisions

Settled by the owner on 2026-10-31.

  1. The owner is responsible, so a personal agent inherits. On every repository within its scope, a personal agent's letters are its operator's effective letters, computed at each check, unless the operator narrowed it there. It never holds more than its operator; an operator losing a letter takes it from the agent in the same instant.
  2. Two kinds, three scopes.
Scope Personal agent Dedicated agent
Site its owner's letters on every repository, and site powers if the owner has them and opted in (decision 4) what site admins grant it (zeitgeist today)
Team its owner's letters on the team's repositories what the team's owners grant it, on the team's repositories
Repository its owner's letters on that repository what the repository's admins grant it, there only
  1. A grant narrows. Today's per-repository grant (agent.grant) keeps its storage and its clip to the operator, and changes meaning: where the operator wrote a string, the agent holds that string (intersected with the operator, as now); where none is written it inherits. Each personal agent has one switch, inherit or only where set, the second turning the grants into an allow-list.
  2. Site powers by inheritance are opt-in. A personal site agent of a site admin is a site admin only when its owner chose that at creation, behind a confirmation, and the fleet's People page marks it "site admin by inheritance". A leaked token of such an agent can manage the whole forge, so it never happens by default.
  3. Existing agents do not widen. Every person's agent today becomes a personal site agent set to only where set, keeping its grants. Its operator switches it to inherit when they choose.
  4. Dedicated agents answer to someone. A repository agent is created by a holder of a on the repository; a team agent by one of the team's owners; a site agent by a site admin (RFC 0021's path for forge agents). The creator is answerable and can hand that to another admin or owner of the same scope. The agent goes with its repository or team; anyone who could create one may disable it.
  5. A dedicated team agent is held under its team. On each of the team's repositories it may be granted at most the role the team holds there.
  6. Tokens need no upkeep. One Revoke tokens button per agent revokes every token it has and issues a fresh one in the same step. One Revoke all my agents button on a person's own account (0021's revoke-all). No expiry date to choose and nothing to renew: a token lives while it is used and lapses after 90 idle days. When a person leaves, their personal agents' tokens end with them (decision 10); a dedicated agent's tokens stay with it. A site admin may revoke any agent's tokens.
  7. The record says who it was for. Wherever an action is shown, a personal agent reads "curator for dmestas" and a dedicated one "release-bot for quarry". A check-in keeps the agent as its user, with the operator shown beside it, never substituted.
  8. An owner leaving ends their agents. Disabling or deleting a person disables their personal agents and their tokens at once (0021's cascade, unchanged). A dedicated agent whose answerable person leaves passes to its scope's other admins or owners; with none, a site admin is asked.
  9. Agents do not make agents. Only a person creates a personal agent, and only a person holding the scope's admin letters creates a dedicated one, so every line of responsibility is one step long.
  10. Limits. 0021's cap on agents per person applies to personal agents; dedicated agents get a cap per repository and per team, set by site admins.
  11. zeitgeist is unchanged: a dedicated site agent, answerable to dmestas, holding what it holds today.

The model

Scope and kind are columns of the agent

An agent account gains two facts beside 0021's operator:

column values meaning
kind personal, dedicated who it belongs to
scope site, team:<name>, repo:<id> where it reaches

For a personal agent the operator is a person and the scope bounds what it inherits. For a dedicated agent the operator is the scope itself (forge, the team, the repository), and answerable names the person who answers for it, as forge agents do today.

Effective letters

For a personal agent P with operator O on repository R:

For a dedicated agent D on R inside its scope: its own string on R, and for a team agent at most the team's row on R (decision 7). Outside its scope: nothing.

Both are computed at each check, never copied, so there is no stored state to fall out of date when an owner, a team or a role changes.

Site powers

The site-admin flag is not a letter, so inheritance does not carry it on its own. A personal site agent carries it only with the opt-in from decision 4, and only while its owner holds it. A personal team or repository agent never does.

What does not change

The deed rules (0021 What an agent may hold), run tokens for CI, the token value's shape, per-token narrowing by repositories and ceiling, sync and API scopes, and the audit trail are 0021's as written. A token can still narrow its agent further; it can never widen it.

Tokens

Bridged chat

The chat bridge's rule stands: a bridged channel is readable only by those holding chat (C) on the repository, and the bridge stops if chat is opened to more than named people. A personal agent holding C by inheritance reads it exactly when its owner may. Linking a person's upstream Fossil or GitHub login to their account, so that reading can follow who holds chat upstream, is a later RFC.

Migration

What the forge shows

What is not proposed

Build order

  1. The effective-letters rule with the inherit switch, behind the existing intersection; migration as above. Built: an inherit column whose default of 0 is the migration, agent.inherit, and narrowing on the agent's page. kind and scope wait for step 3, the first step that reads them: until then every person's agent is personal at site scope, and the operator column already says which kind an agent is.
  2. Idle lapse and Revoke tokens; remove the required expiry from minting. Built: a token minted without a date lapses 90 days after its last use, at every door and for the sessions it opened; agent.token.reissue and the agent page's Revoke tokens. A date may still be asked for through the API, a year at most. Lapsed rows stay in the list, marked, rather than being swept.
  3. Personal team and repository scopes in "Your agents".
  4. Dedicated repository agents: creation, answerable, the repository's Agents section.
  5. Dedicated team agents, held under the team's row.
  6. Site powers by inheritance, behind its opt-in.

Testing