Agents and teams
Define roles that contribute to the same mission, with clear responsibility and useful handoffs.
Start with the responsibility
A role should explain what it owns, what it may decide, and when it should ask for help. A name such as Engineering is useful only when the team understands its actual responsibility. For a release, that could mean preparing the implementation, checking it, and producing a readiness summary.
Define the expected inputs and outputs before choosing tools. This keeps a role useful even when its execution environment changes.
Keep one owner for each task
Many roles can contribute, but each task should have a single accountable owner. That owner gathers the needed work, resolves dependencies, and brings the task to its next decision point. Shared ownership without a named lead makes handoffs easy to miss.
A proposed reporting structure would make those relationships visible: who coordinates a role, who can clarify priorities, and which decisions still belong to a person.
A release teamEngineering owns release readiness. Growth owns the announcement draft. Operations owns the checklist that combines their evidence. You retain the decision to publish.
Write a useful role brief
- Purpose: the outcome this role contributes to the mission.
- Scope: the work it owns and the decisions it may make.
- Context: approved sources, constraints, and relevant decisions.
- Handoff: the deliverable, recipient, and completion evidence.
- Escalation: what to do when information, permission, or a dependency is missing.
Use the team view in the product preview to explore these sample responsibilities. Runtime selection, persistent assignments, and actual delegation remain planned capabilities. A visible role is not evidence that an agent has executed its work.