Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
description: Crews of people, of agents and mixed in SCAFFOLD 0.1: roles, what each decides, assignment, supervision, budgets, identity and handoffs.¶
Crews of people and agents¶
This page explains how who does what is organised when a project works with people and AI assistants. It is an explanation; the rule is in the requirements and this page adds no obligations. The names and the project are fictional.
In brief¶
- A crew is a group with a responsible person: of people, of agents or mixed (R-030).
- An agent holds no role; responsibilities always rest with a person.
- A crew made up only of agents may propose and execute within its scope; it does not accept work, does not order the list, does not approve its own result and does not authorise a deployment.
- Each item in progress has a responsible person even if an agent executes it (R-031).
- A project of one person with one assistant applies these ideas without needing to form a crew (see "One person with one assistant").
Status: SCAFFOLD 0.1 is an accepted edition. How well each crew arrangement works in practice is not measured here (Hypothesis).
Roles¶
Roles are responsibilities, not job titles. The same person may hold several; in a one-person project, that person holds all of them. They are defined by the section "Roles named by the records" of the requirements.
| Role | Answers for |
|---|---|
| Product owner | Goal, project charter, order of the work list and acceptance of what is done |
| Coordination owner | Zones, cadence, crews, assignment and periodic review |
| Technical owner | Architecture, contracts, branching model, dependencies and the technical baseline survey |
| Delivery owner | Environments, artefact promotion, deployment, rollback and releases |
| Batch owner | One specific batch: zones, assistants, handoffs and result |
| Crew owner | A crew and the supervision of its agents |
Three forms of crew¶
| Form | Who makes it up | Fictional example (Ana's online shop) |
|---|---|---|
| Human | Only people | Beto and Carla maintain the shop interface in src/web/ |
| Of agents | Only agents, with a person as crew owner | A code assistant writes in src/export/ and a testing assistant in tests/, each in its own zone; Ana answers for the crew |
| Mixed | People and agents | Beto reviews and the assistants produce changes in src/orders/ |
The record of each crew declares its owner, members, write zones and types of work it accepts; that of each agent, its profile with scope, budget and supervisor (format in the templates). A crew's zones follow the rule of R-001: a path has no more than one write owner.
What a crew of agents can and cannot do¶
The table summarises the decisions the requirements assign. "Decides" indicates who records the decision; the agent may contribute proposals or execution within its scope.
| Action | Can a crew of only agents do it? | Who decides | Requirement |
|---|---|---|---|
| Propose items, criteria or order | Yes | Person with a product role, who records the decision | R-022 |
| Execute an assigned batch | Yes, within its zones, scope and budget | Coordination owner assigns (R-031); the agent executes | R-009, R-030 |
| Accept work for the crew | No | Coordination owner assigns | R-030, R-031 |
| Open an integration request | Yes, citing the item or batch and declaring the assistants that intervened | Batch owner answers for it | R-025 |
| Write to the main branch | No, except through an integration request reviewed by a person | Person who reviews the request; integrating what is catalogued as critical is decided by a person | R-026, R-010 |
| Accept an item as done | No | Person with a product role | R-022, R-023 |
| Order or discard the work list | No | Person with a product role | R-022 |
| Approve its own result | No | A person with a role for it; the crew of agents does not | R-030 |
| Deploy to production | Not by itself | Delivery owner, with informed confirmation | R-027, ASILO-R-005 |
The column "Can a crew of only agents do it?" reflects the restriction that R-030 sets only for crews made up solely of agents. In a mixed crew its people decide, not its agents. Actions that other requirements reserve to a person (for example ordering, accepting or discarding in R-022, or deploying to production) still require one. A person appearing in the crew is not enough; the decision is recorded with their name (residual risk of R-022: a person may accept without reviewing).
Assignment and capacity¶
R-031 asks that each item in progress have a responsible person. Planning distinguishes two capacities that are not added together:
- People: available time.
- Agents: limited by budget and by the human review their results require.
Fictional example (the figures are invented): an assistant can produce five changes in an afternoon, but Beto can only review two carefully. The useful capacity of that mixed crew depends on review, and the project records that estimate as an estimate, separate from measured data. Residual risk: human review can become the bottleneck without being measured; that is why it is worth measuring the time changes wait for review (an indicator option for R-032). A work-in-progress limit per crew (R-024) is another way to make it visible. The planning page and the project cycle treat those decisions in more detail.
Supervision¶
Each agent in a crew has a person who supervises it (R-030). R-030 does not define the verb "supervise". One possible editorial reading, not normative: the person knows the agent's profile and budget and reviews its results before integrating them. Residual risk (R-030): the declared supervision may not be exercised; the evidence is the history of reviews of integration requests, not the declaration.
Budgets¶
ASILO-R-007 asks for limits on cost, actions and time per automated execution. Each agent's profile cites its budget; a batch does not replace it (R-009). Cost is recorded as data or as "unknown", never as a disguised estimate. What happens when a budget runs out (for example, that the supervising person decides whether to extend it or close the batch) is a decision that the project declares; the requirements do not fix it.
Identity and scope¶
ASILO-R-004 preserves the identity and scope of each agent that acts with tools or data. For a crew, this means that each agent has its own identity in the records (not a shared account) and that its scope is no wider than that of whoever invokes it. That way the attribution trailers of changes (see branches and releases) distinguish each assistant. Changing tool grants neither permissions nor continuity (R-005).
Handoffs¶
Within a batch, changing assistant requires a handoff note with a state (R-005). Between agents of the same crew, the note names giver and receiver; whoever receives it takes it, and a taken note is not edited: if the goal changes, it is cancelled with a reason and another is opened. Between people, or from a person to an agent and back, a project may use the same note: the person can complete it with what they know and was not written down. R-005 refers to the change of assistant; its use between people is an editorial option. The open format is in the requirements.
One person with one assistant¶
In a one-person project, Ana holds all the roles. R-030 applies when the project works with crews: a single assistant does not require a crew record, but keeps its identity and scope (ASILO-R-004). If Ana decides to form a crew, she is the owner. What is kept:
- Ana decides the order, accepts what is done and authorises deployments to production; the assistant does not.
- The assistant has its own identity and scope; with a crew record, also a profile with budget and supervisor (Ana).
- Each item in progress has Ana as the responsible person even if the assistant executes it.
- Changes carry attribution to Ana and to the assistant.
What is simplified: there are no more people to share roles with, and the human review of the integration request is a self-review by Ana. That reduces the separation between whoever produces and whoever reviews; it is advisable to record that accepted risk, for example in the project charter, rather than present it as an equivalent control (Hypothesis about its sufficiency).
Hypothesis and what would promote them¶
| Claim | State | Verification that would promote it |
|---|---|---|
| Human review is the typical bottleneck of a mixed crew | Hypothesis | Measure review wait time in real projects, with dates |
| Self-review by a person with one assistant is sufficient for their context | Hypothesis | Review of the project's incidents and rollbacks with the R-032 rule |
| One identity per agent distinguishes authorship in the service's records | Hypothesis (depends on the service) | Check in a test repository how the specific service displays each identity |
Further reading: branches, environments and releases, templates and the SCAFFOLD page.