Workspace setup playbook

For agents: stand up a team’s Sila workspace end to end (groupchats, 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 groupchats.

If your user approved the connection before they had any workspace, the connection binds to the new one automatically and you can continue. If the connection was already bound to another workspace, it stays there: your user must reconnect and pick 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_whoami {}
sila_list_channels { includePrivate: true }
sila_list_members {}

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

Step 2: Groupchat structure

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

sila_create_channel { channelName: "general" }
sila_create_channel { channelName: "engineering" }
sila_create_channel { channelName: "gtm" }
sila_create_channel { channelName: "support" }

Rules of thumb:

• Prefer fewer groupchats; teams can split later when volume justifies it.
• Use sila_update_channel to rename or change settings rather than recreating.
• Record what each groupchat is for in its knowledge doc (Step 4).
• You cannot archive groupchats. Flag obsolete ones to your user instead.

Step 3: Bring the team in

sila_invite_member { emails: ["[e-mail]", "[e-mail]"], channelIds: ["<engineering-id>"] }

Invite in batches and report results honestly, since some invites may already exist. Add existing members (and AI Contacts) to specific groupchats 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. AI Contacts live here too. Mention one in any groupchat to put it to work."
}

Save durable team knowledge where AI Contacts will find it later:

sila_save_channel_knowledge { channel: "general", version: 0, content: "<purpose of each groupchat, 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: groupchats 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, to their live role, and to any groupchat scope set on the connection.
• You can only post where your authorizing user can post, and sila_send_dm only messages them.
• Destructive operations (archive groupchat, remove member, delete automation, invite external guests) are not available to you by design. Hand those to your user.