Choose an AI agent organization template by starting with the job, not the template name. Pick the smallest coordination pattern that gives every decision, permission, handoff, failure, and maintenance obligation one clear owner. Reject a pattern if it adds roles without distinct responsibility, grants broad write access for convenience, shares mutable state without an owner, or cannot stop and recover cleanly.

This guide uses organization template to mean a reusable operating pattern for roles, coordination, data, permissions, and handoffs. It is not a marketplace listing or a claim about any specific product inventory.

Toone is the AI workspace for your agentic workflows: a macOS app where specialist agents run your workflows and routines under your control. The choice below is the operating shape you give those agents, made before any of them is created.

Start with the simplest viable organization

More agents create more coordination paths. That can be useful when work needs separate expertise, context, or permission boundaries, but it also adds handoffs, failure modes, latency, and maintenance.

Anthropic recommends beginning with the simplest solution that meets the need and increasing agentic complexity only when the task warrants it in Building effective agents. OpenAI similarly recommends maximizing a single agent's capabilities before introducing multiple agents in A practical guide to building agents. Microsoft's AI agent orchestration patterns advises using the lowest level of complexity that reliably meets the requirements.

These sources do not establish a universal ideal number of agents. Use the following questions instead:

Can one accountable owner complete the job with clear instructions and well-defined tools?
Does any part of the job need a distinct expertise, context, data, or permission boundary?
Are the dependencies fixed, parallel, or discovered during the work?
Who owns shared state, conflicting results, approval, and recovery?
What evidence would show that the pattern fits better than a simpler option?

If the first answer is yes and the remaining questions do not expose a separate boundary, keep one owner.

Decision matrix

The pattern names below are a neutral editorial vocabulary. They describe coordination shapes, not available products.

Pattern	Coordination shape	Choose it when	Reject it when
Single owner with tools	One agent or deterministic component owns the job and calls well-defined tools.	One owner can complete the work within one context and permission boundary.	Instructions or tools remain overloaded after clarification, or the job requires distinct access boundaries.
Sequential specialists	A predefined chain passes a checked artifact from one stage to the next.	Dependencies are stable and each stage adds a distinct transformation or review.	Work needs dynamic routing or backtracking, an early error cannot stop the chain, or a stage adds no distinct value.
Concurrent specialists	Independent agents handle separable parts or perspectives; a named collector reconciles results.	Work can run independently and conflicts have an explicit resolution rule.	Agents contend over mutable state, outputs depend on one another, or nobody owns conflicting results.
Manager and workers	One coordinator selects specialists, delegates bounded tasks, validates them, and synthesizes the result.	Subtasks emerge from the input and one owner should retain final context and responsibility.	The manager receives incompatible authority, cannot validate worker output, or becomes an unowned single point of failure.
Controlled handoff	One active specialist transfers the job and required state when a documented boundary is reached.	The right specialist becomes clear only during work and transfer conditions can be tested.	Routing is already deterministic, responsibility becomes ambiguous after transfer, or no loop cap exists.
Maker-checker loop	One role creates; another applies written criteria; the loop stops at pass, escalation, or a fixed cap.	Quality can improve through independent review against explicit acceptance criteria.	The checker lacks a rubric or independence, the loop has no cap, or a role can waive its own hard failure.

Microsoft's pattern guide distinguishes sequential, concurrent, group-chat, handoff, and manager-led approaches by dependency and routing shape. Anthropic describes prompt chaining, parallelization, orchestrator-workers, and evaluator-optimizer patterns with different fit conditions. OpenAI separates manager-led delegation from decentralized handoffs. The matrix combines those ideas into an operating decision; it does not claim that the labels form an industry standard.

Organization selection worksheet

Complete every field before selecting a pattern. Write UNRESOLVED instead of guessing. A load-bearing unresolved field is a reason to hold the decision.

Worksheet field	What to record	Rejection signal
Business job	One bounded task, intended user, required artifact or state, exclusions, and foreseeable misuse.	The organization begins with roles or tools before the job is defined.
Decision owner	Person or team authorized to choose, change, pause, and retire the organization.	No one can accept residual risk or stop the work.
Operator and agent roles	Each human and agent role, its distinct responsibility, and where responsibility changes hands.	Two roles own the same decision, or no role owns a required decision.
Shared-data boundary	Data each role may read, data it must not receive, retention, and the owner of shared state.	Every role receives full context by default, or mutable shared state has no owner.
Source ownership	Authority of record for each instruction, fact, configuration, and dependency.	The organization cannot determine which source wins when records conflict.
Routines	Trigger, frequency or event, stop condition, retry rule, and accountable maintainer.	Recurrence is implied but no trigger, stop, or retry boundary exists.
Inputs and outputs	Required input schema, output contract, evidence, and consumer.	Free-form handoffs make downstream acceptance impossible to test.
Read and write permissions	Tools and data each role may read; state each role may change; denied actions.	A role receives write authority because it can read the same system.
Approvals	Exact action requiring approval, approver, immutable payload, expiry, and behavior when no response arrives.	Approval is vague, self-approved, or cannot be tied to one action.
Dependencies and integrations	Required systems, interfaces, identities, declared capabilities, availability assumptions, and fallback.	An undocumented dependency can stop the job or expand access.
Coordination and handoffs	Pattern, routing rule, handoff payload, receiver, acknowledgement, conflict resolution, and loop cap.	Control can bounce indefinitely or be owned by more than one active role.
Evidence	Logs, artifacts, checksums, evaluations, reviewer identity, and limitations required to accept work.	A confident statement substitutes for inspectable evidence.
Recovery	Failure state, safe retry, rollback or reconciliation path, duplicate prevention, and owner.	Retry can repeat an external write or conceal an uncertain effect.
Maintenance owner	Who updates roles, routines, sources, permissions, dependencies, tests, and retirement state.	The structure has no owner after initial setup.
Fit and non-fit	Conditions that justify the pattern and conditions that require a simpler or different structure.	The pattern is selected from a label without testing its boundaries.

NIST's voluntary AI Risk Management Framework Core calls for documented roles, lines of communication, human-AI responsibilities, oversight, intended use, monitoring, and decommissioning ownership. The worksheet applies those accountability concerns to organization selection. It is not a claim of NIST certification or compliance.

Select the pattern in seven passes

1. Freeze the job and owner

Write one job that a reviewer can recognize as done or not done. Name the person or team that can change the operating design, accept residual risk, and stop the work.

“Support the company” is too broad. “Classify new support requests, draft a response from approved sources, and route billing disputes to the billing owner without issuing refunds” is bounded enough to expose roles, data, permissions, and escalation.

2. Test the single-owner option

List the tools and instructions one owner would need. If that owner can complete the job reliably within one permission and context boundary, adding more agents creates coordination work without a clear return.

Split a role only when you can name the boundary it protects or the distinct work it owns. Useful boundaries include a different data scope, a different decision authority, a required independent check, or expertise that should not receive the primary role's tools.

3. Map dependencies before choosing a topology

Use a sequential pattern when stage B genuinely depends on a checked output from stage A. Use concurrent specialists only when the work is independent and a named collector can resolve disagreement. Use a manager when subtasks emerge from the input but one owner must retain final synthesis. Use a controlled handoff when the correct specialist becomes knowable only during the work.

Do not use a dynamic handoff to implement a fixed rule. If every billing request always goes to billing, deterministic routing is easier to test and recover.

4. Separate data access from action authority

For each role, list what it may read, what it may write, and what it must never receive. Reading a system does not justify changing it. Drafting a recommendation does not grant approval authority.

The Model Context Protocol architecture is one concrete example of explicit capability boundaries: hosts control permissions and authorization, clients maintain isolated server connections, and supported capabilities are declared during negotiation. Not every integration uses MCP, but the design lesson transfers: record what a connection exposes and who may authorize its use.

If connection choice is the unresolved part of the design, treat it as a separate decision with its own record. A named integration should not enter this worksheet without its own evidence and permission boundary.

5. Specify handoffs and shared state

A handoff should name the trigger, payload, recipient, acknowledgement, and owner after transfer. The receiving role should be able to reject malformed or unsupported input before acting on it.

Persist only the state required to resume. Microsoft's orchestration guidance recommends durable progress and checkpointing for long-running work, validation before passing output downstream, and explicit timeout, retry, and degradation behavior. It also warns that concurrent agents sharing mutable state can create inconsistent results.

Record one source owner for every shared instruction, fact, and configuration. If two sources conflict, the organization needs a deterministic precedence or an escalation owner.

6. Define evidence, recovery, and maintenance

Decide what proves the work is acceptable before running it. Evidence might include a required schema, a source manifest, an immutable artifact, a reviewer applying a rubric, or a state-change receipt. Match the evidence to the job and its risk.

Write the failure path beside the happy path:

What state means the attempt stopped?
When is a retry safe?
How are uncertain external effects reconciled?
Who can roll back, supersede, or retire the organization?
Which sources, permissions, and tests expire when the structure changes?

A template without maintenance and retirement ownership is an initial diagram, not an operating design.

7. Apply rejection gates

Reject or revise the organization if any of these conditions remains:

The job has no accountable decision owner.
A role exists without a distinct responsibility or boundary.
One role can propose, approve, execute, and waive review for the same sensitive action.
All agents receive full context or write access by default.
Concurrent work changes shared state without reservation or reconciliation.
A handoff can loop or lose ownership.
An external effect can occur without an immutable approval and receipt.
A retry can duplicate or overwrite work.
Evidence, maintenance, or retirement has no owner.
The structure is more complex than the job requires.

Worked selection: a fictional vendor-onboarding job

This is a fictional operating example. It is not a Toone template, customer deployment, product test, performance result, or recommendation for every vendor process.

Job boundary

A fictional operations team needs to read a new vendor request, check that required documents are present, draft a review packet from approved sources, and route the packet to the accountable policy owner. The organization must not approve the vendor, send a message, create an account, or change permissions.

Candidate designs

Candidate	Fit analysis	Decision
One agent with read-only tools	The intake fields and approved sources are stable. One role can draft the packet, but it must also interpret which policy owner receives exceptions.	`REVISE`. Keep one intake owner but separate the exception-routing decision.
Sequential intake, policy routing, and checker	Intake produces a required schema. A routing role selects the policy owner from a controlled directory. A checker verifies required fields and citations before the packet enters human review.	`SELECT FOR TEST`. Dependencies are fixed, outputs can be validated, and no role receives approval or write authority.
Concurrent intake and policy agents	Both roles would need the same incomplete request and could produce conflicting owner choices.	`REJECT`. The tasks are not independent and no latency requirement justifies conflict resolution.
Manager with several workers	The job has a known three-stage path, so dynamic decomposition adds authority and routing complexity.	`REJECT`. A deterministic chain is sufficient.
Peer-to-peer handoff network	The next role is knowable from the input schema and routing table.	`REJECT`. Dynamic handoffs add loop risk without solving an unknown-routing problem.

Worksheet excerpt

Field	Fictional decision
Decision owner	Vendor Risk Lead owns the design, exceptions, and retirement.
Roles	Intake drafter, controlled policy router, independent packet checker, human policy owner.
Shared data	Each automated role receives the request ID and minimum fields needed for its stage. The human policy owner receives the complete checked packet.
Source ownership	Vendor requirements snapshot and policy-owner directory each have one named maintainer and version.
Permissions	Automated roles are read-only and may write only their versioned draft artifacts. They cannot send, approve, provision, or change access.
Handoffs	Each stage emits a required schema and checksum. The receiver rejects malformed input.
Approvals	The human policy owner's decision is outside the automated chain and cannot be inferred from the packet.
Recovery	A failed stage leaves the prior artifact unchanged. A new attempt uses a new ID. Any uncertain delivery blocks until reconciled.
Non-fit	Do not use this chain when requirements cannot be expressed as a stable schema or when qualified legal, privacy, security, or domain review is required earlier.

The result is a candidate for evaluation, not an approved deployment. The team would still need to test each role, the complete chain, permission denials, malformed handoffs, conflict cases, and recovery before use. Record that acceptance decision separately from the selection decision this worksheet covers.

Registry information is not the same as selection evidence

An agent registry helps people and orchestrators discover available agents. Microsoft's Agent Registry reference says that agent information should at least convey a name and detailed purpose, while expected inputs, outputs, communication details, endpoint, authentication, owner metadata, monitoring, and registration validation improve operability.

A name and one-line description are still insufficient to choose an organization. Selection needs the job, ownership, data, permissions, dependencies, handoffs, evidence, recovery, maintenance, and non-fit fields in this guide. A product gallery can help discovery only after its records have adequate provenance and completeness.

This page deliberately makes no claim about a current Toone template registry or inventory.

Connect the organization to adjacent decisions

Organization design owns responsibility and coordination. It should link to, but not absorb, adjacent decisions:

Use AI agent governance to set authority, approval, and exception policy.
Use organizational knowledge to define source ownership, provenance, access, and lifecycle.
Use AI agent routines to specify recurring triggers, inputs, stop conditions, retries, and maintenance.
Use the adoption roadmap to bound the first rollout before the design is widened.
Use showcases only for evidence that is documented on those pages.

The most useful next step is to complete the worksheet, then draw the responsibility and handoff map for the roles it produced. If the worksheet exposes an unresolved approval, permission, or exception boundary, continue with AI agent governance before adding roles.

About this guide

Who: Toone Content is the organizational author, and Hexagonal.io is the publisher. The Content Editor agent owns the independent editorial audit. This source does not claim human, product, security, privacy, legal, or subject-matter review.

How: The draft was prepared from an approved editorial brief and a pinned dossier of claims and sources. Automated assistance helped collect, organize, and synthesize current primary documentation from Anthropic, Microsoft, OpenAI, NIST, and the Model Context Protocol project. The decision matrix, worksheet, rejection gates, and fictional example are editorial synthesis. No Toone or third-party template was installed or tested.

Why: The guide is intended to help operators choose an accountable operating shape before copying a gallery label or granting access.

Limits and corrections: Real organizations differ by task, law, data, risk, and operating environment. Security, privacy, legal, employment, regulated, safety-sensitive, and other high-impact uses need qualified review beyond this editorial method. Read the editorial and corrections policy or contact Toone to report a material issue. Corrections should identify what changed, update the source date, and invalidate dependent locale versions until reviewed.

Primary sources

Anthropic: Building effective agents, published 2024-12-19.
Microsoft Azure Architecture Center: AI agent orchestration patterns, updated 2026-02-12.
OpenAI: A practical guide to building agents, accessed 2026-08-13.
NIST: AI Risk Management Framework Core, AI RMF 1.0 published 2023-01-26; accessed 2026-08-13.
Model Context Protocol: Architecture, revision 2025-06-18, accessed 2026-08-13.
Microsoft multi-agent-reference-architecture: Agent Registry, updated 2025-05-15.