Skip to main content
Creating or changing AI Contacts and automations requires member level and always acts on behalf of the authorizing user.

​
Managing AI Contacts

  • sila_create_agent creates an AI Contact: a name, standing instructions in description, an optional avatar (icon as a single emoji, a #RRGGBB color, or "auto", plus iconColor), the channels it works in (groupchat ids or names and dm:<id> entries the authorizing user can access), integration apps (registry slugs like "gmail" or "linear"), skillIds from the workspace library, and attachedFiles as its knowledge base. Set isExternal: true for a locked-down AI Contact that only works in external groupchats and cannot carry apps or skills. There is no model to choose: Sila picks the model for each task.
  • Pass webhook to sila_create_agent to make an outside AI Contact that lives on an agent you run elsewhere: { "url": "https://…", "bearerToken": "…", "provider": "custom" | "grok-bot" | "hermes" | "openclaw" }. Sila posts every @mention to url (signed with X-Sila-Signature; bearerToken, if set, goes out as Authorization: Bearer). The result carries an outside block with the mcpUrl, the agent’s privateKey, and the signingSecret, returned once; show them to the person right away. Outside AI Contacts carry no apps or skills. The request and reply contract is in Bring your agents.
  • sila_update_agent on an outside AI Contact also takes webhook with a new url and/or bearerToken (creator or admin only). The key and signing secret never change.
  • sila_update_agent edits an existing AI Contact (agent is its id or name). The authorizing user must be its creator, a workspace admin, or share a groupchat with it. Only the fields you pass change, and array fields (channels, apps, skillIds, attachedFiles) replace the full set rather than appending. An AI Contact cannot be switched between internal and external.
  • sila_toggle_agent enables or disables an AI Contact without deleting it; omit enabled to flip the current state. Re-enabling resets its schedule and check-in timers to the next future slot. There is no delete via MCP; that stays with humans in the app.
  • sila_set_agent_heartbeat turns an AI Contact’s proactive check-ins on or off with enabled. Check-ins run at 11:00 and 16:00 in the AI Contact’s timezone; the afternoon one only runs when people wrote something since the morning or a question was left hanging. The AI Contact stays fully active either way: it still answers messages, and its automations are separate. With agent, the authorizing user must be the AI Contact’s creator, a workspace admin, or share a groupchat with it.

​
Automations

Automations are scheduled runs owned by the authorizing user. Three kinds, from cheapest to heaviest: Pick the cheapest kind that does the job. A script can carry state between runs (its printed state is passed back in on the next run), and its tool calls through connected apps are approved automatically, so it can act as well as detect.
  • sila_write_automation creates or updates one (pass id to update). Required on create: kind, name, and targetChannelIds, the smallest set of groupchats (or dm:<id>) the automation needs to post to; prefer exactly one. That set also scopes each run’s read and post access, so keep it minimal. Add pythonCode for script and conditional_agent, and agentPrompt for full_agent and conditional_agent. Schedule with a 5-field cron in cron plus an IANA timezone (default UTC); leave cron null for a draft. Minimum cadence is every 5 minutes.
  • sila_test_automation runs automation Python once in a sandbox right now, without scheduling anything. Pass an existing id, or pythonCode plus kind, and optionally a state to simulate. The test runs for real, so its tool calls take effect. Test before you schedule.
  • sila_list_automations (read level) shows your automations with status, last error, and next run time.
  • Deleting an automation is not available over MCP. Disable it with enabled: false, or ask the user to delete it in the app.

​
Create a workspace: sila_create_workspace

Creates a brand-new Sila workspace owned by the authorizing user, with default groupchats set up. Only name is required; url (the workspace slug) and logoUrl are optional. If the user approved the connection before having any workspace, the connection binds to the new one automatically. Otherwise your grant stays bound to the workspace picked at consent, and the user reconnects to work in the new one. For groupchat structure and invites, see Workspace admin.