Teams & mandates
The canonical software-company template uses teams as its primary coordination unit. Teams are optional graph structure, not kernel or runtime requirements.
What a team is
In this package model, a team is a durable coordination unit with a clear mandate and measurable outcome pressure. Package-owned work and principal placement may refer to a team; runtime attempts and provider sessions remain mechanical facts rather than team state.
The template chooses teams to make responsibility legible. The common product remains agent-primary and coordination-neutral: another company may use one principal, overlapping groups, peer networks, councils, markets, or another selected structure.
What a team owns
- A mandate — What the team is responsible for. Defines the scope of work it can accept, the resources it can use, and the outcomes it’s expected to deliver.
- A KPI set / utility vector — How the team’s success is measured. Usually a set rather than a single scalar — primary outcome metrics, guardrail metrics, health metrics.
- A budget scope — What the team is allowed to spend. Budgets are enforced; a team can’t operate outside them. Budget pressure surfaces as alerts: advisory, soft-limit, hard-stop.
- An inbox and outbox — How work enters and leaves the team. Cross-team waits become explicit through these.
- Local policies — Team-scoped rules: spend authorization, approval gates, escalation paths, allowed tools, session-reuse policy.
- Persistent agents — The template’s durable role bindings. This package places each one in exactly one team; that cardinality is not a common principal rule.
- Heartbeats — Narrow, clock-driven obligations the team owns (e.g. a daily review at 09:00). Heartbeats are not generic “wake up and do something” loops — they materialize through activation rules before they emit triggers.
- Local operating memory — Team-scoped doctrine, prior outcome reviews, local skill packages, and accumulated team-specific knowledge. Some of this rolls up into the company knowledgebase; some stays local.
- Optional child teams — Teams can have sub-teams when the mandate needs durable subdivision. The hierarchy is the org chart.
What “mandate” means here
A mandate isn’t a prompt. It’s a brief — a description of what the team owns, what it’s allowed to do, what outcomes it’s accountable for, and where its authority ends. Concrete, durable, auditable.
Mandates can change. Over time, a mandate may get narrowed when scope was too wide, paused when a bet stalled, replaced, demoted, or retired entirely. Mandate changes are real governance events — not just renaming.
Lifecycle
The package moves a team through these coarse states: proposed, active, paused, retired. Pausing a team stops it from accepting new work; existing in-flight runs may complete depending on policy. Retiring a team is permanent — its mandate, agents, and remaining work need explicit closure or migration.
Familiar and unusual shapes
Some teams in a company using this template will look familiar: marketing, delivery, operations, research, growth. Others may look strange: capability acquisition, lifecycle evaluation, memory stewardship, workflow ecology, promise integrity. The test isn’t whether the team’s name appears in a human org chart. The test is whether the team owns a real operating surface that benefits from durable local optimization.