One conversation, a team when you need it

01 · Ask for the outcome, not the agents

Start with a normal brief: what you want, which sources to use, what must not happen and how you will review the result. You do not need to decide whether Radar, a writer or an editor executes each step. The coordinating Soot decides whether delegation is useful; a simple question can stay solo.

Prepare three draft posts for next week from our approved brand-guide and product sources. Cite source IDs and revisions. Suggest only channels we have connected. Do not publish. Return the drafts, a channel plan and any missing access or decisions.

Continue in the same conversation to refine that work. Ask about missing sources, approve a specific draft or choose a draft-only outcome. One automatic conversation keeps one selected Soot and can handle work in group A, then B, then A. You do not need a new chat each time the work needs another authorized group. Group-native history, artifacts and memory stay scoped; they are not copied across groups. Existing pinned chats and app/client pins remain fixed, and legacy ungrouped chats keep their old scope. Changing a default or management runtime does not move an existing chat. Choose a new conversation for a different objective or coordinating Soot, or to replace a fixed chat.

This chapter explains automatic collaboration in the current source implementation. It does not promise that these capabilities are enabled on a public deployment. Start with initialization and the daily operating guide if you have not yet prepared one working Soot.

02 · One Soot, host collaborators and templates

Users choose one Soot, not a group or an editable team. Nest, the current SDK chat session, widget and CLI automatically create with group_id: auto when the host advertises groups.auto.v1 and that Soot has automatic_groups: true. No required group picker sits in the normal chat flow. Native AgentCore spawn_subagent chooses from host-authorized group destinations when scoped work is useful; ordinary answers need no delegation. Group description explains which work belongs there, but cannot grant tools or access. Moving a chat between Nest sidebar folders does not change authorization. The host freezes the permitted destinations and their scoped policy for each execution; the Soot keeps its identity and mission.

Do not confuse collaboration with Principal.Team or conversation_clients.*.team: true: those concern shared access to conversations within a tenant, not teammate selection. A fixed-user key can use authorized collaborators in its own conversation without permission to read other users' conversations.

03 · Host members, automatic admission and API compatibility

The host defines named groups; each references existing, active, conversation-enabled Soots in the same runtime. Review the configuration reference and the effective policy before activation. Users choose a Soot; automatic delegation can select only host-authorized destinations, never infer permission from a task or edit a roster.

Group members run with their own Soot grants — tools, operations and credential bindings come from each member's Soot definition, never from the group. Host-local toolbox grants do not cross into a group run. Membership, a Pack name or a prompt cannot grant shell access, tools or another group's credentials. This is not an OS sandbox: the operator must review the adapter and backend resource boundary, not trust a group label.

Within a selected group destination, eligible colleagues are group members intersected with the caller's Soot grants. Nested colleagues stay in that group even if they also belong to another. An automatic root can select another authorized group destination for different work in the same chat; invalid or revoked scope never falls back to another group, a more privileged Soot or standalone work. Standalone remains a separately granted mode, not an automatic root's fallback.

Existing legacy ungrouped conversations retain their original scope and receipts; they are not automatically assigned to new groups. Old configurations retain their legacy collaboration.<root>.members behavior. Migration requires host review. For every execution, the host freezes authorized group destinations, admitted colleagues, grants, credential bindings and effective revisions. Later additions cannot expand queued or continued work; changed policy fails closed. Current access is rechecked before effects and publication. Retry with the same request ID returns the original receipt, not a newly computed scope.

Clients create a conversation with id, soot and optional group_id. Current clients automatically request group_id: auto only with groups.auto.v1 and the Soot's automatic_groups: true; explicit auto is rejected before contacting an older host without that capability. A named group creates a fixed chat. Existing pinned chats and app/client pins stay fixed and reject incompatible selections. Omitting `group_id` on the legacy API retains the old/default behavior, including authorized default/single-choice resolution and group_selection_required for ambiguity before work starts. It does not silently enable automatic delegation. Conversation mode is immutable: replacing a fixed chat or changing its pinned group needs a new conversation, while an automatic chat can use A → B → A. Do not send team: explicit legacy selections, including `team: []`, return 400, rather than selecting standalone work.

The public roster POST also rejects changes: 403 when public collaboration is disabled, otherwise 400. The current SDK chat session negotiates automatic groups under the same capability/flag gates and does not offer editable teammate rosters; group_id is distinct from team[]. Low-level clients retain read-only diagnostics. Remove roster editing from old integrations. See automatic collaboration and API compatibility and the conversation API.

04 · One execution path, each teammate's own authority

The coordinator is the selected Soot with its own mission and host-supplied collaboration guidance—not a separate router, scheduler or model loop. In automatic mode, native AgentCore spawn_subagent chooses a host-authorized group/<id> destination, which runs that Soot with the group's narrowed grants and colleagues. AgentCore still owns the model loop, retries, jobs, subagents, budgets and execution lifecycle. The automatic root has no external tools or global credential fallback; it can answer ordinary questions directly or synthesize returned results.

The host forwards the original user input, never coordinator-authored cross-group task or context. A group handles its relevant portion under the frozen policy; generated coordination text cannot carry another group's data into its tools. Named colleagues use their own definition and model policy, with operations and credential bindings narrowed to that group. Bindings resolve for the group, executing Soot and operation, not a pool of root or other-group credentials. Membership does not grant tools. An unnamed self-fork stays read/research-only within its parent's scope.

Group-native history is separate per conversation/group/Soot and is reused after restart only under the same policy revision. Scoped worker memory stays tenant/user/group/Soot-local, with extra conversation isolation for public work; artifacts stay within their conversation and execution group. Returning from B to A reuses only A's permitted context, not B's native history, artifacts or memory. Root aggregate memory is chat-local, not global or shared group memory. Backend ACLs must still enforce source and resource boundaries through reviewed adapters and group-specific credentials; a group is not an OS sandbox.

Child results return to the root for synthesis in the original conversation, not another customer chat or marketing queue. A chat containing group results requires access to all contributing groups, conservatively including failed contributions. Revocation hides the whole mixed chat rather than attempting to redact model summaries. Private artifacts are not automatically transferred across groups. Delegation receipts record attribution and recovery, not a second scheduler or a child's full native transcript.

All teammates currently execute within the same runtime. Connecting multiple runtimes in Nest does not enable cross-runtime delegation or a global router that automatically chooses between them.

05 · Shared limits, one Stop, careful recovery

Delegation count, depth, concurrent children and model-call limits bound the root run's execution tree. Children do not receive fresh budgets to escape the ceiling. Ordinary host limits still apply when no teammates are authorized; public application/global reservations are additional shared ceilings, not extra allowance.

Stop fences the whole tree. The runtime persists Stop before cancellation, blocks new effects and late replies, and cancels descendants, which are joined as execution finishes. A Stop acknowledgement is not proof that every child has already exited. You do not need to stop each teammate separately. Stop does not undo effects already completed or refund consumed work.

After an interruption, running work and uncertain external actions are not automatically replayed on restart. Keep the original request IDs and receipts, read the authoritative result and reconcile uncertainty before submitting again. Repeated group destinations in one request return the original receipt. Resource fences follow actual resource identities across groups: never replay an uncertain effect through another group. A lost connection is not proof that work stopped. The operation chapter and execution reference explain these boundaries.

06 · Set up a group from Soot Forge

A group template is soot/group-template/v1; a Pack supplying Skills/tools is soot/v1. The template describes member roles, soul/mission, flat capability selectors, channel metadata, binding requirements and dependency archives pinned by SHA-256. It is a reusable starting point, not a mandatory workflow graph.

In Nest, open Soot → Mẫu Soot. Add an archive with its verified checksum, inspect members and proposed capabilities, name the group and provide private binding file paths on the runtime host. Confirm grants to save the namespaced group. Áp dụng Soot uses the existing drained activation path; wait for the runtime to report it active before chatting.

Discover → verify/install → configure bindings → review grants → save → activate → create a conversation. These are separate steps. A download does not run tools or create a session. Selected Pack runners and backing services may still need operator preparation. See setup, Data Pool permissions and Soot Forge.

The website's current Marketing team listing is source/preparation guidance, not a released installable archive. Do not infer release availability from the source directory. When a reviewed group archive is available, this CLI example shows the local setup flow; replace every placeholder and use a new output directory:

soot group add ./marketing-team-group_VERSION.tar.gz --sha256 CHECKSUM
soot group inspect groups.d/marketing-team
soot group create groups.d/marketing-team --name acme --output ./acme-marketing --ai-config /private/ai.json --draft-only
soot check --config ./acme-marketing/deployment.json --show

--draft-only excludes members carrying publisher channel metadata. Review required-bindings.json, source access and selected runners before starting the generated deployment. The commands above do not start it. Keep real provider configuration and credential bindings private on the host; never paste secrets into a chat or template.

Operators save an adjusted configured workspace with soot group save, then export it with soot group export; this is not a session roster action. Save/export requires pinned provenance and verified dependency archives. Export derives binding requirements from those archives; it does not read secret bindings or transcripts. It excludes provider configuration, credential values, active schedules, history and runtime databases. Review authored prompts too: manually pasted private text remains private text.

The CLI also provides soot group save and soot group export. Saving locally does not upload to Forge; sharing follows its PR-based catalog workflow. See the group lifecycle and export examples.

07 · Marketing: sources to drafts to authorized channels

The benefit is one brief and one combined review, even when specialists do different parts:

You → Coordinator
Coordinator → Radar → source pool with URLs and revisions
Coordinator → Content creator → cited drafts from the pool
Coordinator → Editor → plan for available channels
Coordinator → 0, 1 or N permitted publishers → separate channel outcomes
Coordinator → You: drafts, plan, results and remaining decisions

Radar reads host-authorized sources such as X, blogs or GitHub and records source URLs and observed revisions in the shared pool. Creator writes from those references. Editor plans only channels represented by authorized publishers with the required bindings. The tool context includes channel metadata for the root and teammates; configured means configuration/bindings exist, not that an external account or endpoint is healthy.

Publication normally requires operator approval of the exact draft revision, content hash and `plan_revision`. Changing the plan invalidates previous approval. A host may explicitly configure automatic approval, but “please post” in a message is not a substitute for approval or credentials. A proposed publication date is not a scheduled job; timed execution needs host-owned scheduling.

A publisher records an uncertain receipt before its HTTP attempt. If the response is lost, it queries the original outcome through the bound gateway rather than repeating the POST. Changing the destination or gateway while an attempt is uncertain is blocked: restore the original reviewed binding and reconcile first. One channel's failure does not erase another channel's success. Return what was confirmed, what failed and what remains unknown.

Installing the template does not create X/blog accounts, crawl rights or a live publication gateway. Use the Marketing Pack and Marketing group source for pool, approval and gateway setup—not as evidence of real-account publication.

08 · Public chat: same collaboration, narrower permissions

Public chat uses the same conversation service, native AgentCore execution, durable store and Stop. The widget uses group_id: auto when the host advertises groups.auto.v1 and the selected Soot has automatic_groups: true, subject to app/client pins. The host must enable public_web.apps.<id>.collaboration: true only for delegation to other Soots; automatic group entry runs the same selected Soot in an authorized group and remains available without colleague collaboration (autoScopes always admits the entry and conditionally admits colleagues). Each group destination must be authorized by client groups; colleagues are group members intersected with the active client's assigned Soots. The selected Soot must be an allowed group entry; root and colleagues must pass the safe public capability profile. Existing pinned chats and app/client pins stay fixed; legacy ungrouped chats retain their old scope. false disables named teammates; true never permits visitor roster editing.

A publishable app key is a selector, not an operator credential. Server-issued visitor bearers and tenant/visitor ownership protect conversations. Client assignments are the browser grant; there is no reverse public_apps grant. The host owns client configuration, origins, keys, limits and activation. Saved policy is not active policy until the runtime confirms activation. Keep private operator and trusted-backend keys out of public frontend code.

Public integrations choose one authorized soot; current automatic-capable clients negotiate group_id: auto without a required group picker. Explicit named groups remain fixed, and omitted group_id on legacy API calls keeps pinned/default/single-choice resolution and ambiguity errors rather than silently choosing auto or the first group. Defaults affect only new conversations, not existing history. Reading or continuing a mixed chat requires all contributing group grants; revocation hides it conservatively. Read-only scoped snapshot diagnostics remain available, but public roster changes are rejected. Detailed delegation receipts and native transcripts remain private; visitors use authorized history and progress.

For configured workload tools, public safety permits only read_skill, not privileged workload operations. Marketing research/crawl and publication require a private deployment with appropriate grants. A public coordinator cannot reach a publisher outside its assignments. Use a suitable authenticated backend or private transport for staff workflows.

Configure each public app's limits.model_calls_per_run for root calls, teammates and synthesis. An omitted app limit reserves one call, insufficient for delegation. Public app/global quotas are shared ceilings even when the host collaboration budget is higher. Assignments, enabled status and current budgets are rechecked at execution boundaries. See public-web architecture; source behavior does not prove production activation.

09 · Ask for decisions, not teammate routing

Choose one Soot and give it a normal task. With automatic groups available, no group picker or user-written routing prompt is required: native spawn_subagent chooses host-authorized group destinations, and ordinary answers stay solo. Group descriptions help choose relevant work without expanding authority. Let the Soot collect evidence and return one combined result in the original conversation; pinned and legacy modes retain their limits.

Soot should ask about the goal, missing data or access only when needed—not ask you to select Radar, Editor or Publisher. For marketing, useful decisions include “Connect Blog,” “Approve this revision” or “Continue with drafts.” Missing access should produce a concrete blocker or a draft-only result, not an attempt to add an out-of-scope Soot.

Operators still configure members, bindings, grants and template activation. Installing a template does not create external accounts or activate bindings. Review the work and its evidence rather than managing a session roster or each teammate's tab.