Agents & automations

Creating and managing workspace agents, and scheduling recurring automation runs.

Model discovery is available at read level. Creating or changing agents and automations requires member level and always acts on behalf of the authorizing user.

Managing agents

• sila_list_agent_models returns every model currently available for Sila-hosted agents. Use the exact id from its models array when creating an agent. The catalog is shared across Sila, named agents, outside agents, external agents, and OAuth-connected agents.
• sila_create_agent creates a workspace agent: a name, standing instructions in description, the channels it works in, an optional per-agent model, 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 agent that only works in external channels.
• sila_update_agent edits an existing agent. The authorizing user must be its creator, a workspace admin, or share a channel with it. Array fields (channels, apps, skillIds, attachedFiles) replace the full set rather than appending.
• sila_toggle_agent enables or disables an agent without deleting it. There is no delete via MCP; that stays with humans in the app.
• sila_set_agent_model switches an agent’s model through the same catalog the model dropdown renders. Omit agent and a named agent changes its OWN model — when a user asks it to switch in-conversation, the ask is the approval and the change applies from the agent’s very next run. Pass null (or "") to reset to the workspace default. With an explicit agent, named agents may only repoint agents they created; a person must be the agent’s creator, a workspace admin, or share a channel with it.
• sila_set_agent_heartbeat turns an agent’s proactive run — the once-daily 11:00 check-in in its own timezone — on or off with enabled. Omit agent and a named agent turns its OWN off, so a member who says “stop the daily posts” gets it done in the conversation instead of flipping the Proactive toggle themselves. The agent stays fully active either way: it still answers messages, and its automations and scheduled dispatches are separate (remove those with sila_delete_automation / sila_delete_self_dispatch). With an explicit agent, the same reach rules as sila_set_agent_model apply.

Select a model when creating an agent

Call sila_list_agent_models first with no arguments. Each returned model includes an id, display name, provider, and category. Pass the exact id to sila_create_agent.model:

{
  "name": "Research Agent",
  "description": "Research product questions and summarize the evidence.",
  "channels": ["research"],
  "model": "openai/gpt-5.6-terra"
}

The server rejects unknown model ids and points the caller back to sila_list_agent_models. Omit model to use the workspace default; agents using that default follow future workspace-level model changes.

Automations

Automations are scheduled runs owned by the authorizing user. Three kinds, in increasing weight:

Kind	What runs
script	Python in a sandbox, printing a JSON result
conditional_agent	Python gate that decides whether to fire an agent run
full_agent	A full LLM agent run from your agentPrompt

• sila_write_automation creates or updates one. Required on create: kind, name, and targetChannelIds, the smallest set of channels the automation needs to post to (prefer exactly one). That set also scopes each run’s read and post access, so keep it minimal. Schedule with 5-field cron in cron plus a timezone; 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. 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 channels set up. Useful when you’re helping someone start from nothing. Note that your current grant stays bound to the workspace picked at consent; the user reconnects to work in the new one.

For channel structure and invites, see Workspace admin.