> ## Documentation Index > Fetch the complete documentation index at: https://docs.tuturuuu.com/llms.txt > Use this file to discover all available pages before exploring further. # Agent Operating Model > Roles, the shared subagent budget, publication and review rules, and the security default for autonomous agent work. Autonomous agent work on Tuturuuu runs as a small, bounded company hierarchy. This page explains the model for people. The repository's canonical rules are the [program orchestration reference](https://github.com/tutur3u/platform/blob/main/plugins/tuturuuu/skills/tuturuuu-agent-coordination/references/program-orchestration.md#operating-model-and-budget) and the self-contained [security default](https://github.com/tutur3u/platform/blob/main/plugins/tuturuuu/skills/tuturuuu-agent-coordination/references/security-default.md). The user-local shared `pstack-t3-workflow` skill is an optional convenience. ## Roles | Role | Who | Responsibility | | - | - | - | | Director | The user or Mastermind | Cross-project priorities and admin custody | | Project integration owner | One orchestrator per project | The only writer of main, release and other shared refs; program board; admission and budget reservations | | Team lead | Delegated child | One disjoint workset, its workers and its receipts | | Worker | Delegated child | Its own work branch and PR only, on an isolated worktree | | Reviewer | A child that did not author the change | Independent review receipt | ## Subagent budget Each thread tree may have up to `agent-allocation: 10` subagents, counting every descendant. This replaces the older five-child ceiling. Ten is a ceiling, not a target. * A project declares its allocation as the lowest of: * ten; * the observed runtime limit when scoped `per-thread-tree`; * resource admission; * any explicit lower allocation. * `observedRuntimeLimit.unit` accepts only `per-thread-tree` or `per-parent`. A tree limit caps the allocation; a per-parent limit caps each parent's live direct children, independently of the tree allocation and descendant grants. Do not relabel an ambiguous session limit without evidence. * Reserved, queued, active, waiting-for-children and blocked agents occupy a slot. Only drained `done` and `retired` agents release theirs. * The owner grants each lead an explicit remaining budget, and the lead's children must fit inside it. Nested leads share their parent's grant. They never get ten new slots. * The hierarchy is at most three subagent levels deep, and only leads delegate. > [!WARNING] > > The T3 runtime does not enforce ten, and no live session is claimed to > support ten. The budget is a repository contract plus a checker that > validates declared allocation files. It cannot configure or enforce T3's > runtime limit. Declare a program's live allocation in its ignored `tmp/agent-coordination//allocation.json`. The plugin reference ships an example. Check it with: ```bash theme={null} node scripts/ci/check-agent-budget.js tmp/agent-coordination//allocation.json ``` The checker rejects: * more live agents than the allocation (11 fails); * a file allocation above `AGENTS.md` or an observed tree limit, direct children above a per-parent limit, or a missing/unknown runtime scope; * lead grants that oversubscribe their parent; * excess nesting; * live agents under finished leads; * a reviewer that is, or descends from, its author; * any subagent that claims integration writes. Without arguments, it confirms that `AGENTS.md`, the plugin reference and this page declare the same allocation. `node scripts/docs-audit.js`, which the Documentation and SEO contracts workflow runs, includes that consistency check. The root script test suite runs the checker's tests. A passing check proves the declared structure only. It cannot see what a live thread tree actually ran. Agent count is not resource admission. ttr validation lanes, free disk, CPU and RAM still limit heavy work. Reduce active WIP when queues grow or disk runs low, and never spawn busywork to fill unused slots. ## Publication, review and retirement * Isolated workers and leads commit and push only their own verified work branch, or open a PR. Main, release and other shared refs move only through the project integration owner. * Publishing from the worker's own worktree means the root checkout's index never blocks branch publication. * The reviewer is never the author. * Leads return compact receipts: the PR, full head SHA, tests with results, residual risk, an explicit blocker (or none) and the resume event. * Once a child's result is on a pushed branch, the parent removes the child's worktree. The pushed branch and its receipt are the recovery point. * Add no new permanent controller, timer or wake, and never revive a retired one. Native result and PR watches plus the existing authorized cadence provide wakes. ## Security by default Tuturuuu is open source and a high-value target. * **Every change:** code, dependency, runtime and workflow changes get focused secret, dependency, SAST and trust-boundary checks. * **Independent review:** authentication, RLS and tenant isolation, credentials, storage delivery, CI/actions, runner execution, package publishing and deployment changes get an independent security review before integration. * **CI trust:** * Untrusted fork code never runs with secrets or write permissions. * Actions and artifacts are pinned, and tokens get least privilege. * Privileged follow-ups check actor and head/branch trust. * Mutations fence duplicates, replays and UNKNOWN outcomes. * **Cadence:** both cadences run only through existing admitted mechanisms. Where one is missing, record the exact gap, its owner and its resume event, and never add a T3 timer. * The daily automated audit belongs in trusted CI. As of 2026-10-23 this is a recorded gap: `codeql.yml` runs only on manual dispatch, and the scheduled security workflows are still pending. The gap is owned by the CI security workstream under the project integration owner. Its resume event is that workflow's merge. * The weekly deeper review runs on the integration owner's existing admitted control cadence. The plugin's security-default reference tracks the current status. * **Findings:** * Each finding carries a stable ID, severity, owner, source, current status and remediation receipts. * Open critical and high findings, including unconfirmed findings, hold the release until a verified fix with fresh exact-head evidence, an evidenced false-positive determination, or recorded risk acceptance by the release authority naming the finding ID, scope and expiry. Risk acceptance never waives secret rotation, untrusted-code isolation, or legal and tenant-isolation gates. * Existing negative assertions are preserved. * A scan is never reported as a blanket all-clear. * Raw secrets and customer logs never appear in public PRs, issues or artifacts. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.