# Stilla Full Documentation > Complete documentation for AI/LLM consumption --- # Coding Agents > Fix bugs, implement features, and write PRs with AI. # Coding agents Stilla includes a built-in coding agent that can clone repositories, make code changes, and submit them for review. It runs in an isolated cloud sandbox, so your local environment stays untouched. ## What coding agents do From a natural language description, the coding agent can: - Fix bugs reported in issues or meetings - Implement features from specs or discussions - Update documentation to match code changes - Refactor code for clarity or performance - Write or update tests - Create landing pages or small applications ## How it works Tell Stilla what you need — reference a Linear issue, paste a bug report, describe a feature, or point to a meeting discussion. Provide enough context for the agent to understand the requirements. The coding agent clones the relevant repository into an isolated cloud sandbox. It has access to any repo connected through your [GitHub integration](/docs/integrations/github). The agent explores the codebase, understands the structure, and makes the necessary changes. It can read files, run commands, install dependencies, and test its work. The agent pushes its changes to a new branch and presents a change proposal — including a PR title, description, and number of lines changed. Review the proposal before accepting. Once you accept the change proposal, a pull request is created on GitHub with the proposed title and description. ## Context passing Coding agents receive context from wherever the task originated: - Meeting notes and transcripts - Linear issue descriptions and comments - Canvas content and specifications - Chat conversation history The more context you provide, the better the result. If you're referencing a specific issue, include the issue link so the agent can pull in all relevant details. ## Repository access Coding agents can access any repository connected through your [GitHub integration](/docs/integrations/github). Access requires both a personal GitHub connection and a GitHub organization channel — the personal connection authenticates the agent, and the organization channel determines which repos are available. They clone the repo fresh for each run, so they always work with the latest code. ## Credentials in the sandbox The sandbox starts without third-party credentials. GitHub access uses a short-lived token scoped to the repositories the command names, and it is minted per command rather than stored in the environment. When an agent needs another credential, such as a deployment token or a third-party API key, an organization administrator can store it as a secret and grant it to that agent. The value is injected as an environment variable for a single command and is never shown to the model. See [Secrets](/docs/security/secrets), which also covers the ways a credential can still end up in a transcript, a log, or a commit. ## IDE integration Prefer working in your own editor? Stilla can also launch tasks through Cursor, passing meeting context and specifications directly to the IDE agent. This gives you the best of both worlds — Stilla's context gathering with your preferred coding environment. You can also access Stilla data in Claude Code through the [Stilla MCP](/docs/integrations/mcp) — pull in meeting notes, Linear issues, and other context without leaving your terminal. Coding agents run in isolated cloud environments with a 60-minute maximum lifetime. They have access to common development tools and can install additional dependencies as needed. --- # Creating Agents > Build your first agent with natural language instructions. # Creating agents Creating an agent takes minutes. Write what you want in plain English, configure when it should run, and you're done. ## Step-by-step setup Give your agent a clear, descriptive name. This appears in the agent list and in run history, so make it recognizable — e.g., "Weekly Engineering Digest" or "PR Review Bot". Choose when the agent runs. Set a recurring schedule, listen for @Stilla mentions in specific channels, or run manually. You can have multiple triggers, and combine them freely. See [Triggers](/docs/agents/triggers). Describe what the agent should do in its prompt. Be specific about what data to gather, what output to produce, what format to use, what actions to take, and any constraints. The prompt is plain markdown — write it like you're giving instructions to a capable teammate. Tag using `@`-tag in the instructions to target channels in Slack, teams in Linear, or repositories in GitHub that Stilla should read, or post to when running. Control what the agent can access and modify. See [Agent Restrictions](/docs/agents/restrictions). Run the agent manually to verify it works as expected. Review the agent run canvas to see what it did. Once you're satisfied, enable it. ## Prompt best practices - **Be specific about output**: "Write a summary with bullet points grouped by team" beats "summarize what happened" - **Name your integrations**: "Search Linear for issues updated this week" tells the agent exactly where to look - **Define success criteria**: "Only include PRs that were merged, not opened or closed" - **Handle edge cases**: "If no updates are found, post a short message saying so" ## Example: weekly summary agent ``` Collect all updates from the past week: - Linear issues completed, started, or created - GitHub PRs merged - Significant Slack discussions in #engineering Write a summary grouped by project. For each project, list: - Completed work - In-progress work - Notable discussions or decisions Post the summary to #engineering-updates on Slack. ``` ## Example: meeting follow-up agent ``` After each meeting: 1. Read the transcript and identify action items 2. Create a Linear issue for each action item, assigned to the person mentioned 3. Post a summary of created issues to me in a DM 4. If no action items were found, reply confirming the meeting had no follow-ups ``` ## Turn on, and off Toggle agents on and off without deleting them. Disabled agents retain their configuration and run history, so you can re-enable them anytime. --- # Agent Memory > Persist information across agent runs with memory canvases. # Agent memory Agents can persist information across runs using a memory canvas. This lets agents remember context from previous executions rather than starting from scratch each time. ## How it works Memory is stored as a dedicated canvas that the agent reads at the start of each run and can update before finishing. This creates a persistent scratchpad that carries forward between executions. ## Use cases - **Track trends over time**: e.g., "alert me if deployments increase week over week" - **Remember decisions from past runs**: avoid repeating analysis or re-asking questions - **Build up context incrementally**: aggregate information across multiple runs into a single summary - **Maintain state**: keep running counts, lists, or logs that evolve over time Memory is different from [agent runs](/docs/agents/overview#agent-runs). Runs are a history of what the agent did. Memory is what the agent carries forward — notes and context it can refer back to next time. --- # Agents Overview > Reusable AI automations configured with natural language. # Agents overview Agents are reusable AI automations that you configure with natural language instructions. No code, no workflow builders, no drag-and-drop — just plain English describing what you want done. ## How agents work Each agent has three components: 1. **Triggers**: When and where the agent should run - **Scheduled**: Run on a recurring schedule (daily, weekly, custom cron) - **Channels**: Where the agent listens for mentions (Slack channels, GitHub repos, Linear teams) 2. **Prompt**: Regular text instructions describing what the agent should do 3. **[App restrictions](/docs/agents/restrictions)**: Control what each agent can access and modify — set default access levels, per-system overrides, and per-resource permissions to follow the principle of least privilege When triggered, the agent runs in its own [canvas](/docs/basics/canvases), executing the instructions with full access to Stilla's tools and [integrations](/docs/integrations/overview). ## Agent runs Every execution creates a separate canvas — an "agent run" — where you can see exactly what the agent did, what tools it used, and what changes it proposed. This gives you full transparency into automated actions. Agent runs are stored and searchable, so you can review past executions, debug issues, or audit what happened. ## Agent memory Agents can persist information across runs using a [memory canvas](/docs/agents/memory). This lets agents track trends, remember decisions, and build up context incrementally rather than starting from scratch each time. ## Channel triggers By assigning an agent to specific channels, you can customize how Stilla responds when mentioned in different contexts. Each channel can have its own agent, so Stilla behaves differently depending on where it's mentioned. For example: - An agent for your #support Slack channel that follows specific triage steps - An agent for GitHub PRs that runs your team's review checklist - An agent for Linear that categorizes and routes new issues ## Use cases - **Weekly standup summaries**: Aggregate updates from Linear, GitHub, and Slack into a weekly digest - **Changelog generation**: Generate release notes from merged PRs - **Customer feedback triage**: Route and categorize incoming feedback - **Incident response**: Pull context from PagerDuty, Slack, and logs when incidents fire - **Dependency scanning**: Check for outdated or vulnerable dependencies on a schedule - **Meeting prep**: Before a recurring meeting, gather relevant updates from all connected tools --- # Restrictions > Control what Stilla can read and do across chats, channels, and agent runs. # Restrictions Restrictions are runtime access controls for what Stilla can read and do on its own. They apply when Stilla reads connected data, calls a tool, accesses the network, or executes a change proposal. Restrictions are not limited to agents. Organization and user-group policies apply in direct chats and channels as well as agent runs. An individual agent can then have a narrower policy for its particular job. ## How policies compose Stilla can evaluate policies from several layers: 1. **Organization restrictions** set the baseline for every user and interaction in the organization. 2. **Group restrictions** customize that baseline for members of a user group. When a group defines the same default, app, or resource layer as the organization, the group value takes precedence. If a user belongs to several groups that define the same layer, the most permissive group value wins. 3. **Agent restrictions** are evaluated in addition to the user's effective organization and group policy. Both policies must allow an operation, so an agent can narrow what its user may do but cannot widen it. In a regular chat without an agent policy, the user's effective organization and group policy still applies. Administrators can also configure **default agent restrictions**. This policy is copied to each newly created agent and can then be adjusted by its owner. Changing the default does not change existing agents. ## Levels of control A policy starts with default access and can become progressively more specific: 1. **Default access** provides the baseline for connected systems. 2. **App or connection rules** override the default for a native integration or for an individual MCP or Pipedream connection. 3. **Resource rules** override the app rule for a particular channel, repository, recipient, drive, folder, file, or canvas. The most specific matching rule wins within a policy. For example, a file rule takes precedence over its folder and drive, and an exact email address takes precedence over an email-domain rule. ### Access levels Most apps and resources support these access levels: | Level | Can read | Can execute changes | | ---------------- | -------- | ------------------- | | **Read & write** | Yes | Yes | | **Read only** | Yes | No | | **No access** | No | No | Network access has additional modes for using the organization's network settings or limiting access to trusted sources. ### Individual tools and actions Instead of granting every operation on an app or resource, select the individual tools and change types Stilla may use. Tool-level controls work across native integrations and the discovered tools on individual MCP and Pipedream connections. For example, a policy can: - Allow GitHub reads and issue comments without allowing issue creation or other GitHub writes. - Allow a monitoring agent to search Slack without allowing it to send messages. - Allow selected tools from one MCP connection while denying the rest of that server's tools. - Allow one action in a specific repository or channel without allowing every write action there. For MCP servers, Stilla also uses the server-provided `readOnlyHint` tool annotation to distinguish reads from mutations. Tools Stilla treats as mutating are routed through change proposals. ## Resource rules Resource rules let you separate what Stilla may learn from where it may act. A policy can allow broad access to an app while granting or denying access for particular resources. Supported resource rules include: - Stilla canvases and folders - Google Drive files, folders, and drives - OneDrive folders and drives - Slack, Discord, and Microsoft Teams channels - GitHub repositories - Exact email addresses and email domains for Gmail, Outlook Mail, Google Calendar, and Outlook Calendar - URL and domain patterns for network access - Organization secrets an agent may use in sandbox commands Some resource types provide convenient virtual targets. Slack rules can cover all public channels; named private channels; all private conversations, including DMs; all direct messages; all group direct messages; or the current user's own direct message. Email rules can target the current user. Examples include: - Read email broadly, but send only to the current user, selected recipients, or approved domains. - Read only public Slack channels and send only to the current user's DM or `#incident-response`. - Use Google Drive broadly while denying access to sensitive documents in selected shared drives or folders. - Read all GitHub repositories but open issues or comments only in one repository. - Read the Stilla workspace but edit only canvases in a project folder. When an operation has several targets, Stilla evaluates each one independently. An email or calendar invitation with several recipients is allowed only if every address passes the policy. ### Secrets Organization secrets are the one part of the policy that is denied by default. Every other system falls back to the policy's default access when a policy does not mention it. Secrets grant nothing unless a policy names them, and an interaction running with no policy at all is denied rather than allowed. A grant is either the whole secrets system or one individual secret. There is no read-only variant, because injecting a credential is a single operation. Grants are keyed to the secret rather than its name, so replacing a deleted secret with a new one of the same name does not carry the old grant over. See [Secrets](/docs/security/secrets) for how to add a credential and what it can still expose. ## Enforcement Restrictions are checked at runtime against the actual tool, operation, and target resource. Stilla checks them again when an agent executes a change proposal, using the live policy and current target rather than only the values that existed when the proposal was created. Restrictions control what **Stilla** can do on its own: - Stilla can still draft a change proposal that it is not allowed to execute. - An authorized person can review and accept that pending proposal in the app. - To require human review for a class of changes, give the agent read-only access or select only the read operations for that app or resource. The agent can prepare the proposal, but it cannot execute it. Some actions have additional safeguards. Agents cannot execute messages or reactions in Slack Connect channels. They also cannot execute non-draft Gmail or Outlook Mail sends, or Google or Outlook Calendar invitations and updates, involving external addresses unless every address is an organization member or is explicitly allowed by an email-address or domain rule. Network restrictions use the same policy composition. They apply to regular web search and fetch as well as HTTP and HTTPS traffic from Stilla's sandboxed computer. ## Configure restrictions Organization administrators manage organization, group, and default-agent restrictions under [Settings → Organization → Restrictions](https://app.stilla.ai/settings/org/restrictions). Organization restrictions apply to direct chats, channels, and agents; default-agent restrictions affect only agents created after the setting is changed. Agent owners configure an individual agent's restrictions from the agent canvas. These restrictions can tighten the user's effective policy but cannot override an organization or group restriction that blocks an operation. For a least-privilege agent, start with **No access** or **Read only**, then add only the apps, tools, and resources required for its job. This is especially important for agents that process email, documents, web pages, or other untrusted content. For the security model behind these controls, see [Prompt injection security at Stilla](/docs/security/prompt-injection). --- # Triggers > Schedule agents or trigger them from Slack, GitHub, and Linear. # Triggers Triggers control when your [agents](/docs/agents/overview) run. You can schedule them, trigger them from channel mentions, or run them manually. ## Scheduled triggers Set agents to run on a recurring schedule. Stilla supports flexible scheduling: - **Simple**: "Every Monday at 9am", "Every weekday at 5pm" - **Complex**: "Every other Friday", "First Monday of each month" - **Frequent**: "Every 4 hours", "Every 30 minutes" Schedules use your timezone by default. You can override the timezone if needed for distributed teams. Each agent can have multiple scheduled triggers. Every trigger evaluates based on the start date you specify — the agent won't run that schedule before its start date. If multiple schedules are due at exactly the same time, Stilla coalesces them into one agent run. For example, an agent scheduled daily at 9am and every Monday at 9am runs once on Monday at 9am. Each schedule continues advancing independently after that occurrence. ## Channel-based triggers (playbooks) Configure agents to respond when `@Stilla` is mentioned in specific channels: ### Slack channels Add Slack channels to your agent. When @Stilla is mentioned, the agent processes the message using its instructions. There are two modes: - **Mention mode** _(default)_ — the agent only responds when someone explicitly mentions **`@Stilla`** in the channel - **Intake mode** — the agent processes **every** message automatically, without requiring a mention. Useful for dedicated intake channels like #support-requests ### GitHub repos Add GitHub repositories. When **`@Stilla`** is mentioned in issues or PRs in those repos, the agent handles the request. ### Linear teams Add Linear teams. When **`@Stilla`** is mentioned in issues belonging to those teams, the agent responds according to its instructions. ## Manual triggers Run any agent on-demand from the Stilla app, using the **Run** button. This is useful for: - Testing agents before enabling automated triggers - Running one-off tasks that don't need a schedule - Triggering agents in response to ad-hoc events ## Combining triggers An agent can combine multiple scheduled triggers with channel listeners. For example: - A triage agent that runs every morning at 8am to review overnight issues, AND responds to @Stilla mentions in #support for real-time triage - A digest agent that posts weekly summaries on schedule, AND can be triggered manually for on-demand reports --- # Canvases > Rich, collaborative documents where your team and AI work together. # Canvases Canvases are Stilla's core document format — rich, collaborative documents where your team and AI work together in real time. ## What are canvases? A canvas is an editable document stored as markdown and rendered with full WYSIWYG formatting in the Stilla app. Think of canvases as living documents that combine notes, decisions, change proposals, and AI-generated content in one place. Every conversation with Stilla happens alongside a canvas. The AI writes to the canvas, you edit it, your teammates contribute — all simultaneously. ## Rich editing The canvas editor supports the full range of markdown formatting: - Headers, bold, italic, and strikethrough - Ordered and unordered lists - Code blocks with syntax highlighting - Tables, images, and embedded links - Blockquotes and horizontal rules Content is stored as markdown under the hood, so it's portable and version-friendly. But in the editor, everything renders beautifully with a clean, distraction-free interface. ## Real-time collaboration Multiple users **and** AI agents can edit the same canvas simultaneously. Changes appear in real time for everyone. This is what makes Stilla different from traditional AI assistants — AI is a first-class collaborator, not a chatbot in a separate window. When Stilla processes a meeting transcript, drafts a document, or extracts change proposals, the results appear directly in the canvas where your team can immediately review and refine them. ## Change proposals When Stilla suggests changes to other apps — creating a Linear issue, sending a Slack message, updating a GitHub PR — these appear as **change proposals** at the bottom of the canvas. Each item shows exactly what will happen. You review, accept, or reject each one individually. Nothing changes in your other apps until you approve it. Change proposals are pending until accepted. Stilla never modifies your other apps without your approval. ## Sharing, and permissions Control who sees your canvases: - **Individual sharing**: Invite specific team members as viewers or editors - **Organization sharing**: Make a canvas visible to everyone in your Stilla workspace - **Public sharing**: Generate a public link for anyone to access (like external stakeholders) Canvas owners control access levels. Editors can modify access and content; viewers can only read. ## Canvas types - **Regular**: Standard documents for notes, specs, reports, or any content - **Meeting**: Automatically linked to calendar events. Created when Stilla transcribes a meeting, containing summaries, decisions, and change proposals - **Agent run**: Created by [agent](/docs/agents/overview) executions. Each agent run gets its own canvas showing what the agent did and what it proposed ... and more (example [memory](/docs/agents/memory)) ## Attachments Canvases support file attachments including documents, images, recordings, and other media. Upload files directly or let Stilla attach relevant content from meeting recordings and integrations. --- # Chat > Talk to Stilla in real time — as a team. # Chat Chat is how you interact with Stilla. Ask questions, give instructions, upload files, and collaborate with your team — all in one conversation. ## AI chat Stilla processes text, images, audio, video, and PDF files natively. You can: - Ask questions about your projects, issues, or codebase - Upload screenshots or documents for analysis - Request actions like creating issues, sending messages, or writing code - Get summaries of meetings, PRs, or Slack threads Stilla doesn't just use what's in the conversation — it actively searches across all your [connected tools](/docs/integrations/overview) to find relevant context and give accurate, current answers. ## Shared chat Everyone in a shared chat sees the same context, the same responses, and the same [change proposals](/docs/basics/canvases). This eliminates the "I asked AI about this separately" problem. Multiple team members can: - Provide additional context the AI needs - Ask follow-up questions - Review and act on change proposals together - Collaborate with AI in real time Shared chat turns Stilla from a personal tool into a team coordination layer. ## Private chat For anything you'd rather keep to yourself, create a private canvas or a private chat. There's also an "Ask" mode for asking questions without modifying the canvas or creating change proposals (useful for looking things up during meetings without others seeing, or just finding answers on your own). ## Chat surfaces Use Stilla chat from multiple surfaces: - **Stilla desktop app** (macOS): Full-featured with canvas editing, change proposals, and meeting transcription. [Download here](https://stilla.ai/download). - **Stilla web app**: Access from any browser at [app.stilla.ai](https://app.stilla.ai). Full chat and canvas support. - **Slack**: Mention **`@Stilla`** in any connected channel to ask questions or request actions. See [Slack integration](/docs/integrations/slack). - **GitHub**: Mention **`@Stilla`** in issues and PRs. See [GitHub integration](/docs/integrations/github). - **Linear**: Mention **`@Stilla`** in issues. See [Linear integration](/docs/integrations/linear). - **Discord**: Mention **`@Stilla`** in any connected channel to ask questions, or request actions ## Canvas integration Chat lives alongside [canvases](/docs/basics/canvases). From the chat sidebar, Stilla can: - Write content directly to the canvas - Create change proposals for external systems - Reference previous conversations and decisions - Process uploaded files and surface relevant information The chat and canvas work together — chat is for conversation and instructions, the canvas is for persistent, editable output. --- # Folders > Organize canvases into structured groups with granular permissions. # Folders Folders let you organize your [canvases](/docs/basics/canvases) into logical groups — by project, team, topic, or whatever structure fits your workflow. ## Organizing canvases Group related canvases together. Common patterns include: - **By project**: All specs, meeting notes, and decisions for a specific project - **By team**: Engineering docs, design reviews, marketing plans - **By topic**: Onboarding materials, runbooks, client documentation - **By time**: Weekly standups, quarterly reviews, sprint retrospectives Drag and drop canvases between folders, or ask Stilla to move them for you. ## Folder hierarchy Folders can be nested inside other folders for deeper organization. For example: - Engineering - Backend - Frontend - Infrastructure - Marketing - Campaigns - Analytics Folders can be nested up to 3 levels deep. ## Permissions Control visibility at the folder level: - **Private**: Only you can see the folder and its contents - **Shared with individuals**: Invite specific team members with view or edit access - **Organization-wide**: Make the folder visible to everyone in your workspace Folder permissions cascade to all canvases within, and nested folders inherit permissions from their parent. This is useful for team-specific documentation, sensitive projects, or client-facing content. ## Sharing Share entire folders with team members or your organization, giving everyone access to all canvases within. When new canvases are added to a shared folder, they automatically inherit the folder's permissions. ## Resources Attach external links and files to folders for easy reference. This keeps related URLs, documents, files, and tools alongside your canvases without cluttering individual documents. --- # Meetings & transcription > Transcribe meetings, extract change proposals, and keep your team aligned. # Meetings & transcription Stilla's desktop app transcribes your meetings, identifies speakers, extracts change proposals, and creates structured notes — so you can focus on the conversation instead of taking notes. Meeting transcription requires the Stilla desktop app for macOS. [Download it here](https://stilla.ai/download). ## How it works Connect your Google Calendar. Stilla sees your upcoming meetings and can automatically join them. Stilla also gets notified when the microphone becomes active, so you can join any meeting and get a prompt from Stilla to record. Never miss transcribing an important conversation. During the meeting, Stilla captures audio from your microphone and system audio (other participants). The desktop app handles all recording. After the meeting, Stilla creates a meeting canvas with key decisions, discussion points, and change proposals. It cross-references your connected tools to link discussions to existing work. Stilla extracts change proposals and proposes follow-up tasks — like creating Linear issues, sending follow-up Slack messages, or updating documentation. ## Supported languages Stilla transcribes meetings in 13 languages: English, Spanish, French, German, Hindi, Russian, Portuguese, Japanese, Italian, Dutch, Swedish, Danish, and Hebrew. ## Meeting settings You can customize how Stilla handles a specific meeting from the meeting settings dialog (gear icon in the meetings list or meeting notification). ### What each setting controls - **Mute notifications**: Suppresses reminders for this meeting **for you**. - **Auto-record**: Automatically starts recording when microphone activity is detected **for you**. - **Recording language**: Sets the default transcription language for this meeting **for everyone in your organization**. - **Default folder**: Sets where meeting canvases are created by default **for everyone in your organization**. ### Shared vs personal settings Two settings are personal per user (`Mute notifications`, `Auto-record`), and two settings are shared org-wide (`Recording language`, `Default folder`). If someone in your workspace updates the shared settings, other members will see those new defaults for that meeting. ### Recurring meetings For recurring meetings, settings apply to the recurring series (not just a single occurrence). That means changing settings once updates future instances of the same recurring meeting. ## Meeting canvases Each transcribed meeting gets its own [canvas](/docs/basics/canvases) linked to the calendar event. The canvas contains: - Summary of key discussion points - Decisions made during the meeting - Change proposals with proposed assignments - Links to related issues, PRs, and documents ## Change proposal extraction Stilla listens for commitments and tasks mentioned during the meeting. It then: - Searches your [Linear](/docs/integrations/linear) and [GitHub](/docs/integrations/github) for existing related work - Creates change proposals to update existing issues or create new ones - Proposes follow-up messages in [Slack](/docs/integrations/slack) - Suggests documentation updates ... and much much more! You review and accept each proposal individually — Stilla never creates issues or sends messages without your approval. ## Private AI sidebar During meetings, you can privately chat with Stilla to: - Catch up on context you missed - Look up related issues or PRs - Check the status of work being discussed - Prepare talking points This happens silently — other meeting participants don't see your private interaction with Stilla. --- # FAQ > Frequently asked questions about Stilla. # Frequently asked questions ## General ### What is Stilla? Stilla is the first **multiplayer AI agent** for product teams. Unlike a personal chatbot, Stilla lives where your team works — in Slack, Linear, and GitHub. It acts as a shared brain that captures context, orchestrates workflows, and keeps everyone aligned without manual updates. ### How is Stilla different from ChatGPT or Claude? Three things set Stilla apart: - **Context**: Stilla indexes your tools (Slack, Linear, GitHub, Notion, Google Drive, Gmail) so it knows your team's history, decisions, and active projects. - **Action**: Stilla doesn't just chat — it [creates issues](/docs/integrations/linear), [drafts PRs](/docs/integrations/github), [sends messages](/docs/integrations/slack), and [updates docs](/docs/integrations/notion). - **Multiplayer**: Stilla is designed for teams. Everyone sees the same context via [shared chat](/docs/basics/chat), preventing silos. ### Can Stilla write code? Yes. Stilla includes a built-in [coding agent](/docs/agents/coding-agents) that can clone repositories, make changes, and submit them for review. It handles bug fixes, feature work, documentation updates, refactoring, and test writing — all from a natural language description. ### What languages does meeting transcription support? Stilla transcribes meetings in English, Spanish, French, German, Hindi, Russian, Portuguese, Japanese, Italian, Swedish, Danish, Hebrew, and Dutch. See [Meetings & Transcription](/docs/basics/meetings) for details. ## Privacy & security ### What data does Stilla access? Stilla only accesses the platforms and channels you explicitly connect. You control what Stilla can see through [connections](/docs/integrations/overview), and you can further limit what agents can do with [agent restrictions](/docs/agents/restrictions). ### Is my data secure? Yes. All data is encrypted in transit and sensitive information such as API keys are also encrypted at rest. Stilla has passed its SOC 2 Type II audit with zero findings. See [Security & Privacy](/security) for more. ### Can I delete my data? Yes. Remove your account to delete all indexed information from our systems within at most 40 days. ## Agents & automation ### What are agents? [Agents](/docs/agents/overview) are reusable AI automations you configure with natural language instructions. No code required. They can run on a schedule, respond to Slack mentions, or be triggered manually. ### What are skills? [Skills](/docs/agents/skills) are reusable instruction bundles with file attachments that teach Stilla how to handle specific tasks — like code review checklists, deployment procedures, or writing style guides. ## Pricing ### Is there a free trial? Yes. 14-day free trial of the Pro plan with full access. No credit card required. ### Is there a free tier? Yes. After your trial, the Free tier gives you read-only access to canvases and documents in Stilla — you can view your team's work but can't interact with the AI agent or edit documents. ### What's included in Pro? The Pro plan removes all limits: - Unlimited agent actions - Unlimited integrations - Unlimited history - Priority support ### Do you offer Enterprise plans? Yes. For organizations needing SAML SSO, custom contracts, or dedicated support, contact [support@stilla.ai](mailto:support@stilla.ai). ## Technical ### Is there a mobile app? A mobile app is on our roadmap. The web app at [stilla.ai](https://stilla.ai) is fully responsive and works well on mobile devices. ### Does Stilla support SSO and SCIM? Yes, SAML-based SSO and SCIM provisioning are available for Enterprise customers. Contact [sales@stilla.ai](mailto:sales@stilla.ai) to get set up. ### Can I extend Stilla with custom integrations? Yes. Stilla supports [Model Context Protocol (MCP)](/docs/integrations/mcp), an open standard for connecting any external tool. If a service provides an MCP server, Stilla can use it. Visit [stilla.ai/integrations](https://stilla.ai/integrations) to browse available integrations. --- Still have questions? [Join our Slack community](/join-slack) or email us at support@stilla.ai. --- # Getting Started > Set up Stilla and start tracking your work in minutes. # Getting started with Stilla Get up and running with Stilla in just a few minutes. This guide will walk you through the initial setup process. ## Prerequisites Before you begin, make sure you have: - A Stilla account ([sign up here](https://app.stilla.ai)) - Access to the platforms you want to connect (Slack, email, etc.) ## Quick setup Visit [app.stilla.ai](https://app.stilla.ai) and sign up with your work email. Using your work email ensures you can easily connect to your organization's tools. Download the desktop app from [stilla.ai/download](https://stilla.ai/download). The desktop app is required for meeting transcription and provides the best full-screen editing experience. Open the app and follow the onboarding flow to connect your primary tools. * **Slack:** For reading conversations and sending messages. * **Linear:** For managing tasks and issues. * **GitHub:** For tracking PRs and code changes. * **Notion:** For reading and updating documentation. * **Google Calendar:** For joining and recording meetings. You can always add more later in **Settings → Account → Connections**. You're ready to go! Try these first actions: * **Ask a question:** "What did we decide about the login flow?" * **Transcribe a meeting:** Stilla will automatically detect meetings on your calendar. * **Create a task:** Ask Stilla to "Create a Linear issue for..." ## Next steps Now that you're set up, explore these topics: ## Troubleshooting If you're having trouble adding a connection, make sure you have the necessary permissions in that platform. Admin access may be required for some connections. For additional help, join our [Slack community](/join-slack) or contact support. --- # Docs introduction > Learn how to use Stilla, the AI agent that keeps track of everything. # Welcome to Stilla documentation Stilla is the first multiplayer AI agent for product teams. It lives where you work, turning loose conversations into clear actions and keeping your entire team aligned without the overhead. ## What can Stilla do? - **Orchestrate your workflow** — Create Linear issues, draft GitHub PRs, update Notion pages, and send Slack messages directly from conversations. - **Capture context instantly** — Transcribe meetings, extract change proposals, and turn discussions into trackable work. - **Answer with full context** — Search across your entire stack (Slack, Linear, GitHub, Notion, Google Drive, Gmail) to answer questions with accurate, current information. - **Code and document** — Spin up coding agents to fix bugs, write features, or keep documentation in sync. - **Automate with agents** — Build reusable automations using plain English. Schedule them, trigger them from Slack, or run them manually. - **Stay aligned** — Stilla is multiplayer. The whole team sees the same context, preventing silos and reducing status meetings. New to Stilla? Start with our [Getting Started guide](/docs/getting-started) to be up and running in minutes. --- # GitHub > Manage issues, review PRs, search code, and automate development workflows. # GitHub Connect GitHub to manage issues and PRs, search code, review changes, and automate development workflows with [coding agents](/docs/agents/coding-agents). ## Setup GitHub supports both: - **User connection**: Personal connection for reading and writing (required for change proposals and PR creation) - **Organization channel**: Enables @Stilla mentions in repo issues and PRs ## Issue & PR management - **Create issues**: Specify title, description, assignees, labels, and issue types - **Update issues**: Change status, labels, assignees, or description - **Comment**: Add review feedback, context from meetings, or status updates - **Close/reopen**: Manage issue and PR lifecycle ## Code search Search across your connected repositories: - **Code**: Find specific functions, patterns, or configurations - **Commits**: Search commit messages and history - **Issues & PRs**: Find by keyword, author, label, status, or date - **Discussions**: Search repository discussions ## Repository exploration Stilla can browse and read repository contents: - Navigate directory structures - Read individual files - View commit history and diffs - Understand codebase architecture ## Code review Stilla performs structured code reviews on pull requests: - Reads the full diff - Analyzes for bugs, security issues, performance problems, and style concerns - Posts detailed review comments organized by severity - References relevant context from Linear issues, meeting notes, and documentation ## PR creation [Coding agents](/docs/agents/coding-agents) push changes to branches and create pull requests with: - Clear, descriptive titles - Detailed descriptions of what changed and why - Proper base branch targeting - Draft or ready-for-review status ## Channel-based triggers (playbooks) Configure custom [agent](/docs/agents/overview) behaviors for specific repositories: - Auto-review all new PRs with your team's checklist - Triage new issues by labeling and assigning based on content - Notify relevant team members when specific files are changed --- # Google Workspace > Calendar, Drive, and Gmail — all connected through one account. # Google Workspace Connect your Google account to give Stilla access to Calendar, Drive, and Gmail. ## Setup Connect your Google account in **Settings → Account → Connections** ## Google Calendar - **View events**: See your schedule, check availability, and understand meeting context - **Meeting transcription**: Stilla uses your calendar to identify meetings and [join them for transcription](/docs/basics/meetings) - **Draft events**: Create calendar event drafts with title, time, attendees, and description - **Schedule awareness**: When you ask Stilla about timing, it considers your calendar - **Google Group attendees**: If a meeting invite contains a Google Group, Stilla expands it when Google exposes the members to your connected account ## Google Drive - **Search files**: Find documents, spreadsheets, and presentations across your Drive - **Read content**: Access the full content of Google Docs, Sheets, and Slides - **Create documents**: Generate new Google Docs with content from conversations, meetings, or analysis - **File analysis**: Upload files from Drive for Stilla to analyze, summarize, or extract information ## Gmail - **Search email**: Find messages by sender, subject, date, or content - **Read threads**: Access full email conversations with all replies - **Send emails**: Compose and send emails with formatted content - **Reply to threads**: Continue existing email conversations - **Attachments**: Access and process email attachments --- # Linear > Create issues, track projects, and manage work from Stilla. # Linear Linear is Stilla's default task management integration. Create and update issues, track projects, manage customer requests, and stay on top of your team's work. ## Setup Linear supports both: - **User connection**: Personal connection for reading and writing issues (required for change proposals) - **Organization channel**: Enables @Stilla mentions in Linear issues ## Issue management Stilla can create, update, and comment on Linear issues: - **Create issues**: Specify title, description, team, assignee, priority, labels, project, and cycle - **Update issues**: Change status, priority, assignee, or any other field - **Comment**: Add context, meeting notes, or status updates to existing issues - **Search**: Find issues by keyword, assignee, status, team, project, label, or date range When Stilla proposes issue changes, they appear as [change proposals](/docs/basics/canvases) in your canvas. Review and accept to apply changes to Linear. ## Project tracking - Search and browse projects across teams - Post project updates with health status (on track, at risk, off track) - Track progress across project milestones - View project members and recent activity ## Initiatives & documents - Access and update Linear initiatives - Read and modify Linear documents - Link work across initiatives, projects, and issues ## Customer tracking - Manage customer records with domains and external IDs - Create and update customer requests (needs) - Link customer requests to issues or projects - Filter by customer tier, status, and owner ## Teams & workflows Stilla works with all your Linear teams (not private teams yet) and respects their specific configurations: - Team-specific workflow states - Team-specific labels - Cycle management (current, upcoming, previous) - Priority levels and custom fields ## Bi-directional Stilla works in both directions: - **From Stilla**: Create change proposals to modify Linear from canvases, meetings, or chat - **From Linear**: Mention @Stilla in any Linear issue to ask questions, get context, or request actions --- # MCP (Model Context Protocol) > Connect any external tool to Stilla through the open MCP standard. # MCP (Model Context Protocol) MCP is an open protocol that lets you connect virtually any external tool or API to Stilla. If a service provides an MCP server, Stilla can use it — no custom integration required. ## What MCP is The [Model Context Protocol](https://modelcontextprotocol.io/) is a standard for connecting AI systems to external tools. Instead of building bespoke integrations for every service, MCP provides a universal interface that any tool can implement. For Stilla, this means the list of tools you can connect is effectively unlimited. ## How it works MCP servers are encapsulated as subagents within Stilla. Each MCP connection gets its own isolated agent with access to that server's tools. When Stilla needs to interact with an MCP-connected service, it delegates to the appropriate subagent. ### Transport Stilla supports remote MCP servers using the **Streamable HTTP** transport. MCP servers must be accessible via HTTPS. ### Authorization MCP connections support multiple authorization methods: - **Custom headers**: Add API keys or tokens as HTTP headers - **OAuth**: Full OAuth 2.0 authorization flow for services that require it Stilla handles the complete OAuth flow, including token refresh. ## Curated registry Stilla maintains a curated list of verified MCP servers you can connect with one click: - **PagerDuty**: Incident management, on-call schedules, service health - **PostHog**: Product analytics, feature flags, experiments - **Polar**: Open-source funding and subscription management - And more being added regularly Browse the full registry at [stilla.ai/integrations](https://stilla.ai/integrations). ## Custom MCP servers Connect any MCP-compatible server by providing its URL: 1. Go to **Settings → Account → Connections** 2. Select "Add MCP Server" 3. Enter the server URL 4. Configure authorization (headers or OAuth) 5. Stilla discovers available tools automatically ## Building MCP servers If you maintain an internal tool or API, you can build an MCP server for it and connect it to Stilla. The MCP specification is open and documented at [modelcontextprotocol.io](https://modelcontextprotocol.io). All changes to external systems through MCP use [change proposals](/docs/basics/canvases). Stilla never modifies MCP-connected systems without your approval. --- # Notion > Search, read, and update your Notion workspace from Stilla. # Notion Connect Notion to search pages, read documentation, and keep your workspace up to date based on meeting discussions and decisions. ## Setup Notion requires an **MCP connection**. Connect your personal Notion account in **Settings → Account → Connections** to give Stilla access to your workspace. ## What Stilla can do ### Search & read - Search across all pages in your connected Notion workspace - Read page content including text, databases, and embedded media - Follow links between pages to understand context ### Update pages - Edit existing page content based on new information - Keep documentation in sync with decisions made in meetings or chat - Update project specs when requirements change Changes to Notion are made through change proposals using Stilla's MCP integration. You review the proposed changes before they're applied. ## Common use cases - **Meeting follow-up**: After a meeting where a spec was discussed, Stilla updates the Notion page to reflect decisions - **Documentation sync**: When code changes affect documented behavior, Stilla proposes updates to the relevant Notion pages - **Knowledge retrieval**: Ask Stilla questions and it searches Notion alongside other connected tools for comprehensive answers Stilla can only access pages that your connected Notion account has permission to view. Ensure the pages you want Stilla to work with are accessible to your account. --- # Integrations Overview > Connect your tools so Stilla can search, act, and stay in sync. # Integrations overview Stilla connects to your tools so it can search across them, take actions, and keep everything in sync. The more you connect, the more context Stilla has to work with. ## How integrations work Stilla connects through two mechanisms: ### User connections Personal connections tied to your individual account. These give Stilla access to your data in each platform: - Your Linear issues and projects - Your GitHub repos and PRs - Your Google Calendar, Drive, and Gmail - Your Notion workspace - MCPs (with OAuth, or custom headers) - Connect to tools with API keys Set up user connections in **Settings → Account → Connections** in the Stilla app. ### Organization channels Organization-wide connections that enable Stilla in shared spaces: - **Slack**: Let anyone mention **`@Stilla`** in Slack channels - **GitHub**: Let anyone mention **`@Stilla`** in repo issues and PRs - **Linear**: Let anyone mention **`@Stilla`** in Linear issues - **Discord**: Let anyone mention **`@Stilla`** in Discord channels - **Zoom**: Let anyone sync transcribed Zoom meetings into Stilla for notes and action items Organization channels are set up by workspace admins. ## Available integrations Stilla supports 35+ integrations across these categories: | Category | Integrations | | ---------------------- | ---------------------------------------------------------------- | | **Project Management** | Linear, Asana, Todoist | | **Communication** | Slack, Discord, Gmail | | **Code** | GitHub | | **Knowledge** | Notion, Google Drive, Mintlify | | **Calendar** | Google Calendar, Clockwise | | **Meetings** | Zoom | | **Analytics** | PostHog, Amplitude, Mixpanel | | **CRM** | Attio, HubSpot | | **Infrastructure** | Cloudflare, Vercel, Sentry, PagerDuty, Honeycomb, Supabase, Neon | | **Payments** | Stripe, Polar | | **Customer Comms** | Intercom, Customer.io | | **Extensibility** | Any tool via [MCP](/docs/integrations/mcp) | Browse the full list at [stilla.ai/integrations](https://stilla.ai/integrations). ## Setting up connections Navigate to **Settings → Account → Connections** in the Stilla app. Select the platform you want to connect. Follow the OAuth flow to grant Stilla access. You'll be redirected to the platform to approve permissions. Once connected, Stilla can immediately search, read, and (where applicable) write to that platform. Some connections require admin access to your organization's account (e.g., Slack organization channel). Check with your workspace admin if you can't complete a connection. --- # Slack > Chat with Stilla in Slack, send messages, and automate channel workflows. # Slack Connect Slack to chat with Stilla directly in your channels, read conversations for context, and send messages as part of automated workflows. ## Setup Slack requires an **organization channel** connection. A workspace admin installs the Stilla app in your Slack workspace, which enables @Stilla mentions across all channels. ## What Stilla can do in Slack ### Read & search - Search message history across channels Stilla has access to - Read full conversation threads for context - List channel members and metadata - Browse channel topics and purposes ### Write - Send messages to channels or direct messages - Reply to specific threads - Add emoji reactions to messages - Tag users, channels, and user groups using natural formats ### Agent channels Configure custom [agent](/docs/agents/overview) behaviors for specific Slack channels. Stilla responds differently depending on which channel it's mentioned in: - **#support**: Follow triage steps, search knowledge base, escalate if needed - **#engineering**: Pull relevant PRs and issues, check CI status - **#general**: Answer general questions with full context See [Triggers](/docs/agents/triggers) for setup details. ## Auto-trigger mode By default, Stilla requires an @Stilla mention to respond in Slack. For intake channels like #support-requests or #feedback, you can disable the mention requirement so Stilla processes **every** message automatically. This is configured per-channel in your agent's trigger settings. ## Message formatting Stilla automatically converts markdown to Slack's mrkdwn format. Write naturally with markdown — bold, italic, links, lists, and code blocks all render correctly in Slack. ## Tagging Tag people, channels, and groups using natural formats: - `@user@example.com` or `@display-name` — tag a user - `#channel-name` — tag a channel - `@team-handle` — tag a user group Stilla resolves names and emails to Slack IDs automatically. --- # Stilla MCP > Access your Stilla workspace from Claude Code, Cursor, and other MCP-compatible tools. # Stilla MCP Connect your AI tools to Stilla via the [Model Context Protocol](https://modelcontextprotocol.io) — giving them direct access to your team's meeting notes, decisions, canvases, and transcripts. ## Capabilities - **Search your workspace** — Find canvases, meeting notes, and agent outputs by topic or keyword - **Read meeting notes and transcripts** — Access full notes, summaries, and recordings from any meeting - **Pull context while coding** — Retrieve decisions, specs, and action items while writing code - **Inspect workflow outputs** — Access workflow runs, agent memory, and synthesis canvases ## Setup Add Stilla as a remote MCP server using this URL: ``` https://api.stilla.ai/mcp ``` Stilla uses OAuth for authentication. You'll be prompted to sign in the first time you connect. --- # Zoom > Automatically turn Zoom meetings into collaborative Stilla canvases with notes and action items. # Zoom Connect your organization's Zoom account once to turn meetings into collaborative Stilla canvases automatically. Stilla imports Zoom transcripts and generates meeting notes, decisions, and action items for your team. You must be a Stilla workspace admin and a Zoom account admin. Enable Cloud Recording audio transcripts or AI Companion meeting transcripts in Zoom. Meeting hosts should use the same work email in Zoom and Stilla. Stilla does not join or record Zoom meetings. It uses transcripts produced by Zoom after the meeting. ## Add Stilla to Zoom [Sign in to Stilla](https://app.stilla.ai) as a workspace admin, or [create a workspace](https://stilla.ai/signup) if your organization does not have one. Go to [Settings → Organization → Channels](https://app.stilla.ai/settings/org/channels?channel=zoom). Find Zoom, select **Connect**, and sign in to Zoom as an account admin. Review the requested read permissions and authorize Stilla for the Zoom account. Zoom redirects you back to Stilla when the connection is complete. Return to **Settings → Organization → Channels** and confirm that Zoom is shown as connected. See [Troubleshooting](#troubleshooting) if Zoom is unavailable or authorization does not complete. ## How it works After an admin connects Zoom, no additional action is required for future meetings hosted by people in the Stilla workspace: 1. Zoom makes a Cloud Recording or AI Companion transcript available. 2. Stilla associates the meeting with its workspace host. 3. Stilla creates a meeting canvas and generates notes, decisions, and action items from the transcript. 4. The meeting knowledge can be edited, shared, and used across Stilla. If Zoom is still processing a transcript when the meeting ends, Stilla retries automatically. Zoom meeting canvases use Stilla's standard workspace permissions. Canvas owners can review and adjust sharing at any time. ## Meeting canvases and access Stilla associates each imported meeting with the matching workspace host. The resulting meeting canvas can be edited and shared like any other Stilla canvas. Access follows your workspace's standard canvas permissions. The canvas owner can share meeting knowledge with the teammates who need it and change access at any time. ## Data access and handling Stilla requests read access needed to identify the connected Zoom account, receive supported meeting events, and retrieve transcripts and meeting metadata. Stilla stores: - Zoom account and installation metadata - OAuth access and refresh tokens, encrypted at the application layer - Meeting metadata and transcript text in the resulting Stilla canvas Stilla does not copy Zoom video or audio files as part of this integration. Access to imported content follows Stilla workspace permissions and retention settings. See the [Privacy Policy](/legal/privacy-policy) for more information. ## Remove Stilla from Zoom You can disconnect Zoom from Stilla or remove Stilla in the Zoom App Marketplace. ### Disconnect in Stilla 1. Sign in to Stilla as a workspace admin. 2. Open **Settings → Organization → Channels**. 3. Find Zoom and select **Disconnect**. 4. Confirm the disconnection. Stilla revokes its Zoom authorization, removes the stored Zoom connection and OAuth credentials, and stops future imports. ### Remove in the Zoom App Marketplace 1. Sign in to the [Zoom App Marketplace](https://marketplace.zoom.us/). 2. Select **Manage** and then **Added Apps**. 3. Find and open Stilla. 4. Select **Remove** and confirm. Zoom revokes the authorization and notifies Stilla to remove the connection. Previously imported meeting canvases remain in Stilla so users do not unexpectedly lose their work. Workspace members can delete those canvases in Stilla, subject to their permissions and organization retention settings. ## What happens after removal Disconnecting or removing Stilla stops new Zoom meeting canvases and transcript imports. Existing canvases, notes, and action items remain available in Stilla until they are deleted under your workspace's normal retention and access policies. ## Troubleshooting ### Zoom is not available in Stilla Only Stilla workspace admins can connect organization integrations. Confirm that you are an admin, then reload **Settings → Organization → Channels**. Contact [Stilla Support](/docs/support) if Zoom is still unavailable. ### Zoom authorization fails Confirm that you are both a Stilla workspace admin and a Zoom account admin. If you previously denied access, start the connection again and approve the requested permissions. ### A meeting was not imported Check that: - The host uses the same work email in Zoom and Stilla - The host is an active member of the connected Stilla workspace - Zoom generated a Cloud Recording audio transcript or AI Companion meeting transcript - Zoom finished processing the transcript - The meeting belongs to the connected Zoom account Zoom transcripts can take several minutes to become available. Stilla retries temporary Zoom processing and API failures automatically. If these checks pass and the meeting still does not appear, contact [Stilla Support](/docs/support). ### A teammate cannot see the meeting Meeting canvas access follows Stilla workspace permissions. Ask the canvas owner or a workspace admin to review the canvas sharing settings. ### The wrong host received the meeting Stilla assigns the canvas to the Zoom host by email. Confirm that the host uses the same work email in both systems, then contact [Stilla Support](/docs/support) if the problem continues. ## Contact support For help adding, using, or removing the Zoom integration, email [support@stilla.ai](mailto:support@stilla.ai) or review the [Stilla support options](/docs/support). We aim to reply within 24 hours. --- # Built-in models > The language and image models currently available in Stilla. # Built-in models Built-in models are ready to use without provider setup. Stilla manages the provider connection and credentials, while organization administrators can choose which models are available to their workspace. ## Language models | Model | Creator | Best for | Notes | | -------------------- | --------- | --------------------------------------------------------------------------------- | ------- | | **Sonnet 5** | Anthropic | Anthropic's most agentic Sonnet model, near Opus-class capability at lower cost. | Default | | **Opus 5.5** | Anthropic | Anthropic's Opus model for long-running coding and knowledge work. | — | | **GPT-6 Astra** | OpenAI | OpenAI's most capable model, for complex reasoning and long-horizon agentic work. | — | | **GPT-6 Sol** | OpenAI | OpenAI's model for complex coding and agentic workflows. | — | | **GPT-5.6 Terra** | OpenAI | Balanced GPT-5.6 for everyday work at lower cost. | — | | **GPT-6 Luna** | OpenAI | OpenAI's most efficient model for focused, high-volume tasks. | — | | **Gemini 3.7 Flash** | Google | Google's fast model. Quick responses at lower cost. | Beta | | **Gemma 4** | Google | Google's low-cost open model for simple, routine tasks. | — | **Default** is the model Stilla selects when a workspace has not chosen another. **Beta** models are new additions we're still testing. We're continuously adding and testing new models. Missing one you'd like to use? [Contact us](/docs/support). ## Image models | Model | Creator | Best for | Notes | | -------------------------- | ------- | ---------------------------------------------------------------------------- | ------- | | **Gemini 3.1 Flash Image** | Google | Google's fast image generation model. | Default | | **Gemini 3 Pro Image** | Google | Google's highest-quality image generation, for detailed renders. | — | | **GPT Image 2** | OpenAI | OpenAI's image generation model, strong at text rendering and precise edits. | — | ## Using your own provider account See [Bring your own model credentials](/docs/models/byok) to run a compatible model on your provider account. --- # Bring your own model credentials > Run Stilla models with your own Anthropic, OpenAI, Google Cloud Agent Platform, or compatible custom endpoint credentials. # Bring your own model credentials Bring your own credentials (BYOK) lets Stilla orchestrate work while model requests run on an account your organization controls. Your provider bills the model usage and applies its own quotas, data controls, and regional policies. Organization administrators manage models under [Settings → Organization → Models](https://app.stilla.ai/settings/org/models). Choose **Add model**, then pick one of the three setup types below. Credentials are encrypted at rest and are not displayed again after saving. BYOK is very experimental and currently available only to select customers. [Contact support](/docs/support) if the controls are not visible. ## Built-in model with your API key Use this option when you want a model from Stilla's [built-in catalog](/docs/models/built-in-models) to run against a provider account you pay for. Stilla keeps the model's tested context window, tool behavior, and API adapter; you provide only a display name, model, and key. The model picker only shows models compatible with this credential type. | Provider | What it can run | How to get a key | | ------------------------ | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Anthropic** | Built-in Claude models with a direct Anthropic route. | Create a standard API key in the [Anthropic Console](https://console.anthropic.com/settings/keys). The [Anthropic access guide](https://support.anthropic.com/en/articles/8114521-how-can-i-access-the-anthropic-api) also covers billing and team setup. | | **OpenAI** | Built-in GPT models with a direct OpenAI route. | Create a project key under [OpenAI API keys](https://platform.openai.com/api-keys). Use a normal project key, not an organization admin key. See [OpenAI authentication](https://platform.openai.com/docs/api-reference/authentication). | | **Google Cloud API key** | Built-in Gemini models through Agent Platform express mode. | Create a key in [Agent Platform Studio](https://console.cloud.google.com/agent-platform/studio/settings/api-keys) or follow Google's [Agent Platform API key guide](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/start/api-keys). This key type supports Gemini `generateContent`; it does not unlock Claude or other partner models. | Enable billing and model access with the provider. Prefer a project or service credential made only for Stilla, with the narrowest permissions the provider offers. In Stilla, enter a recognizable display name, select a compatible model, and paste the key. ## Google Cloud Agent Platform (formerly Vertex AI) Use Agent Platform when requests should run in your Google Cloud project. Stilla supports chat models from Google and other Model Garden providers through these Agent Platform API contracts: - **Google Gen AI** for Gemini models - **Anthropic Messages** for Claude partner models - **OpenAI-compatible Chat Completions** for managed MaaS models, self-deployed endpoints, and OpenAI-shaped publisher `rawPredict` APIs such as Mistral Agent Platform models are configured independently of Stilla's [built-in model list](/docs/models/built-in-models). Choose the API contract the model exposes, then supply its Agent Platform endpoint URL and exact provider model ID. ### Prepare Google Cloud Attach a billing account, then [enable the Agent Platform API](https://console.cloud.google.com/apis/library/aiplatform.googleapis.com). Open [Model Garden](https://console.cloud.google.com/vertex-ai/model-garden), select the model's managed API or **API Service** card, and choose **Enable**. Accept provider terms when prompted. Google documents this flow for [Claude partner models](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/partner-models/use-claude) and [open-model MaaS](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/open-models/use-maas). In [IAM → Service Accounts](https://console.cloud.google.com/iam-admin/serviceaccounts), create an account for Stilla and grant it **Agent Platform User** (`roles/aiplatform.user`) in the project. Do not grant Owner or Editor just to make model calls. Open the service account, choose **Keys → Add key → Create new key → JSON**, and store the download securely. Google's [service-account key guide](https://docs.cloud.google.com/iam/docs/keys-create-delete) explains the required permissions and organization-policy restrictions. A service-account JSON key is required for Agent Platform models. Treat it like a password: keep the account dedicated and least-privileged. ### Add the Agent Platform model to Stilla Choose **Agent Platform** in Stilla and give the model a recognizable name. Select the API contract described above, then copy the endpoint URL and model ID from the model's sample code in Model Garden. Paste the complete service-account JSON key. You can paste the endpoint URL exactly as Google provides it—Stilla handles validation and routing. Set the context-window and output-token limits if you know them, or leave them blank to use the defaults. ## Custom endpoint Use a custom endpoint for a model or gateway that is not in Stilla's built-in catalog. The endpoint must be publicly reachable over HTTPS. The provider does not need an explicit Stilla integration. Any provider or gateway can work, including providers such as OpenCode Zen and Fireworks AI, if its public endpoint supports API-key authentication and streaming responses. Select the API your provider supports and paste the endpoint URL it gives you. Stilla supports: - **OpenAI Responses** - **OpenAI Chat Completions** - **Anthropic Messages** - **Google Gemini** Create an API key with the endpoint operator. There is no universal key issuer for custom endpoints; the key must be valid for the URL and model ID you enter. Enter the exact provider-side model ID. Optionally set its context window and maximum output tokens. ## Rotation and troubleshooting Edit a model to replace its API key or Agent Platform service-account JSON. Stilla verifies the new credential before saving it; the old value remains active if verification fails. Removing a model discards its stored credential. The model's name remains attached to existing conversations so they remain understandable. Common setup failures: - **Authentication failed:** Create a fresh key, confirm billing is active, and make sure it belongs to the intended provider project or workspace. - **Model not found or access denied:** Enable the model, accept its terms, check the exact model ID, and confirm your account has access. - **Agent Platform project or region error:** Copy an endpoint from the model's Google Cloud sample code and confirm its `/projects/.../locations/...` values. Partner-model regions can differ from Gemini regions. - **Service-account key creation is unavailable:** Check the `iam.disableServiceAccountKeyCreation` organization policy or ask a Google Cloud organization administrator. - **Custom endpoint rejected:** Use a public `https://` URL. Private-network endpoints and URLs containing embedded usernames or passwords are not supported. - **Verification times out:** Confirm the provider is healthy and the endpoint can return a minimal generation request promptly, then try again. For help, [contact Stilla support](/docs/support) with the model name, setup type, provider error, and Agent Platform project/location or custom endpoint host. Never send the API key or service-account JSON. --- # Prompt Injection Security at Stilla > Stilla limits what an AI model can access, change, and communicate if it is manipulated by prompt injection or simply makes a mistake. # Prompt injection security at Stilla **Stilla assumes an AI model can be manipulated or simply get something wrong.** It may follow a prompt injection, misunderstand a legitimate request, confuse one destination with another, or choose an action the user did not intend. Our security model does not depend on the model always recognizing malicious instructions or making the right judgment. Instead, controls enforced outside the model limit what data it can access, where it can communicate, and which changes it can make. No AI system can fully prevent prompt injection or eliminate model error today. This page explains the threat we design for, the boundaries Stilla enforces when the model is influenced or mistaken, and the responsibilities that remain with organizations using AI agents. ## Our position Prompt injection occurs when untrusted content — such as an email, document, web page, chat message, or tool response — contains instructions intended to manipulate the model. The model may treat those instructions as legitimate context and disclose information, contact an unintended recipient, or take an unwanted action. Prompt injection is one cause of unsafe model behavior, but it is not the only one. A model can reach the same bad decision without an attacker. The safeguards described here are designed to constrain both adversarial manipulation and ordinary mistakes. The greatest risk appears when an AI system combines three capabilities: 1. Access to private data 2. Exposure to untrusted content 3. The ability to communicate externally or make consequential changes Simon Willison calls this combination the ["lethal trifecta"](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/). Stilla has all three capabilities because useful work often requires reading private information, understanding content from outside the organization, and acting on a person's behalf. We therefore treat the model as a fallible and potentially influenced component, not as the security boundary. The important question is not only why the model made a bad decision, but what authority remains available after it does. ## Security boundaries ### Runtime restriction policies The model does not decide whether an operation is authorized. Stilla evaluates restriction policies in application code when the AI reads data, calls a tool, accesses the network, or executes a change proposal. These checks apply regardless of whether an instruction came from a person, an agent definition, an email, a document, a web page, or a tool result. Policies can come from several layers: - An **organization policy** applies to every interaction, including regular chats, shared-channel conversations, and agent runs. - **User-group policies** are merged with the organization policy to produce the user's effective policy. At the same policy layer, a group setting takes precedence over the organization setting; when several groups define that layer, the most permissive group setting applies. - An **agent policy** is evaluated in addition to the user's effective policy. Both must allow the operation, so an agent can be more restricted than its user but cannot use its own policy to bypass the user's restrictions. Administrators can set a default policy for newly created agents. The user's effective policy remains active in regular chats where no agent policy applies. Policies can govern an entire connection or an individual operation. This includes native Stilla integrations and the discovered tools on individual MCP and Pipedream connections. For example, an organization can permit GitHub reads and issue comments without permitting issue creation. ### Resource-level rules Resource rules separate what Stilla may learn from where it may act. An organization can keep broad read access while granting write access only for selected recipients, conversations, repositories, folders, drives, files, or canvases. For example, a policy can allow Stilla to: - Read any email, but send only to the current user, `me@example.com`, or recipients at an approved domain. - Read only public Slack channels, keeping private channels and other direct messages out of scope, and send only to the user's own DM or a specific internal channel such as `#incident-response`. - Use Google Drive broadly, while preventing access to sensitive documents in specific shared drives or folders. - Read every GitHub repository, but comment or open issues only in one repository. - Read across the Stilla workspace, but edit only canvases in a particular folder, with an exception for a specific canvas when needed. Stilla evaluates every target independently. An email or calendar invitation with several recipients is allowed only if every address passes the policy; an injected extra recipient cannot borrow permission from an approved one. More-specific rules take precedence over broader ones. A file rule can override its folder and drive, a canvas rule can override its folder, and an exact email address can override a domain rule. The decision uses the resource actually being accessed or changed, rather than relying on the model's description of what it intends to do. ### Credential isolation Stored API keys, refresh tokens, and long-lived OAuth credentials are kept outside the model's context. Native integrations authenticate on the server, and sandbox commands start without third-party credentials unless an administrator has deliberately made one available as an [organization secret](/docs/security/secrets). Access to one user's account does not grant access to another user's account. For tools that run inside Stilla's sandboxed computer: - **GitHub:** Stilla mints a short-lived installation token scoped to the repositories named by the command and the minimum permissions required for the operation. - **Google Workspace:** the sandbox never receives a Google OAuth bearer token. It receives a short-lived Stilla proxy credential tied to the user and canvas. A Stilla-maintained build of the [`gws` CLI](https://github.com/googleworkspace/cli) sends supported requests through Stilla's reverse proxy, where live user and agent restrictions are reloaded and enforced before Stilla attaches the Google credential on the server. Google Workspace writes use a separate change-proposal executor and are checked again when executed. The model can request an operation, but it does not receive the stored credential or raw Google access token. ### Network enforcement Network controls apply to both Stilla's web tools and its sandboxed computer: - **Web search and fetch:** Stilla checks whether web access is allowed and validates each requested URL against the effective network policy before fetching it. - **Sandbox computer:** HTTP and HTTPS traffic passes through an authenticated egress proxy that enforces the effective allowlist and blocklist. A shell command cannot bypass the same boundary by using `curl`, a package manager, or another HTTP client. Organizations can block network access, use Stilla's trusted-source defaults, define their own allowed destinations, or allow unrestricted access. User and agent network policies are combined using the more restrictive result. ### Change proposals and human authorization Stilla represents supported changes to connected systems — such as sending an email, posting a message, editing a calendar event, or creating an issue — as change proposals. A proposal starts pending and makes the intended change available for review. A person can accept a proposal in Stilla. In workflows where an agent is allowed to execute proposals on its own, every applicable restriction policy must authorize the operation, and Stilla checks the current target resources again at execution time. Some destinations add stronger safeguards: - **Slack Connect:** an agent cannot send messages or add reactions in externally shared Slack channels on its own. A person must accept and execute the proposal. - **External email and calendar participants:** an agent cannot execute a non-draft Gmail or Outlook Mail send, or a Google or Outlook Calendar invitation or update, involving an external address unless that person is an organization member or the address or domain is explicitly allowed by a resource rule. Otherwise, the proposal waits for a person. Agent restrictions do not prevent an authorized person from reviewing and accepting a pending proposal in the app. Human acceptance is a separate authorization decision. ### Third-party connections and MCP servers Organization administrators can disable integrations whose data should not be available to Stilla. They can also restrict individual native, MCP, and Pipedream connections and tools. An MCP server can itself span all three legs of the lethal trifecta. Stilla treats each server as a separate restriction-policy system. Stilla uses the server-provided `readOnlyHint` tool annotation to distinguish reads from mutations and routes tools it treats as mutating through change proposals. Because the server supplies this tool annotation and the tool implementation, connecting an MCP server extends the organization's trust boundary; organizations should connect only servers they trust and restrict their tools to the minimum necessary access. ## What is automatic and what organizations configure | Control | Built-in behavior | Organization control | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Policy enforcement** | Stilla enforces every applicable policy outside the model and checks live policy again when an agent executes a proposal. | Administrators define organization and group policies, default policies for new agents, and resource or tool exceptions. Least-privilege access must be configured for the organization's use case. | | **Credentials** | Stored and long-lived credentials are kept out of model context. Integration credentials are not placed directly into the sandbox; organization secrets are the deliberate exception and are denied by default. | Administrators and users decide which integrations to connect; administrators can disable selected integration types, choose which organization secrets exist, and decide which agents may use them. | | **Network** | Web tools and sandbox traffic pass through the same policy enforcement. New agents defer to the organization's network setting. | Administrators choose block-all, trusted sources, a custom allowlist, or allow-all; agent policies can narrow this further. | | **Change proposals** | Supported connected-system changes begin as pending proposals and restrictions are checked before agent execution. | An agent may execute an allowed proposal when instructed. A person may instead review and accept it, including changes that agent policy would not permit the agent to execute. | | **External destinations** | Slack Connect requires a person. External mail and calendar participants require a person unless explicitly authorized by policy. | Administrators can allow specific external email addresses or domains for agent execution. | ## Examples under attack ### A malicious email requests forwarding An email contains hidden instructions telling Stilla to find sensitive messages and forward them to an attacker. A policy may allow the email to be read while permitting sends only to the user's own address. The proposed external recipient fails the resource check and the agent cannot execute the send. ### A web page requests an upload A page tells the sandbox to upload private files to another domain. Whether the model uses a web-fetch tool or tries a command-line HTTP client, the destination is checked against the effective network policy. A destination outside the allowlist is blocked. ### A Slack message requests external disclosure An organization can limit Slack reads to public channels and writes to the user's own DM or a specific internal channel. If injected content requests a post elsewhere, the resource policy rejects it. An agent also cannot execute a post to a Slack Connect channel on its own. ### A document hides an additional attendee A document instructs Stilla to create a calendar event and quietly add an external attendee. Stilla evaluates every attendee separately. Unless that external address is an organization member or is explicitly authorized by policy, the agent cannot execute the proposal. ## Detection and response Stilla gives the model a built-in path to report suspected abuse and unsafe use. In practice, Stilla regularly flags different kinds of potential prompt-injection attacks, which our team investigates. Reports identify the originating user and, when available, the chat or canvas where the concern occurred. The reporting tool requests only a short, generic description and instructs the model not to include private user content, secrets, filenames, message text, or raw tool data. It does not automatically attach a transcript or tool output. What we learn from investigations informs improvements to our safeguards. Reporting is a detection and response measure, not an authorization boundary. Restriction policies, credential isolation, network enforcement, and change-proposal checks remain active whether or not an attack is recognized or reported. ## Limitations and customer responsibilities Stilla's controls reduce the likelihood and potential impact of prompt injection, but they do not make the model immune to malicious content. - Prompt injection may still influence the model's reasoning, output, or choice of attempted action. - An operation that is within the effective policy remains available to the agent. Broad access creates a broader potential blast radius, so organizations should use least privilege for agents that process untrusted content. - A person can authorize a proposal that an agent could not execute. Reviewers should check the content, destination, recipients, and target resources before accepting consequential changes. - Third-party integrations and MCP servers have their own security properties. Organizations should connect trusted services and limit each connection and tool to what the workflow needs. - Detection is not perfect. A suspected attack may not be recognized or reported, which is why enforcement does not depend on detection. For higher-risk workflows, we recommend starting with no access or read-only access, granting only the required tools and resources, restricting network destinations, and requiring human review until the workflow's behavior is well understood. See [Agent restrictions](/docs/agents/restrictions) for configuration guidance. This approach follows the central principle in [Design Patterns for Securing LLM Agents against Prompt Injections](https://arxiv.org/abs/2506.08837): after an agent consumes untrusted input, consequential capabilities should be limited by controls the untrusted input cannot override. For questions about Stilla's security practices, see our [Trust Center](https://trust.stilla.ai/), visit our [Security](/security) page, or contact security@stilla.ai. --- # Secrets > Store credentials your agents can use in sandbox commands, and understand how a secret can still leak. # Secrets Secrets let an administrator store a credential once and make it available to chosen agents inside Stilla's sandboxed computer. The agent asks for a secret by name, and Stilla injects the value as an environment variable without adding it to the model's context. The value may still reach the model if a command prints it: command output is sent back to the model and saved in the chat without redaction. Without secrets, a credential an agent needs must be pasted into a chat message or into the agent's instructions. It then stays in that conversation permanently, is readable by anyone who can open it, and is sent to the model with every request. Storing it as a secret instead avoids putting the value directly into the model's context, limits which agents may use it, and records every use. Administrators manage secrets under [Settings → Secrets](https://app.stilla.ai/settings/org/secrets), on the Team plan and above. Stilla controls which agents may use which secret. It does not control what a command does with the value once it runs. If a command prints a secret, the value is exposed to the model and chat. ## What a secret consists of | Field | Rules | | --------------- | ----------------------------------------------------------------------------------------- | | **Name** | Uppercase letters, digits, and underscores, starting with a letter. Up to 100 characters. | | **Value** | Up to 64,000 characters. Encrypted at rest. Never shown again after saving. | | **Description** | Optional, up to 500 characters. Shown to the agent so it can pick the right one. | The name is the environment variable the agent references, so it cannot change without breaking existing commands. Names the sandbox already uses, such as `PATH` and `GITHUB_TOKEN`, are rejected. The value is write-only: no API returns it. ## Granting access Adding a secret does not grant access to it. A restriction policy must name the secret first. Secrets behave differently from the rest of the restriction system. For every other system, a policy that does not mention it falls back to the policy's default access. Secrets have no such fallback. If a policy does not name a secret, agents under that policy cannot use it, and an agent running without a policy cannot use any secret. You grant either the whole secrets system, which covers secrets added later, or one individual secret. The only levels are No access and Read, because an agent can use a value but can never create, change, or delete a secret. Both the agent's policy and the user's policy must allow the grant. Grants are keyed to the secret's identifier, so recreating a deleted secret under the same name does not carry the old grant over. ## How an agent uses a secret The agent calls `organization_secrets_query` for the names it is allowed to use, then names one in the `secrets` parameter of the shell tool. The query does not return secret values, and injection does not add them to the model's context. Command output can still expose them, for example through `echo $SECRET`. Injection lasts for one command. If any requested name is unknown or blocked, the whole call fails and nothing is injected. ## Rotating and deleting Rotating replaces the value in place, keeping the name, grants, and history. Deleting archives the secret and scrubs the value. Neither action affects a value that has already been used. If you suspect a value has been exposed, revoke it at the source first. ## Audit log Stilla records an audit event when a secret is created, rotated, or deleted, and each time one is injected into a command. No event stores the value. An injection event identifies the secret by name and records the user, the chat and canvas it ran in, and the command that requested it. The command is masked when the log is read, because it is free-form text that may contain anything the agent typed. Events are written only for injections that actually happened: if any requested name is unknown or blocked, the command fails and nothing is recorded against the secret. Each secret has its own usage log on its detail page, which is part of audit logging. Organizations without audit logging still see the usage count and last-used time in the settings table, and those track every injection. ## Ways a secret can still leak None of these require a malicious agent or an attacker. Assume that a granted secret can reach anywhere the agent's output reaches. - **The value is an ordinary environment variable.** Every process the command starts inherits it, including a script that dumps `env` or a dependency's install hook. - **Command output returns to the model.** Stilla does not scan or redact it. `echo $MY_KEY`, `curl -v`, `set -x`, or a tool that prints the credential in an error all put the value into the chat and the transcript. - **Conversation content spreads.** Once a value appears in a chat or canvas, it can be summarized, quoted into Slack, stored in agent memory, or read by anyone with access. - **Network rules limit destinations, not payloads.** The egress proxy controls which hosts a command may reach, not what it sends to an allowed host. - **Prompt injection can misuse a granted secret.** Policy decides which secrets an agent may use, not whether a particular use is sensible. See [Prompt injection security](/docs/security/prompt-injection). - **Rotation does not retract copies.** A value already in a transcript, a log, or a commit stays there. - **Installed packages run with the same environment.** Granting a secret to an agent that installs dependencies extends trust to whatever it installs. ## Reducing the risk - Issue a narrow, dedicated credential at the source. Stilla decides who may use a credential; it cannot make a broad one safe. - Grant one secret at a time instead of allowing all of them. - Keep secrets away from agents that read external email, public issues, or arbitrary web pages. - Restrict the sandbox's allowed network destinations. - Monitor the audit log for use the workflow does not intend. See also [Restrictions](/docs/agents/restrictions). --- # Support > Get help, join the community, or contact our team. # Support We're here to help you get the most out of Stilla. Whether you have a technical question, feedback on the product, or just want to say hi, there are several ways to reach us. ## Other ways to connect ### Enterprise support For enterprise inquiries, custom contracts, or dedicated success managers, please contact our sales team directly. [Contact Sales](mailto:sales@stilla.ai) ## Self service Before reaching out, you might find your answer in our documentation: - [Getting Started](/docs/getting-started) — Set up your account and first connections. - [FAQ](/docs/faq) — Answers to common questions about privacy, pricing, and features. --- Generated: 2026-09-22T20:04:43.736Z