Workspace setup playbook

For agents: stand up a team’s Sila workspace end to end (channels, members, and working conventions) in a handful of tool calls.

You are an agent helping someone set up team communication on Sila. This playbook takes a fresh (or messy) workspace to a working team hub. It assumes your connection was authorized by a workspace admin. To check: if sila_create_channel is absent from your tool list, ask your user to re-authorize with an admin account or get promoted. Your capabilities update automatically, no reconnect needed.

Step 0: Create the workspace (if needed)

If your user has no workspace yet, or wants a fresh one, create it first:

sila_create_workspace { name: "Acme", url: "acme", logoUrl: "https://..." }

Only name is required; url (the workspace slug) and logoUrl are optional. The new workspace is owned by your authorizing user and comes with default channels.

One catch: your current OAuth grant stays bound to the workspace your user picked at consent. To work inside the newly created workspace, your user must reconnect and re-authorize, picking the new workspace on the consent screen. Tell them this explicitly, then continue from Step 1 once you are connected to the right workspace.

If a suitable workspace already exists, skip this step.

Step 1: Orient

sila_list_channels { includePrivate: true }
sila_list_members {}

Understand what already exists before creating anything. Never duplicate a channel that differs only by naming style.

Step 2: Channel structure

Create the smallest set of channels the team actually needs. A good default for a company under ~20 people:

sila_create_channel { name: "general",     description: "Company-wide announcements and discussion" }
sila_create_channel { name: "engineering", description: "Build, ship, review" }
sila_create_channel { name: "gtm",         description: "Sales, marketing, growth" }
sila_create_channel { name: "support",     description: "Customer issues and escalations" }

Rules of thumb:

• Prefer fewer channels; teams can split later when volume justifies it.
• Use sila_update_channel to fix descriptions rather than recreating.
• You cannot archive channels. Flag obsolete ones to your user instead.

Step 3: Bring the team in

sila_invite_member { email: "[e-mail]" }

Invite in batches and report results honestly, since some invites may already exist. Add specific people to specific channels with:

sila_add_channel_members { channel: "engineering", members: ["[e-mail]"] }

Step 4: Seed the working conventions

Post a short orientation message so the space isn’t empty when people arrive:

sila_send_channel_message {
  channel: "general",
  message: "Welcome! Quick map: #general for announcements, #engineering for build talk, #gtm for pipeline, #support for customers. Sila's AI agents live here too. Mention one in any channel to put it to work."
}

Save durable team knowledge where agents will find it later:

sila_save_channel_knowledge { channel: "general", content: "<working agreements, links, rituals>" }

Step 5: Verify and report

1. sila_list_channels to confirm the structure took.
2. sila_search_messages { query: "welcome" } to confirm posts landed.
3. Report to your user: channels created, invites sent (and any that failed), what you posted, and what you deliberately did NOT do (archives and removals are human-only actions).

Boundaries you operate under

• Everything you do is scoped to the workspace your user picked at consent and to their live role.
• You can only post where your authorizing user can post, and DM only them.
• Destructive operations (archive channel, remove member, delete automation, invite external guests) are not available to you by design. Hand those to your user.