# Auto Lab full public content corpus > Auto Lab is an AI that runs part of your business. Describe a goal, and it plans the week, does the work, checks in when it needs you and learns from every run. # Auto Lab – The AI that runs your business Auto Lab is an AI that runs part of your business. Describe a goal, and it plans the week, does the work, checks in when it needs you and learns from every run. Canonical page: https://app.auto-lab.ai/ ## Official resources - [Documentation](https://app.auto-lab.ai/docs) - [Auto Lab](https://auto-lab.ai) --- # Agents and skills The agents that work on a goal, what each one may use, and the skills they open when a task calls for one. Canonical page: https://app.auto-lab.ai/docs/brain/agents-and-skills Every goal has one agent that owns the work, plus task agents it hands single jobs to. **Skills** are written procedures the agents open when a task calls for one. You manage both in the Brain: **Brain › Agents** and **Brain › Skills**. ## The agents on a goal | Agent | What it does | |---|---| | The goal's agent | The one you talk to in Chat. It plans, decides what to do next and reaches you. It runs on Auto Lab's built-in instructions, plus your [goal instructions](/docs/brain#goal-instructions) and the goal's memory. | | Task agents | Research, Docs, Mail reader, Browser and Coder. Each run does one job and reports back. See [Chat and runs](/docs/goals/chat). | | Session agents | The agents listed in **Brain › Agents**. They do the work in sessions, for example when a coder task changes files or when you ask the agent to edit the Brain. | A new goal starts with a default agent, shown as **Auto Lab**, and a few helper agents that Auto Lab uses for planning and reviews. A session that names no agent runs the default agent. ## What the Agents tab shows Each card shows the agent's name and description, its model (or **Default model**), how many triggers start it, and who may use it. A star marks the default agent. Use **Default** at the top of the tab to pick a different one. Select a card to open the agent's page. Its topics are grouped on the left: | Group | Topics | What you set | |---|---|---| | General | **Overview**, **Basics**, **People**, **Triggers** | The description and **Instructions**, whether the agent is on, who may use it, and what starts it | | Access | **Skills**, **Connectors**, **Secrets** and Auto Lab actions | What the agent may use: **All**, **Pick** or **None** | | Runtime | **Model**, **Tools**, **Workspace** | Its default model, which built-in tools it may call, and where its sessions run | **Instructions** are told to the agent at the start of every session. When you change a field, a bar at the bottom says you have unsaved changes. **Save** commits the change to the goal's repository. **Start session** opens a session with this agent. Editing an agent needs the goal's admin role. **People** lets you grant a person or group the use of this agent; see [Roles and access](/docs/organization/access). ### Access is denied unless granted Each agent may use only the connectors, secrets, skills and Auto Lab actions its access rules grant. An agent with no rule for one of these gets none of it. The rules live in the goal manifest (`kortix.yaml`), and the **Access** topics edit them for you. The default agent of a new goal is granted everything. An agent never gets more than the person who started its session. In Chat, the goal's agent uses the default agent's connector access. ### Add or change an agent with the agent Select **New**, then **Create in chat**. Auto Lab opens a session where the agent asks what the new agent should do, writes it and opens a change request. To rewrite an agent's source the same way, open its page, select the **⋯** menu and choose **Edit source in a chat**. Nothing changes until someone applies the change request; see [Approvals and autonomy](/docs/goals/approvals). ## Skills A skill is a written procedure: how to do one kind of task, step by step, with any templates or scripts it needs. The agent sees a one-line description of every skill and opens the full text only when a task needs it. That keeps its instructions short while the goal's know-how grows. In Chat, the goal's agent and its task agents (except the browser) can open the goal's own skills. **Built-in** skills come with Auto Lab, are read-only and are used in sessions. ### Where skills come from | Source | How | |---|---| | You | Select **New** on **Brain › Skills**. Auto Lab opens a session where the agent writes the skill with you and opens a change request. | | The agent | Select **Edit with agent** on an existing skill. The agent makes the change in a session and opens a change request. | | Learning | After a long task, the agent writes down how it did it as a skill named `learned-…`. See [Learning](/docs/brain/learning). | | Marketplace | Add a ready-made skill. See [Add a skill from the Marketplace](#add-a-skill-from-the-marketplace). | ### Edit a skill 1. Open **Brain › Skills** and select the skill. Its file tree opens beside the text. 2. Select the file to change, usually `SKILL.md`. 3. Select **Edit source**, make the change, then select **Save to project**. The file is committed to the goal's repository right away. Saving does not run the skill. The direct editor works on existing text files up to 256 KiB inside the skill's folder. Built-in skills and executable files stay read-only, and you cannot add, rename or delete files here. For those changes, select **Edit with agent**: the agent makes the change in a session and opens a change request. If someone else saved the file first, your draft is kept. See [When someone saved first](/docs/brain#when-someone-saved-first). Editing skills needs the goal's admin role. To pin, archive or restore a skill, use the **Skills** section of **Brain › Learning**; see [Look after its skills](/docs/brain/learning#look-after-its-skills). ## Add a skill from the Marketplace **Brain › Marketplace** lists skills and other ready-made items from community and vendor registries. Select an item to read what is inside and what it requires. 1. Use the add button on the item and choose this goal. 2. The dialog lists any secret, connector or tool the item needs. Confirm. 3. Auto Lab starts an import session that adds the item's files and opens a change request. 4. Review and apply the change request. Until then, the item is not installed. The Marketplace is on by default. It can be turned off for a goal in [Feature flags](/docs/goals/settings#feature-flags). ## Tools **Brain › Tools** lists custom tools that are written as code and stored in the goal's repository. An agent can call them while it works in a session. Open a tool to read it, edit its text with **Edit source**, or select **Edit with agent**. To add a tool, select **Create with agent**: the agent writes and tests it, then opens a change request. The apps the agents use, such as Slack or a CRM, are connectors, not tools. See [Connectors](/docs/connect/connectors). --- # What's in the Brain Everything a goal's agents know, from agents and skills to memory, tools, connections and models, and how it changes. Canonical page: https://app.auto-lab.ai/docs/brain The **Brain** is everything your goal's agents know and use: their instructions, skills, memory, tools, connections, schedules, models and secrets. It also shows how that knowledge changes, who changed it and what is waiting for your approval. Open it from **Brain** in the goal's rail. ## The tabs The Brain opens on **Learning**. The other tabs follow in this order. | Tab | What it holds | |---|---| | **Learning** | What the goal learned from its own work, and the changes it proposes. See [Learning](/docs/brain/learning). | | **Agents** | The goal's agents, their instructions and what each one may use. See [Agents and skills](/docs/brain/agents-and-skills). | | **Skills** | Written procedures the agents open when a task calls for one. See [Skills](/docs/brain/agents-and-skills#skills). | | **Memory** | What the goal remembers, including the objective and the goal instructions. See [Memory and goal instructions](#memory-and-goal-instructions). | | **Tools** | Custom tools, written as code, that an agent can call while it works in a session. | | **Marketplace** | Ready-made skills and other items you can add to the goal. See [Marketplace](/docs/brain/agents-and-skills#add-a-skill-from-the-marketplace). | | **Connectors** | The apps and services the goal may use, and the channels that reach you. See [Connectors](/docs/connect/connectors) and [Channels](/docs/connect/channels). | | **Triggers** | What starts work from outside Chat, such as a timed trigger, a webhook or the **Daily digest**. See [Plans, schedules and triggers](/docs/goals/schedules). | | **Schedules** | The reminders, check-ups and routines the agent keeps for itself. Shown on goals that use Chat. | | **Review** | The Review Center: change requests and other work waiting for a decision. See [Approvals and autonomy](/docs/goals/approvals). | | **Models** | Which models the goal may use and which one it starts with. See [Models](/docs/brain/models). | | **Secrets** | API keys and other sensitive values the agents use. See [Secrets](/docs/connect/secrets). | | **Members ↗** | Opens the goal's access list in Organization settings. See [Roles and access](/docs/organization/access). | | **Settings** | The goal's settings, including **Autonomy**. See [Goal settings](/docs/goals/settings). | **Review** and **Marketplace** are on by default. You can turn either off for a goal in [Feature flags](/docs/goals/settings#feature-flags). As a goal member you see only **Learning**; see [Who can see and change the Brain](#who-can-see-and-change-the-brain). ## What each item tells you Cards and files across the Brain carry the same facts. | You see | What it means | |---|---| | **Updated 3h ago by you** | The last change that reached the goal's repository, and who made it: you, a teammate, Auto Lab, or a change request such as "change #12". | | **1 proposed change** | An open change request would change this item. Inside the file, a banner names the change with a **Review change** button. | | Tags | Memory files show their tags, or the folder they sit in when they have none. Use **Filter by tag** on the Memory tab. | | **Used in** | For a skill, memory file or tool: the saved sessions that opened, read or called it. | ## Change something You can edit an item yourself, or ask the agent to change it. A direct edit saves at once. A change made by the agent always goes through a change request that a person approves. ### Edit it yourself 1. Open **Brain › Memory**, **Brain › Tools** or **Brain › Skills** and select the item. For a skill, select the file in its file tree, usually `SKILL.md`. 2. Select **Edit source** and make your change. 3. Select **Save to project**. Auto Lab commits the file to the goal's repository and shows the commit. Saving does not start a session, run a tool or change a plan. The direct editor works on existing text files up to 256 KiB. It cannot create, rename or delete files, and binary and executable files stay read-only. Built-in skills are read-only too. To change an agent's instructions or access, open it in **Brain › Agents**. **Save** on the agent's page also commits the change to the goal's repository. ### Ask the agent to change it Use this when the change needs new files, several files or some judgement. 1. Select **Edit with agent** on a skill, memory file or tool. To add something new, select **Create with agent** on Memory or Tools, or **New** on Skills or Agents. 2. Auto Lab opens a new session with your request filled in. For **Edit with agent**, confirm with **Send** first. 3. The agent asks what you want, makes the change on a separate branch and opens a change request. 4. Review the change request, then apply or dismiss it. Nothing changes until someone applies it. See [Approvals and autonomy](/docs/goals/approvals) for how change requests are reviewed. ### When someone saved first If the file changed after you opened it, Auto Lab keeps your draft and asks you to compare. Select **Compare with latest** to see both versions. Then select **Keep draft with latest revision**, adjust your draft and save again, or select **Discard draft and reload**. ## Memory and goal instructions Memory is the goal's notebook. The agent reads it as it works and writes to it as it learns. The most important parts, such as a one-page profile, key facts and lessons, are in front of the agent on every turn. **Brain › Memory** shows these files and folders: | File or folder | Holds | |---|---| | `objective.md` | The goal: the outcome, how it is measured, the target and the constraints | | `instructions.md` | **Goal instructions**: standing rules a person approved | | `knowledge/` | Facts, procedures, preferences, decisions and lessons | | `entities/` | One file for each person and organization the goal deals with | | `workstreams/` | Work that is active, completed or set aside for someday | | `timeline/` | What happened each day, with daily, weekly and monthly summaries | | `comms/` | One file for each outside conversation | | `playbook.md` | The lessons every run reads, strongest first | | `profile.md` | A one-page summary the agent reads first, rebuilt each night | | `heartbeat.md` | The checklist the heartbeat looks at | | `MEMORY.md` | An index of what memory holds | Some files appear only once the goal has used them. ### Goal instructions `instructions.md` is a short list of standing instructions. The agent reads them on every turn, right after its built-in instructions, and follows them where the two differ. Keep each instruction to one line. The agent reads up to about 1,600 characters of the list. You can edit the file directly. [Learning](/docs/brain/learning) may propose one line to add, reword or remove, and that proposal always waits for a person. ### The objective `objective.md` is read-only in the Brain, because the goal card on the Overview keeps its own copy of the objective. Change it with **Edit goal** on the Overview. See [Overview, Needs you and Activity](/docs/goals/overview). ## Agents, skills, memory and tools are files Agents, skills, memory and tools are files in the goal's repository, under `.kortix/`. **Files** shows that folder as **System files**. The goal manifest, `kortix.yaml`, holds each agent's access rules. This is why every change to them has an author, a date and a history, and why a change can be reviewed before it lands or undone after. You never need to open the repository to use the Brain. Developers can read [The goal's repository](/docs/developers/repository). ## Who can see and change the Brain | Who | Can | |---|---| | Every member of the goal | Open **Learning** | | Goal admins (shown as **Project admin**) | Open every tab, see the change history, edit items, and use **Undo**, **Pin** and **Archive** on the Learning tab | Organization owners and admins are admins on every goal. A custom role can add any of these rights to other people. See [Roles and access](/docs/organization/access). --- # Learning How a goal learns from its own work, what it changes on its own, what waits for you, and how to undo it. Canonical page: https://app.auto-lab.ai/docs/brain/learning Your goal gets better at its work by looking back at it. After corrections, long tasks and quiet spells, and again each night, the agent reviews what happened and saves what it learned. You see all of it in **Brain › Learning**. Small changes that are easy to reverse, such as a note or a lesson, take effect at once and each has **Undo**. Changes to what a person wrote, or to the rules the agent follows, could change its behaviour in ways you did not ask for, so a person decides on those. This page describes goals that use Chat. For older goals that run in sessions, see [Older session goals](#older-session-goals). ## When the goal reviews its work A review runs in the background after the agent has replied. It reads the conversation since the last review. | When | What starts a review | |---|---| | You correct the agent | Right after that turn | | A long task finishes | A turn that used many tools | | A long conversation | Every 10 of your messages | | Something went wrong | A turn failed, stalled, ran out of steps or hit something in its way | | The agent worked on its own | A turn that ran with no person involved | | A conversation goes quiet | Checked hourly. The review runs once nobody has written for two hours | | Every night | Around 3:30 in the goal's time zone, if the day had any activity | Besides corrections and the nightly pass, a goal runs at most six reviews a day. Each review saves at most three things and proposes at most three. If you write while a review is running, it stops without saving anything and runs again after your turn. ## Choose how much it learns Set the learning level in **Settings › Autonomy**, under **Learning**. | Level | What happens | |---|---| | **Off** | Nothing is learned. Skills and memory still work. | | **Ask me first** | Every change waits for your approval in **Needs your decision**. | | **Learn on its own** | The default. Notes, preferences you stated, lessons and its own skills are saved at once, each with **Undo**. It asks before changing anything a person wrote. | The top of **Brain › Learning** shows the current level, for example "Learning on its own", with a link to **Autonomy settings**. Changing the level needs the goal's admin role. ## What it changes, and what it never changes At **Learn on its own**, these are saved at once, each with **Undo**: - A note about what happened, added to the goal's timeline, people, conversations or workstreams. It only adds; it never rewrites a note. - A preference you stated in the conversation, saved with your own words. - A lesson from something that went wrong, added to the playbook that every run reads. - A skill of its own, named `learned-…`, or an edit to one. First Auto Lab replays recent turns with the new skill. If anything gets worse, or the replay cannot run, the skill waits for you instead. These are always proposed as a change request, at every level: - Replacing or removing something already in memory - Knowledge the agent worked out, rather than heard from you - The objective - Edits to a skill a person wrote - One small edit to the [goal instructions](/docs/brain#goal-instructions): one line added, reworded or removed Learning never changes the agent's own instructions (its prompt), its tools or the goal manifest (`kortix.yaml`). Anything you undo or decline is remembered, and the agent does not save or propose it again. ## See what it learned In Chat, a line appears after a review, for example "Learned: Send invoices on Fridays" with **Undo**, "Learned 3 things" with **See all**, or "1 suggestion waiting for you" with **Review**. **Brain › Learning** shows these sections, top to bottom: | Section | What it shows | |---|---| | **Needs your decision** | Open change requests from learning. Each row names the proposed changes and, for a skill, the replay result, such as "Replay: no regressions". | | **Learned on its own** | What the agent saved without asking, newest first: why (its reason, or your own words), when, and what started the review. **Open** shows the file in the Brain. | | **Skills** | Every skill, with how often the agent opened it and when last. Learned skills come first. | | **Is it helping?** | Corrections per week, which should fall as it learns, and how much was undone or declined. | | **What changed** | Every edit to agents, skills, memory and tools that took effect, by day, with who made it. | | **Outcome trend** | The number the goal tracks over time, with accepted changes marked on it. | | **Reviews** | Each time the agent looked back at its work, and the result. | Further down you find **What got in the way** (the agent's own notes on what was missing or wrong), **Replay results**, **Lessons** and **Learned this week**. Anyone who can open the goal sees this tab. Some sections, such as **What changed** and **Lessons**, need the goal's admin role. ## Decide on a proposal ### Open it In **Needs your decision**, select **Review** on the row. ### Read the change Check what would change. For a skill, check the replay result. ### Decide Select **Apply changes** to accept it, or **Dismiss** to decline it. The same change requests also appear in **Needs you** on the Overview and in the Review Center. See [Approvals and autonomy](/docs/goals/approvals). ## Undo something it learned Select **Undo** in either place: - In Chat, on the "Learned: …" line. - In **Brain › Learning**, on the row under **Learned on its own**. Undo removes exactly what was added and records the removal in the goal's history. The row stays, marked **Undone**. If the file changed since, Undo cannot run safely and says "This changed since; edit it in Brain." Open the file and edit it yourself. Undo needs the goal's admin role. ## Look after its skills The **Skills** section helps you keep the agent's skills useful: - **Pin** a skill to keep it. Pinned skills are never retired. - **Archive** a skill to take it out of the list the agent chooses from. **Restore** brings it back. - A learned skill nobody opened for 14 days is marked **Stale**. After 30 days it is archived, and you can undo that like any other learned item. A skill a person wrote is only ever marked stale. To edit a skill, see [Agents and skills](/docs/brain/agents-and-skills#edit-a-skill). ## Older session goals Goals that run in sessions instead of Chat learn through a **Daily reflection**. Once a day it reviews recent finished sessions and proposes changes as change requests. Nothing applies on its own. - It is off by default. Turn it on with the **Daily reflection** switch in **Settings › Autonomy**. - It needs five completed sessions before you can turn it on. - While it is off and the goal qualifies, the Overview's **Needs you** shows a **Turn on daily learning** suggestion. On these goals, **Brain › Learning** shows the reflection's status at the top and lists each run under **Reviews**. Open a run to read its findings and **Accept** or **Reject** each one. --- # Models Which AI model a goal uses, how to change its default, which models its menus offer, and how to add your own provider key. Canonical page: https://app.auto-lab.ai/docs/brain/models Every reply in Chat and every session runs on an AI model. Auto Lab provides models to every goal, so a new goal works without any setup. In **Brain › Models** you choose the model the goal starts with, decide which models its menus offer, and add your own provider keys if you want more. ## What the page shows **Brain › Models** has its own row of tabs: | Tab | What it is for | |---|---| | **Providers** | Paste API keys for model providers | | **Models** | Turn models on or off in the goal's menus, and set defaults | | **Custom** | Connect a self-hosted or unlisted model service that works like OpenAI's API | | **Gateway** | Create a key so a tool outside Auto Lab can call models through this goal | | **Routing** | What happens when the default model cannot answer: a fallback model, per-model overrides and advanced settings | | **Costs** | Spend, requests, tokens and response times for the goal's model calls, with an optional spending cap | | **Logs** | The goal's recent model requests | The picker at the top right of the page sets the goal's default model. It appears for goal admins. If the goal's **LLM Gateway** feature flag is off, the page shows only **Providers** and **Custom**, with no default picker. ## Change the goal's default model Open **Brain › Models** and choose a model in the default picker at the top right of the page. Chat uses the new default from its next turn, and new sessions start with it. Chat has no model picker of its own, so the goal's default is how you change the model Chat uses. ## How the model is chosen Auto Lab uses the first model in this list that is set and that it can serve. For Chat: 1. The goal's default model. 2. The organization's default model. 3. Auto Lab's default. For a session: 1. A model picked in that session, or set on the trigger that started it. 2. The default model of the agent the session runs, set on the agent's page under **Model**. 3. The goal's default model. 4. The organization's default model. 5. Auto Lab's default. A default that stops working, for example because its provider key was removed, is skipped. The conversation carries on with the next model instead of failing. Some task agents, such as Research and Browser, run on a model Auto Lab picks for their job. To set the organization's default, open the **Models** tab, open the **⋯** menu on a model's row and choose **Make it my default everywhere**. It applies to every goal in the organization that has no default of its own. ## Choose which models the menus offer The **Models** tab lists every model the goal can use, with what it can do (reasoning, tools, images) and how much text it can read at once. Each model has a switch. - Out of the box, each model family offers only its latest model; older ones start switched off. - Turn a model on to offer it in the goal's menus, or off to hide it. - The goal's default model cannot be turned off. Pick a different default first. The switches decide what the menus offer. They do not stop a model that is already set somewhere, such as on a trigger, from running. ## Use your own provider key ### Find the provider Open **Brain › Models › Providers** and search for the provider, for example Google or OpenRouter. ### Paste the key Paste the API key into the provider's field. It saves when you click away. ### Check its models Open the **Models** tab. The provider's models are listed there, and the newest ones are on. A provider key belongs to the goal, not to you. Everyone who works on the goal uses the same key, and there are no personal provider keys. Auto Lab stores the key as one of the goal's secrets and never shows it again. To change it, paste a new key over it. To stop using it, select **Remove key**. A key matters for a provider Auto Lab does not already supply. Models that Auto Lab supplies run on its own connection, even if you add a key for the same provider. ## Pick a model for one session In a session, the model picker in the message box switches the model for that session only. Its **Manage models** button opens the **Providers**, **Models** and **Custom** tabs in a dialog, so you can add a key without leaving the session. Beside it, the **Thinking effort** control sets how much the model reasons before it answers. The choices depend on the model, and a model without levels shows no control. **Auto** lets the model decide. Chat has neither control. --- # Channels Talk with a goal's agent from Slack, Microsoft Teams, iMessage or email, link your chat account, and choose where its updates go. Canonical page: https://app.auto-lab.ai/docs/connect/channels A channel is a place outside Auto Lab where you talk with the goal's agent. You mention it in Slack, text it, or email it. Every channel feeds the goal's one Chat thread, and the agent answers where you asked. ## Available channels Set up channels in **Settings › Channels**. The same list is on the **Channels** tab of **Brain › Connectors**, and in setup under **Where should I reach you?**. | Channel | Available | What you need | |---|---|---| | Slack | On every goal | A Slack workspace where you can add apps | | Microsoft Teams | When switched on for the goal | A Teams admin of your Microsoft tenant to approve the Auto Lab app | | iMessage | When switched on for the goal | A dedicated line from Sendblue, and its API key id and secret | | Email | When switched on for the goal | An AgentMail inbox, which Auto Lab can create for you | | Here in Auto Lab | Always | Nothing. This is the goal's Chat | Teams, iMessage and email are off by default. Someone who manages the goal switches them on in **Settings › Feature flags**: **Microsoft Teams**, **iMessage** or **AgentMail Email**. ## Connect Slack ### Add the Slack app In **Settings › Channels**, select **Add to Slack**. Pick your Slack workspace and approve. You are linked as the first person automatically. ### Invite the bot to a channel In Slack, invite the Auto Lab bot to a channel: type `/invite` in the channel and pick the bot added in the previous step. ### Give it a task Mention the bot with what you need, or send it a direct message. In a thread under one of the bot's own messages, you can reply without mentioning it. If your deployment has no shared Slack app, the page shows **Set up Slack** instead. It walks you through creating your own Slack app, which takes about three minutes. If your Slack workspace is connected to more than one goal, the first mention in a channel asks which goal it belongs to. ### Slack commands Type these in Slack. Only you see the answers. | Command | What it does | |---|---| | `/autolab` | Shows which goal this channel is connected to, with buttons to change it or open it in Auto Lab | | `/autolab login` | Links your Slack account to your Auto Lab account | | `/autolab logout` | Removes that link | | `/autolab projects` | Lists the goals connected to this Slack workspace. Slack still calls a goal a project | | `/autolab switch` | Connects this channel to a different goal | | `/autolab help` | Lists every command | Slash commands do not run in Slack's assistant side panel. Type the same words as a plain message there, for example `/autolab login`. ## Connect Microsoft Teams 1. Switch on **Microsoft Teams** in **Settings › Feature flags**. 2. In **Settings › Channels**, select **Connect** on the Microsoft Teams row. A Teams admin of your Microsoft tenant signs in and grants consent. This adds the Auto Lab app to your organization's Teams apps, or sends it to your admin for review. 3. Select **Add to Teams** and add Auto Lab to a chat or a team. 4. Mention Auto Lab with a task. Send `/login` to link your account, and `/help` for the other commands. If your deployment has no shared Teams bot, the page offers **Use your own Azure bot instead of the managed Auto Lab bot**. ## Connect iMessage 1. Switch on **iMessage** in **Settings › Feature flags**. 2. Get a dedicated line from Sendblue, with its API key id and secret. 3. In **Settings › Channels**, select **Connect** on the iMessage row. Choose **Sendblue** and enter the **Line** in international format, such as `+15551234567`, then the **Sendblue API key id** and **Sendblue API secret**. 4. Select **Generate** next to **Webhook secret**. Paste the **Webhook URL** from the form, and the same secret, into Sendblue's webhook settings. Then select **Connect iMessage**. Teammates text the line. The first text from a number that is not linked gets a sign-in link back. A number that texts `STOP` gets no more messages until it texts `START`. ## Connect email 1. Switch on **AgentMail Email** in **Settings › Feature flags**. 2. In **Settings › Channels**, select **Connect Email**. Create a managed inbox with an address prefix, or attach an AgentMail inbox you already have. 3. Optionally, turn on **Restrict who can start sessions** and list the addresses, domains or pattern allowed to write in. Mail from the sign-in address of a goal admin runs as that person. Mail from anyone else reaches Chat as outside content. The agent answers it in Auto Lab only, with limited tools, and Chat marks it as a message from outside. ## Link your chat account The agent acts as the person who wrote to it, so each person links their chat account to Auto Lab once. The first time you write from a channel, the agent asks you to link. | Channel | How to link | |---|---| | Slack | `/autolab login`, or **Connect or create account** on the prompt | | Teams | Send `/login` to Auto Lab | | iMessage | Text the line and open the sign-in link it sends back | | Email | Nothing to link. Your sign-in address is matched | Open the link and sign in to Auto Lab. If you link within about ten minutes, the message you sent first then runs. If your account cannot work on this goal yet, Slack and Teams offer **Request access**, and a goal admin approves it under **Asked to join** in **Settings › Access**. A Slack, Teams or iMessage message runs only when its sender is linked to an Auto Lab account with the admin role on the goal (shown as **Project admin**). To see or remove your links, open **Personal settings › Chat identities** and select **Unlink**. Unlinking does not change your access to any goal. ## How replies work - Every message from a linked person lands in the goal's Chat, next to messages from the web. - The answer goes back where the question came from: the same Slack thread, the same iMessage chat, a reply to the email. - In Slack, the bot marks your message while it works and adds a check mark when it has answered. - In Slack, iMessage and email, questions arrive as a numbered list. Reply with the number, or type your answer. Teams shows a question card. - When a message the agent wants to send needs your approval, Slack and iMessage show you the draft. Reply `go` to send it or `no` to cancel. - On long tasks, Slack and iMessage get a short progress line now and then. - If a reply cannot be delivered, Chat shows **Delivery to {platform} failed**. ## Where scheduled updates go The channel you pick under **Where should I reach you?** during setup gets the goal's routine and check-up output. When you launch, Auto Lab also turns on escalation to that channel, so items waiting for you reach you there. **Here in Auto Lab** keeps everything in Chat and on the Overview. Teams gets escalations, but routine output stays in Chat for now. Two more deliveries live in **Brain › Triggers**: - **Daily digest** sends one summary a day, at a time you set in UTC, to up to four linked channels or your verified email. Quiet days send nothing. - **Escalate what needs you** sends a waiting question, approval, change request or plan after a delay you choose, outside quiet hours. Anything you answer in the app within the delay is never sent. See [Plans, schedules and triggers](/docs/goals/schedules). ## What does not work - Telegram and other chat apps are not supported channels. - The bot only hears Slack channels it has been invited to. - A Teams chat cannot receive scheduled output yet. - `/autolab agent`, `/autolab model`, `/autolab policy`, `/autolab sessions` and the **Channel bindings** table (**Agent**, **Model**, **Join policy**) only matter for older goals that run as sessions. On a goal with one Chat thread, every message goes to that thread. --- # Connectors Connect apps, MCP servers and APIs to a goal, choose who connects, and decide what each tool may do. Canonical page: https://app.auto-lab.ai/docs/connect/connectors A connector lets the goal's agent work in an outside app or service: read a Gmail inbox, update a CRM, call your own API. You connect it once, and the agent uses its tools as it works. Auto Lab keeps the account's credentials and makes each call on the agent's behalf. ## Where connectors live Open **Brain › Connectors**. The same page is at **Settings › Connectors**. It has four tabs. | Tab | What it shows | |---|---| | **Discovery** | The app catalogue, grouped by category | | **All** | The same catalogue as one list | | **Connected** | The connectors this goal already has | | **Channels** | Slack, Teams, iMessage and email. See [Channels](/docs/connect/channels) | Adding or changing a connector needs permission to manage the goal's connectors. Without it the page is read-only. If your deployment has no app catalogue, **Discovery** and **All** do not appear, and an empty **Connected** tab says "Connector discovery isn't set up on this deployment". You can still add a custom connector and connect channels. ## Connect an app from the catalogue ### Pick the app In **Brain › Connectors › Discovery**, search for the app or open a category, then select the app. ### Choose who connects Under **Authorization owner**, choose **Project** so everyone in the goal shares one connection, or **User** so each person connects their own account. This choice is fixed once the connector exists. See [Shared or personal connections](#shared-or-personal-connections). ### Add the connector Select **Add connector**. Auto Lab adds it to the goal manifest. ### Sign in to the app For a shared connection, select **Connect now**. A window opens on the app's own sign-in page. Approve access there. For a personal connection, each person connects their own account in **Personal settings › Connectors**. ## Connect during setup or from Chat You rarely need to open the Connectors page first. - **During setup.** The **Works with** part of the goal brief lists the tools you named. A catalogue app shows **Connect**, a public website shows **Ready**, and a site behind a login shows **Sign in**. Apps connected here are shared with the goal. While you set up, the agent only reads from connected apps. Nothing is written before you launch. - **In Chat.** When the agent needs an app that is not connected, it posts a **Connect {app}** card. **Connect** opens the connection page in a new tab. Once the app is connected, the thread carries on with what you asked. - **Without permission.** If you cannot manage connectors, the setup card says **Ask an admin to connect {app}**. When the goal already has that connector, **Copy link** gives you a connect link to send them. A connect link opens without signing in to Auto Lab, so the person who owns the account can use it. Anyone who has the link can connect an account to the goal, so share it like a password. It lasts seven days by default. ## Connect an MCP server or your own API Select **New › Add a custom connector**. Choose the **Provider**: **OpenAPI**, **Postman**, **GraphQL**, **MCP** or **HTTP**. Give the address of the spec, the server or the API. Under **Auth**, **Auto-detect** reads the sign-in method from the source. You can also pick one yourself, such as **Bearer**, **API key** or **OAuth 2.0**. After you add the connector, open it and select **Add credential**. - **An API key or token.** Use the **Static credential** tab and paste the value. Auto Lab encrypts it and attaches it to every call. - **An MCP server that uses OAuth.** Use the **OAuth 2.0** tab. Auto Lab reads the server's sign-in settings first. If it shows **One-click OAuth 2.1 available**, select the connect button and approve at the provider. There is no client ID to create. If it says **This server needs a pre-registered OAuth app**, create an app at the provider, register the redirect address below, and paste its client ID. ```text https://api.auto-lab.ai/v1/connectors/oauth2/callback ``` **New › Create in chat** is the other route: an agent sets the connector up for you and opens a change request to review. ## Shared or personal connections | | Shared (**Project**) | Personal (**User**) | |---|---|---| | Whose account | One account for the whole goal | Each person's own account | | Who connects it | Someone who manages connectors | Each person, for themselves | | Good for | A team inbox, a shared CRM, a company data source | Your own calendar or mailbox, where the agent should act as you | People connect their personal accounts in **Personal settings › Connectors**. Pick the organization and the goal, then use **Connect account** under **Your connections**. You can also select **Add my own** on the connector's **Accounts** tab. Each person's credentials stay with their own Auto Lab account. A connect link from Chat only works for shared connections. ## Choose which agents can use a connector An agent can only call a connector its agent settings allow. Open **Brain › Agents**, select the agent, and set **Connectors** to **All**, **Pick** or **None**. With **Pick**, you can also mark a connector **Required**. A session for that agent then does not start until the connector has a usable connection. ## Set what each tool may do Open the connector and select the **Tools** tab. Every tool has four settings. | Setting | What happens | |---|---| | **Default** | The tool follows the goal's delegation setting and your **Global rules** | | **Allow** | The tool runs without asking | | **Ask** | The call waits for your approval | | **Block** | The tool never runs | **Set all** changes a whole group at once. Under **Advanced**, **Ask before every use** makes every tool of this connector ask, reads included. Use it for mail, files or anything where reading is itself sensitive. **Pattern rules** cover many tools with one pattern, such as `delete_*`. **Global rules**, next to the tabs on the Connectors page, apply to every connector and are checked first. A tool decided by a global rule is locked on the **Tools** tab. The **Delegation** dial on the Overview sets what **Default** means. Setup asks the same question under **On its own**. | Delegation | Tools left on **Default** | |---|---| | **Ask first** (setup: **Asks before acting**) | Every connector call waits for approval, reads included. This overrides the tool settings | | **Within policy** (setup: **Acts within your rules**) | Your rules decide. With no rule, reads run and writes and deletes wait for approval | | **Act freely** (setup: **Acts on its own**) | Reads and writes run. Connectors set to **Ask before every use** still ask | A call that waits appears as an approval card in Chat and on the Overview under **Needs you**. See [Approvals and autonomy](/docs/goals/approvals). ## When a call is refused When the agent cannot make a call, it tells you in one line and offers another way. The usual reasons: | Reason | What to do | |---|---| | The agent's settings do not include this connector | Add it under **Brain › Agents** | | No account is connected | Connect one, or ask someone who can | | A tool setting or a global rule blocks the tool | Change the rule if the agent should use it | | You denied the approval | Nothing. The call did not run | ## Where credentials live A connector's credentials stay on Auto Lab's servers, encrypted. When the agent calls a tool, Auto Lab attaches the credential and makes the call. The credential never enters the agent's machine, and the agent never sees it. Keys the agent's own code needs work differently. See [Secrets](/docs/connect/secrets). ## Remove a connector Open the connector, select the **Settings** tab, then **Remove connector**. Its saved connections, agent assignments and tool rules are deleted too, and this cannot be undone. To switch a connector between shared and personal, remove it and add it again. --- # Connecting tools How a goal reaches the apps, people, websites and keys it works with, and where you set each one up. Canonical page: https://app.auto-lab.ai/docs/connect A goal does its work in the outside world. It reads your inbox, updates a spreadsheet, asks you a question in Slack, or signs in to a supplier portal. This section covers the four ways you give a goal that reach, and where each one lives in Auto Lab. ## Four kinds of connection | What | What it gives the goal | Where you set it up | |---|---|---| | Connectors | Apps and data the agent can use: Gmail, a CRM, an MCP server, your own API | **Brain › Connectors** (also **Settings › Connectors**). Your own accounts: **Personal settings › Connectors** | | Channels | Places the agent talks with people: Slack, Microsoft Teams, iMessage, email | **Settings › Channels** (also the **Channels** tab of **Brain › Connectors**) | | Website logins and secure links | Sign-ins, documents and numbers handed over on a private page instead of in chat | The agent sends the link. Saved logins are listed under **Settings › Secrets** | | Secrets | Keys and values the agent's code needs, such as an API key | **Settings › Secrets** (also **Brain › Secrets**). Your own values: **Personal settings › Secrets** | Connectors and channels are the two you meet first. During setup, the **Works with** part of the goal brief lists the apps the goal needs, and **Where should I reach you?** picks its channel. See [Set up and launch a goal](/docs/goals/setup). ## How the pieces fit - A connector is something the agent works in. A channel is where the agent talks with people. Messages from every channel land in the goal's one Chat thread, so the conversation stays in one place. - Credentials stay with Auto Lab. Connector accounts, website logins and secure-link values are stored encrypted, and the agent uses them without seeing them in chat. - A secret is different. A secret set to **Environment variable** is readable by any command the agent runs. [Secrets](/docs/connect/secrets) explains the choice. - What the agent may do with a connected app follows your rules and the goal's autonomy setting. A write can wait for your approval. See [Approvals and autonomy](/docs/goals/approvals). ## Start work without a message A goal can also start work on its own, on a clock or when an event or a webhook arrives. Set these up in **Brain › Schedules** and **Brain › Triggers**. See [Plans, schedules and triggers](/docs/goals/schedules). ## Pages in this section - [Connectors](/docs/connect/connectors): Connect apps, MCP servers and APIs, and decide what each tool may do. - [Channels](/docs/connect/channels): Reach the agent from Slack, Teams, iMessage or email, and get its updates there. - [Website logins and secure links](/docs/connect/website-logins): Hand over a sign-in, a document or a number without typing it into chat. - [Secrets](/docs/connect/secrets): Store keys and values, choose who can read them, and check that they stay hidden. --- # Secrets Store the keys and values a goal's agent needs, decide whether its code can read each one, and check that a hidden value stays hidden. Canonical page: https://app.auto-lab.ai/docs/connect/secrets A secret is a value the agent's code needs but that must not live in the goal's repository: an API key, a token, a database connection string. Auto Lab encrypts each value with a key unique to the goal and delivers it only to the agents you allow. ## When to use a secret | You want the agent to | Use | |---|---| | Work in an app such as Gmail or a CRM | A [connector](/docs/connect/connectors). Its credentials never reach the agent's machine | | Sign in to a website | A [website login](/docs/connect/website-logins) | | Run code that calls an API or a database with a key | A secret | To use your own model provider key, see [Models](/docs/brain/models). ## Goal secrets and personal secrets - **Goal secrets** are shared by the goal. Manage them in **Settings › Secrets**, which is also **Brain › Secrets**. Changing them needs permission to manage the goal's secrets. - **Personal secrets** are your own value for a key, used instead of the shared value in sessions you start. Manage them in **Personal settings › Secrets**. See [Use your own value](#use-your-own-value). ## Add a secret ### Open the dialog In **Settings › Secrets**, select **New › Set up manually**. **New › Create in chat** asks an agent to set it up for you instead. ### Name it and paste the value Enter the key the code reads, such as `STRIPE_API_KEY`, and the value. Leave **Identifier** blank unless you keep a second value under the same key, such as a backup key. Names starting with `KORTIX_` are reserved. ### Choose who can read it Answer **Can your code read this value?** with one of the options below, then select **Save**. ## Choose who can read the value | Option | What the agent's machine holds | Use it for | |---|---|---| | **Environment variable** (the default) | The real value | A key the code signs requests with, a protocol that is not HTTPS, an API that only accepts Basic auth | | **Enforce at the network** | A stand-in value. Auto Lab swaps in the real value on the way out, only for hosts you approve | An HTTPS API that takes the key in a header, a query parameter or the request body | | **Disabled** | Nothing | A value you keep on file without delivering it | > **Environment variables are readable** > > A value on **Environment variable** is readable by every command the agent runs. The agent can read it, print it or send it anywhere, and Auto Lab cannot hide or track it. Choose **Enforce at the network** for any key that only needs to reach an HTTPS API. **Enforce at the network** is still marked experimental. It is on by default, and turning off **Network-Enforced Secrets** in **Settings › Feature flags** hides it. A secret that already uses it keeps working. Three other labels can appear in the **Access** column: **LLM gateway**, **Connector** and **Git**. Auto Lab assigns them when you connect a model provider, bind a connector or connect a repository, and you cannot change them here. **What each Access value means**, at the top of the page, explains every label. If you paste something that looks like a signing key, such as an AWS access key or a PEM or SSH key, the page keeps it on **Environment variable** and says why. Code has to hold a signing key to compute with it. ### Approved hosts With **Enforce at the network**, list every host the key is for under **Hosts**, one per line. Use exact HTTPS host names. Wildcards, paths and ports are refused, and `api.example.com` does not cover `uploads.api.example.com`. A request to any other host carries only the stand-in, which is worthless on its own. Code written for the real key works unchanged with the stand-in. The one exception is HTTP Basic auth, which encodes the value on the way out, so Auto Lab can no longer recognise it and swap it. For an API that accepts only Basic auth, keep the secret on **Environment variable**. Calls to an approved host go through Auto Lab, which changes a few things: - Streaming does not work, so server-sent events and websockets fail. - A request body can be up to 1 MiB, a response up to 5 MiB, and a call up to 30 seconds, with at most 3 redirects. - A program that ignores the machine's proxy settings calls the host directly, and sends only the stand-in. ### Check that the value stays hidden Two checks tell you the swap works. Run them inside the agent's machine, for example by asking the agent in a session to run them. The example uses `postman-echo.com`, which has one endpoint of each kind. Add it to the secret's **Hosts** for the test, and remove it afterwards. ```bash # 1. Reachability: an endpoint that does not echo headers back curl -s -o /dev/null -w '%{http_code}\n' https://postman-echo.com/status/200 # expected: 200 # 2. Substitution: an endpoint that echoes headers back curl -sS -H "authorization: Bearer $STRIPE_API_KEY" https://postman-echo.com/get # expected: 200, with "Bearer [REDACTED]" in the echoed headers ``` Look at check 1 before check 2. If the host cannot be reached, check 2 tells you nothing about the secret. | Check 2 result | What it means | |---|---| | `200`, and the header shows `[REDACTED]` | It works. The real value went out, and Auto Lab hid it in the echo | | `200`, and the header shows the stand-in | The swap did not happen. Check the host list and the agent's grant | | `401` from a real API | The swap did not happen. Check the same two things | | An empty reply or a connection error | Something else is wrong: the host, the network or the command | Then confirm that the machine holds only the stand-in: ```bash env | grep '^STRIPE_API_KEY=' # expected: the stand-in value, not your key ``` ## Give an agent a secret A secret arrives in the machine where the agent runs commands: a session, or the machine a task agent works in. Which agents receive which secrets is set per agent: open **Brain › Agents**, select the agent, and set **Secrets** to **All**, **Pick** or **None**. - A goal with no agent list gives every agent every **Environment variable** secret. - An **Enforce at the network** secret reaches an agent only when that agent names it with **Pick**. **All** does not count. Until then the **Access** column shows **No agent grant**, and editing the secret offers to grant it to an agent. > **The first grant changes every agent** > > When the goal has no agent list yet, granting a secret to one agent writes the first list. From then on, an agent that is not listed receives no goal secrets at all, including environment secrets that worked before. Auto Lab asks you to confirm first. List every agent that needs secrets. ## Change or remove a secret - **Replace the value.** In the row's menu, select **Edit secret**, paste the new value and select **Save**. Running sessions receive it shortly. This is best effort, so a session that misses it picks the value up when it restarts. An **Enforce at the network** secret needs nothing more: the next request uses the new value. - **Remove it.** Select **Delete shared value**, then **Delete**. The value cannot be recovered. A session already running may keep the old value until it restarts. - **Required secrets.** The goal manifest can mark a key as required. An unset required key shows a warning. Sessions still start, but the agent is missing that value. ## Use your own value In **Personal settings › Secrets**, choose the organization and the goal, then select **Add personal secret**. Enter the **Environment key** and the **Secret value**. - Your value replaces the shared one in sessions you start. Other members never see it. - **Pause my override** goes back to the shared value until you select **Resume my override**. **Remove my value** deletes it. - The goal's delivery rules and agent grants still apply. A key that exists only as your personal secret reaches your sessions as an environment variable. - Model provider keys cannot be personal. They are set up under the goal's models. ## Hand over a value without seeing it Someone else can enter a key through a secret link, so the value never passes through you or through Chat. See [Hand over a key without seeing it](/docs/connect/website-logins#hand-over-a-key-without-seeing-it). --- # Website logins and secure links How the agent asks for a website login, a document or a key through a private link, so nothing sensitive is typed into chat. Canonical page: https://app.auto-lab.ai/docs/connect/website-logins Some work happens on websites behind a sign-in, such as a supplier portal or a booking site. Some needs a passport number or an API key. The agent never asks you to type these into Chat. It sends a private link instead. You enter the value on that page, and Auto Lab stores it encrypted for the goal. ## Four kinds of link | Link | The page says | What you hand over | Who uses it | |---|---|---|---| | Login link | **Sign your agent in to a website** | A website sign-in and how its second step works | The browser task agent, which signs in for you | | Secure link | **Hand over a document securely** | A document or a number, such as an ID, a passport or a card | A task that fills a form or reads the record by name | | Secret link | **Add a project secret** | A key or another value | A connector, or the agent's code | | Connect link | **Connect an app** | Your approval on the app's own sign-in page | A connector. See [Connectors](/docs/connect/connectors) | You can open these links without an Auto Lab account. The link itself is the key, so send it only to the person who holds the login or the document. In Auto Lab's Chat, login, secret and connect links show as a card you can open in place. In Slack, Teams, iMessage or email they arrive as a plain link. ## Sign the agent in to a website 1. **The agent reaches a sign-in page.** A browser task that finds no saved login for a site stops there. The agent then posts a login link in the thread, or in the channel you asked from. 2. **You open the link.** The page shows the site's address, whether it is a secure `https` site, which goal asked, and when the link expires. 3. **You enter the login.** Fill in the email, username or phone number, the **Password**, and the **Second factor**. Add a **Note for the agent** if the page needs something extra, such as a company code. Select **Save login**. 4. **The agent carries on.** Chat shows **Login for {host} saved**, and the agent returns to the task. The browser task types the login into the site from the encrypted store. The password never appears in Chat, and the agent does not read it. 5. **The site stays signed in.** After a sign-in, Auto Lab keeps the site's browser session until its cookies expire, for up to 30 days. The next visit starts signed in, with no new link. A login link lasts seven days by default. An expired link says **This link has expired**. Ask the agent for a new one. During setup, **Sign in** on a **Works with** card asks the agent to send a login link for that site. ### Second factors | **Second factor** | What happens | |---|---| | **None** | The password alone signs in | | **Authenticator app (TOTP)** | Paste the setup key under **TOTP secret** and the agent makes the code itself. Without it, the agent asks you for the code each time | | **SMS code** or **Email code** | The agent asks you for the code in the thread and enters it once | | **Push approval** | You approve on your phone. The agent tells you when it is waiting | When a site asks for a one-time code, the agent asks in the thread with the question **One-time code for {site}**. Reply with the code. It is used once and then removed from the log, and Chat shows **One-time code removed from the log**. ### When a site pushes back If a site shows a CAPTCHA or a device check, the agent does not try to get past it. It tells you what the page showed, gives you the quickest way to do the step yourself, and can try once more later. Before it places an order on a site, it shows you what it is about to buy and waits for you to answer **Place order**. ## Approve each use of a saved login To be asked before a saved login is used, turn on **Approve website login use** in **Settings › Autonomy**. The first use of a login in each session then waits for your approval. The approval covers only that login in that session. See [Approvals and autonomy](/docs/goals/approvals). ## See, request and revoke saved logins Saved logins are listed under **Website logins** in **Settings › Secrets**, which is also **Brain › Secrets**. Each row shows the site, its label, the masked sign-in name, the owner, the second factor, when it was last used, and whether a **Saved browser state** exists. Passwords are never shown. | Owner | Who can sign in with it | |---|---| | **Project** | Any session in this goal | | **Personal** | Only sessions started by the person who submitted the link | - **Request a login** makes a link before the agent asks. Fill in **Site**, an optional **Label**, **Sign-in uses** and **Owner**, then select **Create link** and send the **Link to send** to whoever has the login. - **Revoke** stops the agent from signing in to that site with the login, and deletes the saved browser state. To hand it over again, send a new link. Requesting and revoking need permission to manage the goal's secrets. ## Hand over a document or a number The agent never asks for an ID, a passport or a card in Chat. It sends a secure link instead. The page asks for the fields the agent named: text, numbers, dates, or a file (an image or a PDF). Select **Save securely**. - The link works once, and lasts 24 hours by default. A used link says **This link was already used**. Ask the agent for a fresh one if something needs correcting. - The values are stored encrypted as one named record for the goal. The page says whether everyone on the goal can use it or only sessions you run. - A browser task fills a form from the record by name. The agent reads it only when a task needs it and never shows it in Chat. ## Hand over a key without seeing it A secret link lets someone enter a key or another value that you never see. The link can only set the values it names. It cannot read any existing secret. It lasts seven days by default and at most 30 days. A secret link comes from `kortix secrets request` (see [CLI](/docs/developers/cli)) or from an agent working in a session. By default, the value is kept for connectors and stays on Auto Lab's servers. A link made for the agent's machine stores it as an environment variable, which the agent's commands can read. See [Secrets](/docs/connect/secrets). --- # API and sign-in Call the Auto Lab API with a personal access key or a service account, and let your own app sign people in with their Auto Lab account. Canonical page: https://app.auto-lab.ai/docs/developers/api The Auto Lab web app and CLI talk to a REST API. You can call the same API from a script, a CI job or your own backend. You can also let your own app sign people in with their Auto Lab account and act for them. ## Base URL and keys The API's base URL is `https://api.auto-lab.ai/v1`. Send a key in the `Authorization` header: ```text Authorization: Bearer ``` The API uses its own names in routes and fields. It calls a goal a **project** and an organization an **account**. | Key | Starts with | Acts as | Where it comes from | | --- | --- | --- | --- | | Personal access key | `kortix_pat_` | You | **Personal settings › Personal access keys** | | Service account token | `kortix_sa_` | The service account itself | **Organization settings › API keys** | | OAuth access token | `kortix_oat_` | The person who signed in to your app | [Sign in with Auto Lab](#sign-in-with-auto-lab) | ## Personal access key A personal access key acts as you. It can do exactly what you can do in Auto Lab, and nothing more. If your role changes, the key's reach changes with it. If you leave the organization, the key stops working. 1. Open **Personal settings › Personal access keys** and select **New key**. 2. Enter a **Name** that says where you will use the key, such as "Nightly report job". 3. Pick a **Scope**: the whole organization, or one goal. A key for one goal cannot reach any other goal. 4. Pick when it **Expires**. Your organization can require every key to expire. 5. Select **Create key**, then copy the key. Auto Lab shows it only once. To stop a key, open its row menu and select **Revoke key**. It stops working at once. The CLI's `kortix login` creates a key of this kind for you (see [CLI](/docs/developers/cli#sign-in)). ## Service account A service account is an identity of its own, for automation that should keep working after the person who set it up leaves. Organization owners and admins create one in **Organization settings › API keys**. Its token is shown once. A new service account has no access at all, and every call it makes returns `403` until you give it a role. Grant it one on each goal it needs, for example with the CLI: ```sh kortix access grant --service-account --role member --project ``` ## Make a request Check who a key belongs to and which organizations it can see: ```sh curl -s https://api.auto-lab.ai/v1/accounts/me \ -H "Authorization: Bearer $AUTOLAB_API_KEY" ``` The answer holds your `user_id`, your `email` and an `accounts` list, one entry per organization with its `account_id`, `slug`, `name` and your `role`. List the goals you can read in one organization: ```sh curl -s "https://api.auto-lab.ai/v1/projects?account_id=$ACCOUNT_ID" \ -H "Authorization: Bearer $AUTOLAB_API_KEY" ``` The answer is a list of goals, each with its `project_id`, `name`, `default_branch` and `dashboard_url`. Without `account_id`, the API uses your default organization. Some routes you may want next: | Route | What it returns | | --- | --- | | `GET /v1/projects/{projectId}` | One goal. | | `GET /v1/projects/{projectId}/outcome` | The goal's objective, what it tracks, and its delegation level. | | `GET /v1/projects/{projectId}/tasks` | The goal's task board. | | `GET /v1/projects/{projectId}/change-requests` | The goal's change requests. | A `401` means the key is missing, wrong, expired or revoked. A `403` means the key works but its owner is not allowed to do that. ## API reference The full reference is at [api.auto-lab.ai/v1/docs](https://api.auto-lab.ai/v1/docs). The raw OpenAPI document is at `https://api.auto-lab.ai/v1/openapi.json`. Both are generated from the API's code, so they use the API's names and list some routes Auto Lab does not use. Auto Lab does not publish an SDK; call the API directly. ## Sign in with Auto Lab Your own app, such as an internal dashboard or a partner portal, can let people sign in with their Auto Lab account. The app then acts as the person who signed in, with that person's permissions and no more. Auto Lab is a standard OAuth 2.1 authorization server: authorization code flow with PKCE. ### Register your app Organization owners and admins register apps in **Organization settings › API keys**, under **OAuth apps**. Select **Register app** and fill in: | Field | What to enter | | --- | --- | | **Name** | The name people see on the consent page. | | **Description** | Optional. | | **Type** | **Confidential** for a server-side app, which gets a client secret. **Public** for a browser or native app, which has no secret and relies on PKCE. You cannot change the type later. | | **Redirect URIs** | One per line, up to 20. HTTPS, except on a loopback address such as `localhost`. No `#fragment`. Auto Lab matches them character for character. | | **Scopes** | The most the app may ask for. Each sign-in can ask for fewer. | Copy the client ID and, for a confidential app, the secret. The secret is shown only once. If you lose it, use **Rotate secret** from the app's row menu. | Scope | What the app gets | | --- | --- | | `profile` | Who the person is: their ID, email and organization. | | `email` | Their email address. | | `kortix` | Acting as the person on the whole API, with their permissions. Without it, the token only identifies them. | The `mcp:read` and `mcp:write` scopes belong to the [Auto Lab MCP server](/docs/developers/mcp) and work only there. ### Endpoints | Endpoint | Address | | --- | --- | | Discovery | `https://api.auto-lab.ai/.well-known/oauth-authorization-server` | | Authorize | `https://api.auto-lab.ai/v1/oauth/authorize` | | Token | `https://api.auto-lab.ai/v1/oauth/token` | | Revoke | `https://api.auto-lab.ai/v1/oauth/revoke` | | User info | `https://api.auto-lab.ai/v1/oauth/userinfo` | The discovery document follows RFC 8414. It is also served at `/v1/oauth/.well-known/oauth-authorization-server`. Auto Lab does not offer OpenID Connect discovery or ID tokens; read the person's identity from the user info endpoint. ### The sign-in flow ### Send the person to Auto Lab Redirect the browser to the authorize endpoint with `response_type=code`, your `client_id`, one of your `redirect_uri` values, the `scope` you need, a random `state`, and a PKCE `code_challenge` with `code_challenge_method=S256`. ```text https://api.auto-lab.ai/v1/oauth/authorize?response_type=code&client_id=&redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fcallback&scope=profile%20kortix&state=&code_challenge=&code_challenge_method=S256 ``` ### The person allows your app The person signs in to Auto Lab and sees a consent page that names your app and what it asks for, with **Allow** and **Deny**. Auto Lab remembers an approval, so a later sign-in that asks for the same scopes goes straight back to your app. Auto Lab then redirects to your `redirect_uri` with `code` and `state`, or with `error=access_denied`. ### Exchange the code Within five minutes, post the code to the token endpoint as a form. A confidential app sends its `client_secret`. A public app must not send one. ```sh curl -s https://api.auto-lab.ai/v1/oauth/token \ -d grant_type=authorization_code \ -d code="$CODE" \ -d redirect_uri=https://app.example.com/auth/callback \ -d code_verifier="$CODE_VERIFIER" \ -d client_id="$CLIENT_ID" \ -d client_secret="$CLIENT_SECRET" ``` The answer holds an `access_token` (starting `kortix_oat_`), a `refresh_token` (starting `kortix_ort_`), `token_type` `Bearer`, `expires_in` of 3600 seconds, and the granted `scope`. ### Call the API as the person Send the access token as a bearer token. With the `kortix` scope it works on every route, exactly like that person's own personal access key. `GET /v1/oauth/userinfo` returns their `sub`, `user_id`, `account_id` and `email`, and needs the `profile` or `email` scope. ### Refresh and sign out Access tokens last one hour. To get a new one, post `grant_type=refresh_token`, the `refresh_token` and your client credentials to the token endpoint. Each refresh token works once and lasts 30 days. The answer carries a new pair, and the old access token stops working. To sign someone out, post the `token` and your client credentials to the revoke endpoint. Revoking either token of a pair revokes both. The token endpoint accepts 20 requests a minute per app. ### Manage the app Each app's row menu in **Organization settings › API keys** has: - **Edit app**, to change its details. Changes apply from the next sign-in, and tokens already issued keep working until they expire. Switch **Active** off here to stop new sign-ins without deleting the app. - **Rotate secret**, to replace a lost or leaked secret. - **Delete app**, to remove it and revoke every token it was given. --- # CLI Install the Auto Lab command line, sign in, and work with your goals, sessions and change requests from a terminal. Canonical page: https://app.auto-lab.ai/docs/developers/cli The Auto Lab CLI lets you work on your goals from a terminal. You can clone a goal's repository, ship changes, review change requests, set secrets and call connectors. The command is `kortix`, and the goal's own agents use the same command inside their sandboxes. ## Install ```sh curl -fsSL https://app.auto-lab.ai/install | bash ``` The installer runs on macOS and Linux, on x64 and arm64 machines. Windows is not supported. It saves the program in `~/.kortix` and links it onto your `PATH`, in `/usr/local/bin` or `~/.local/bin`. The [download page](https://app.auto-lab.ai/download) shows whether a CLI release is published and which version it is. Until a release exists, the install command does not work. | Command | What it does | | --- | --- | | `kortix version` | Print the installed version. | | `kortix update` | Install the latest release. | | `kortix uninstall` | Remove the program and your saved sign-in. | ## Sign in ```sh kortix login ``` 1. Your browser opens **Sign in to the Auto Lab CLI** at `app.auto-lab.ai/cli/authorize`. Sign in to Auto Lab first if you are asked to. 2. Check the email and device shown, then select **Authorize**. 3. Back in the terminal, pick your active organization if you belong to more than one, then pick a default goal. Authorizing creates a personal access key named after your device, such as "CLI · my-laptop". The key acts as you, with exactly your permissions. It is listed in **Personal settings › Personal access keys**, where you can revoke it. The CLI stores it in `~/.config/kortix/config.json`, readable only by you. On a server or in CI, where no browser can open, [create a personal access key](/docs/developers/api#personal-access-key) and pass it in: ```sh kortix login --token "$AUTOLAB_API_KEY" --account "$ACCOUNT_ID" --no-project ``` `kortix whoami` shows who you are signed in as and which organization is active. `kortix logout` forgets the key on this machine. It does not revoke the key, so revoke it in Personal settings when you no longer need it. ## Names the CLI uses The CLI uses the API's names. It calls a goal a **project** and an organization an **account**. So `kortix projects ls` lists your goals, and `kortix accounts use` switches organization. A **session** is a workbench: an isolated sandbox on its own branch. A coder task opens one, and older goals do all their work in sessions. The goal's Chat is not a session, and the CLI has no command for it. Talk to the goal in Auto Lab or in its channel. A command that acts on one goal picks it in this order: the `--project ` flag, the goal the current folder is linked to (`.kortix/link.json`), then your default goal. ## Goals | Command | What it does | | --- | --- | | `kortix projects ls` | List the goals you can open in the active organization. Add `--all` for every organization. | | `kortix projects use []` | Set your default goal. With no ID, it asks. | | `kortix projects info []` | Show one goal. | | `kortix projects open []` | Open the goal in your browser. | | `kortix projects clone [] []` | Clone the goal's repository and link the folder to the goal. | | `kortix accounts use []` | Switch the active organization. `kortix accounts ls` lists them. | ```sh kortix projects ls kortix projects clone 3f2a9c1e-5b7d-4e8a-9c0f-1d2e3f4a5b6c weekly-brief ``` Clone goes through Auto Lab with your sign-in, whether the repository is managed by Auto Lab or lives on GitHub. It also sets up the folder so plain `git pull` and `git push` use your sign-in. You need no separate git credentials. See [The goal's repository](/docs/developers/repository) for what is inside. ## Change files and ship them Edit a cloned goal like any git repository, then ship your work: ```sh git switch -c tidy-outreach-skill kortix ship -m "Tidy the outreach skill" kortix cr open --head tidy-outreach-skill --title "Tidy the outreach skill" ``` `kortix ship` checks the [goal manifest](/docs/developers/manifest), commits any changes, and pushes your current branch to the same branch on the goal's repository. Along the way it asks for any secret or connector the manifest needs and does not have yet. Use `-n` to see what it would do without doing it. Work on a branch and open a change request, so your change is reviewed the same way as the agents' changes. Pushing straight to `main` also works when your role lets you push. `kortix init --force`, run inside a cloned goal, adds the files that let local coding tools (Codex, Claude Code, Cursor, OpenCode, Pi) read the goal's agents and skills. It does not change how the goal runs in Auto Lab. > **Start new goals in Auto Lab** > > Create a goal with **New goal** in the web app, so its agent can set it up with you. Running `kortix ship` in a folder that is not linked to a goal creates a new goal from that folder, without the setup conversation. ## Sessions | Command | What it does | | --- | --- | | `kortix sessions ls` | List the goal's sessions. | | `kortix sessions log ` | Print a session's recent messages without sending anything. | | `kortix chat []` | Talk to a session's agent, or send one message with `--prompt`. | | `kortix connect []` | Open a session in OpenCode's terminal interface (OpenCode is the coding agent that runs inside a session). With no ID, it lets you pick. | | `kortix sessions shell ` | Open a plain shell in the session's sandbox, with no agent. | | `kortix sessions new --prompt ""` | Start a session. Add `--wait` to wait until it is running. | | `kortix sessions stop ` | Pause a session. Its disk is kept. | ```sh kortix sessions ls kortix sessions new --prompt "Add a test for the lead scoring script" --wait ``` ## Change requests and review A change request proposes merging one branch into another, usually a session's branch into `main`. `` is the change request's number or ID. | Command | What it does | | --- | --- | | `kortix cr ls` | List open change requests. Add `--status all` for every one. | | `kortix cr show ` | Show one change request. | | `kortix cr diff ` | Print its changes. | | `kortix cr open --head --title ""` | Open a change request from a branch into the default branch. | | `kortix cr merge ` | Merge an open change request. | | `kortix cr request-changes --message ""` | Send it back to the agent that opened it, with your note. | | `kortix cr close ` | Close it without merging. | | `kortix review ls` | List everything in the goal's Review Center. | | `kortix review act ` | Decide one item: `approve`, `reject`, `changes`, `answer` or `dismiss`. | ```sh kortix cr diff 12 kortix cr merge 12 ``` ## Secrets | Command | What it does | | --- | --- | | `kortix secrets ls` | List the goal's secrets by name, and which ones the manifest needs but are missing. | | `kortix secrets set NAME=VALUE` | Save a secret. Write `NAME=-` to read the value from standard input. | | `kortix secrets request NAME` | Create a secure link so someone else can type the value. You never see it. | | `kortix secrets unset NAME` | Remove a secret. | ```sh printf '%s' "$HUBSPOT_TOKEN" | kortix secrets set HUBSPOT_TOKEN=- ``` See [Secrets](/docs/connect/secrets) for how values reach the agents. ## Connectors | Command | What it does | | --- | --- | | `kortix connectors ls` | List the goal's connectors and their status. | | `kortix connectors show ` | Show a connector and its tools. | | `kortix connectors discover ""` | Find tools by describing what you want to do. | | `kortix connectors call . ''` | Run one tool. | | `kortix connectors connect ` | Print a link to authorize a connector. | ```sh kortix connectors discover "find unread email from customers" ``` `discover` returns the matching tools as JSON, each named `.`. `kortix connectors show .` shows the arguments a tool takes. Pass the name to `call`, with the arguments as JSON. A call runs server-side, with the goal's connection and its tool rules. The CLI never holds the tool's credentials. When a rule says ask first, the call returns an approval link instead of running. See [Connectors](/docs/connect/connectors). ## Triggers, channels and models | Command | What it does | | --- | --- | | `kortix triggers ls` | List the triggers in the goal manifest and their state. | | `kortix triggers fire ` | Fire one trigger now. | | `kortix triggers pause` | Stop all of the goal's triggers from firing on their own. `resume` starts them again. | | `kortix channels status` | Show the goal's chat channel connection. | | `kortix channels connect` | Print an "Add to Slack" link. Add `--platform teams` for Microsoft Teams, when Teams is switched on for the goal. | | `kortix models ls` | List the models the goal offers. | | `kortix models default ` | Set the goal's default model. | | `kortix agents model ` | Pin one agent to a model. | Triggers here are the ones declared in the manifest. The agent's own reminders, check-ups and routines are in **Brain › Schedules**. See [Plans, schedules and triggers](/docs/goals/schedules), [Channels](/docs/connect/channels) and [Models](/docs/brain/models). ## Access | Command | What it does | | --- | --- | | `kortix access ls` | List the people who can open the goal and their roles. | | `kortix access invite --role member` | Invite someone to the goal. | | `kortix access grant --user --role manager` | Give someone a role on the goal. | | `kortix access revoke ` | Remove someone's access to the goal. | Goal roles are `manager` (shown as **Project admin**) and `member` (**Project member**). Organization roles are `owner`, `admin` and `member`. See [Roles and access](/docs/organization/access). ## When an agent uses the CLI The goal's agents run the same `kortix` command inside their sandboxes: - They do not sign in. The sandbox gives them a token bound to that goal and session, so commands act on that goal without a link file. - An agent can never do more than the person its work runs for. If the goal manifest limits an agent's `kortix_cli` commands, it is held to that list too. - A session can push only to its own branch, so its work reaches `main` through a change request. - Agents learn the platform with `kortix system-skills`. See [The goal's repository](/docs/developers/repository). ## Help and exit codes Every command has `--help`, for example `kortix cr --help`. `kortix --help` lists every command. | Exit code | Meaning | | --- | --- | | `0` | It worked. | | `1` | It failed. The reason is printed to standard error. | | `2` | A flag, subcommand or argument was wrong or missing. | --- # Goal manifest Every key in kortix.yaml, the goal manifest: agents, connectors, triggers, sandbox and env. Canonical page: https://app.auto-lab.ai/docs/developers/manifest `kortix.yaml` at the root of the [goal's repository](/docs/developers/repository) is the goal manifest; the UI calls it the project manifest. It says which agents may run and what each may touch, which connectors and triggers the goal has, which machine sessions start on and which secret names the goal expects. This page is the reference for version 2, which every new goal uses. ## Check the file The schema is public. The first line of the example below points your editor at it. `kortix validate` checks the file in a clone, and `kortix schema --version 2` prints the schema. The same check runs when a change request merges, and an invalid manifest blocks the merge. Top-level keys Auto Lab does not know are skipped rather than rejected, so the file can carry your own notes. A version higher than 2 is refused. Older goals may still have a version 1 `kortix.toml`; new goals never do. ## A full example ```yaml # yaml-language-server: $schema=https://app.auto-lab.ai/schema/kortix.v2.schema.json kortix_version: 2 default_agent: kortix env: required: [CRM_API_KEY] optional: [FORM_WEBHOOK_SECRET] sandbox: default: data templates: - slug: data name: Data tools dockerfile: .kortix/Dockerfile cpu: 4 memory: 8 agents: kortix: connectors: all secrets: all skills: all kortix_cli: all reporter: connectors: [hubspot, gmail] connectors_required: [hubspot] secrets: [CRM_API_KEY] skills: [weekly-brief] kortix_cli: [project.read, project.gitops.push] connectors: - slug: hubspot provider: composio app: hubspot policies: - match: "*delete*" action: block - slug: gmail provider: composio app: gmail authorization_strategy: user sensitive: true policies: - match: "gmail.*send*" action: require_approval policy: default_mode: risk triggers: - slug: monday-brief name: Monday brief type: cron agent: reporter cron: "0 0 8 * * 1" timezone: Europe/London prompt: Draft this week's competitor brief and send it to me for review. - slug: new-lead type: webhook secret_env: FORM_WEBHOOK_SECRET filter: body.type: lead prompt: | New lead from {{ body.email }} at {{ body.company }}. Check it against our qualification rules. ``` The example assumes the repository has `.kortix/opencode/agents/reporter.md`, a `weekly-brief` skill and both secrets. ## Top-level keys | Key | Required | Default | What it sets | |---|---|---|---| | `kortix_version` | yes | | Must be `2`. | | `default_agent` | yes | | The agent a session or trigger runs when it names none. Must be a declared agent that is not disabled. | | `agents` | yes | | What each agent may touch. At least one agent. | | `project` | no | | `name` and `description`, for people reading the file. | | `env` | no | | The secret names the goal expects. | | `sandbox` | no | Auto Lab default | Machine images and which one sessions use. | | `connectors` | no | | The tools agents can call. | | `policies` | no | | Tool rules that apply across every connector. | | `policy.default_mode` | no | `allow_all` | What happens to a tool call no rule matches. | | `triggers` | no | | Scheduled and webhook automation. | | `opencode.config_dir` | no | `.kortix/opencode` | Where sessions read agents and skills. Leave it: the Chat and learning always use `.kortix/opencode`. | | `runtime` | no | `opencode` | Leave it unset. `pi` is an experiment behind a feature flag. | | `apps` | no | | Only read when the Apps feature is switched on for the goal. It is off by default. | A `channels` or `sandboxes` key is an error. Channels are connected in **Settings › Channels**, not in the file. ## `agents` `agents` maps an agent name to what it is allowed to touch. It holds no behaviour. The prompt, model, mode, temperature and tool permissions live in the agent's own file, `.kortix/opencode/agents/.md`, and the map key must match that file name. Putting one of those fields in `kortix.yaml` is an error. See [Agents and skills](/docs/brain/agents-and-skills). | Field | Default | Notes | |---|---|---| | _(name)_ | | Lowercase letters, digits, `-` and `_`, up to 128 characters. | | `enabled` | `true` | `false` keeps the agent from starting. | | `connectors` | none | Connector slugs it may call, or `all`. | | `connectors_required` | none | Connectors that must have a working connection before a session starts. Each must also be in `connectors`. | | `secrets` | none | Secrets it receives, by name, or `all`. | | `skills` | none | Skills it may load, by name, or `all`. | | `kortix_cli` | none | What it may do with the `kortix` CLI and the API, as a list of permissions, or `all`. | | `sandbox` | | The slug of the sandbox template its sessions start on. | | `workspace` | `branch` | `branch` gives its sessions the repository on their own branch. `runtime` and `read` start them without a copy of the repository. | Grants are deny-by-default. A field you leave out means nothing is granted. `all` never lifts an agent above the person who started it. `kortix_cli` takes goal-level permissions only, such as `project.read`, `project.gitops.push` or `project.trigger.read`; run `kortix validate --scopes` for the full list. Organization permissions can never be granted to an agent. Even with `project.gitops.merge`, a session cannot merge a change request it opened. The Chat's access to connectors follows the `connectors` grant of an agent named `harness-main` when the manifest declares one, and the grant of `default_agent` otherwise. ## `connectors` A connector is a tool agents can call. The definition lives in the file. The credential lives in Auto Lab and never in git. See [Connectors](/docs/connect/connectors). | Field | Default | Notes | |---|---|---| | `slug` | required | Lowercase, unique among connectors. `kortix_slack`, `kortix_teams` and `kortix_email` are reserved for channels. | | `provider` | required | See the next table. | | `name` | the slug | Display name. | | `enabled` | `true` | | | `authorization_strategy` | `project` | `project` uses the goal's shared connection. `user` uses only the connection of the person the agent acts for. | | `sensitive` | `false` | `true` makes every call ask first, reads included, unless a rule allows it. | | `policies` | | Rules for this connector's tools. `match` is a pattern over tool names, `action` is `always_run`, `require_approval` or `block`. | | `auth` | | How to send the credential: `type` (`bearer`, `basic`, `api_key`, `custom`, `oauth1`, `hmac`, `aws_sigv4`, `mtls` or `none`), `in` (`header`, `query` or `cookie`) and `name` for `api_key` and `custom`. | | `headers` | | Fixed request headers, up to 32. They are plain text in git, so never put a credential here. | | Provider | Needs | Notes | |---|---|---| | `composio` | `app` | An app from the connector catalogue, such as `gmail`. | | `pipedream` | `app` | | | `mcp` | `url` | `transport` is `http` (default) or `sse`. | | `openapi` | `spec` | A URL or a path in the repository. | | `postman` | `spec` | A collection URL or path. | | `graphql` | `endpoint` | `spec` is optional. | | `http` | `base_url` | `spec` is optional. | | `channel` | `platform` | `slack`, `teams` or `email`. Auto Lab writes these when you connect a channel. | ## Tool rules Patterns use `*` as a wildcard and ignore case. A connector's own `policies` match its tool names. The top-level `policies` match `.` and apply to every connector. Auto Lab decides each call in this order, and the first answer wins: 1. Top-level `policies`, top to bottom. 2. The connector's `policies`. 3. `sensitive: true` on the connector: ask first. 4. `policy.default_mode`: `allow_all` runs the call. `risk` runs reads and asks before writes and deletes. The **Delegation** dial writes these keys for you. **Asks before acting** adds a first rule that asks before every call and sets `risk`. **Acts on its own** removes that rule and sets `allow_all`. **Acts within your rules** puts your own rules and mode back. See [Approvals and autonomy](/docs/goals/approvals). ## `triggers` A trigger runs the agent on a schedule or when a signed HTTP request arrives. See [Plans, schedules and triggers](/docs/goals/schedules). | Field | Default | Notes | |---|---|---| | `slug` | required | Lowercase, unique among triggers. | | `type` | required | `cron`, `webhook` or `monitor`. | | `prompt` | required | The message the agent receives. `{{ … }}` placeholders are filled from the payload. | | `name` | the slug | Display name. | | `agent` | `default_agent` | Must name a declared agent. Leave it out rather than writing `default`. | | `enabled` | `true` | `false` keeps the trigger without firing it. | | `model` | chosen when it fires | Pins a model, as `provider/model`. See [Models](/docs/brain/models). | | `session_mode` | `fresh` | Which session a fire uses. See below. | | `filter` | | Payload paths and the values they must equal, such as `body.type: lead`. A delivery that does not match is accepted and ignored. | **Cron.** Set `cron` to a six-field expression (second, minute, hour, day of month, month, day of week), or `run_at` to one ISO-8601 time for a single run. `timezone` is an IANA name and defaults to `UTC`. **Webhook.** The URL is `https://api.auto-lab.ai/v1/webhooks/projects//`. `secret_env` names the secret that holds the signing key. Sign the raw body with HMAC-SHA256 and send `X-Kortix-Signature: sha256=`; GitHub's `X-Hub-Signature-256` also works. A sender that cannot sign can send the key itself in `X-Kortix-Token` or `Authorization`. The prompt can use `{{ body. }}`, `{{ headers.user_agent }}`, `{{ trigger.slug }}` and `{{ fired_at }}`. The secret must be delivered to connectors only, never to a machine: ```bash kortix secrets delivery FORM_WEBHOOK_SECRET none --consumer connector ``` **Monitor.** An always-on command from the repository whose output lines are events. Monitors are experimental and need the **Monitors** flag in [Feature flags](/docs/goals/settings#feature-flags), which is off by default. **Session mode.** `fresh` starts a new session on every fire. `reuse` sends each fire to the session this trigger started last, so context builds up; monitors use it by default. `pinned` uses the session in `session_id`. A `session_key` such as `{{ body.chat_id }}` keeps one session per value; an empty key falls back to `fresh`. On a goal with the Chat, a webhook or monitor fire does not start a session. It wakes the Chat with the trigger's prompt and a summary of the payload. If the agent was not waiting for that event, the turn can only read, not act. Cron triggers still start a session, and those sessions count against **Settings › Autonomy** limits (**New sessions per day**, **Sandbox minutes per day**). The plan's routine and check-ups are not manifest triggers on these goals. They are the agent's own schedules in **Brain › Schedules**. ## `env` `env.required` and `env.optional` list names only. Values are [secrets](/docs/connect/secrets) and never go in the file. **Settings › Secrets** lists the declared names so people know what to fill in; a missing `required` value does not stop a session. Names use letters, digits and `_`, do not start with a digit, are stored in upper case and fit in 64 characters. `KORTIX_` names are reserved. An agent receives a secret only through its `secrets` grant. ## `sandbox` `sandbox.templates` is a list of machine images. Each entry takes these fields: | Field | Notes | |---|---| | `slug` | Required and unique. Up to 64 characters in practice. `default` is reserved. | | `name` | Display name. Defaults to the slug. | | `dockerfile` | A path inside the repository. Set this or `image`, not both. | | `image` | A public image with a pinned tag or digest, such as `python:3.12-slim`. `latest` gets a warning. | | `entrypoint` | Leave it unset. | | `cpu`, `memory`, `disk` | 1 to 32 vCPUs, 1 to 128 GiB of memory, 1 to 500 GiB of disk. | A value below the minimum is an error. A value above the maximum gets a warning and is capped. GPUs are not supported. `sandbox.default` must name a template declared here, or `default` for the Auto Lab image. An agent's own `sandbox` key wins over it. For Dockerfile rules and rebuilds, see [Sandbox templates](/docs/developers/repository#sandbox-templates). ## When changes take effect - **A change in a session or a clone** takes effect once its change request merges into the default branch. New sessions start from that branch, and the Chat picks the change up within about a minute. - **A change saved in the UI** (a trigger, a connector, a tool rule, the **Delegation** dial) is committed to the default branch at once. Auto Lab rewrites the file from its parsed contents when it saves, so comments are dropped and `kortix_version` moves to the top. - **A webhook trigger** answers `404` until its entry is on the default branch and enabled. - **A sandbox change** builds a new image. Running sessions keep the machine they started on. - **A secret value** is read when a machine starts, so it applies to the next session. --- # MCP Let your own AI client read and steer your goals through the Auto Lab MCP server, or give any assistant these docs through the public docs server. Canonical page: https://app.auto-lab.ai/docs/developers/mcp Auto Lab runs two MCP servers. The first lets an AI client you already use, such as a desktop assistant or a coding tool, read and steer your goals with your permission. The second serves these docs to any assistant, with no sign-in. | Server | Address | Sign-in | What it reaches | | --- | --- | --- | --- | | Auto Lab MCP | `https://api.auto-lab.ai/v1/autolab/mcp` | OAuth, one grant per person | Goals in one organization, under your permissions | | Docs MCP | `https://app.auto-lab.ai/mcp` | None | Public docs and product pages | ## Connect your AI client to your goals ### Check your client Your client must support: - the Streamable HTTP transport; - OAuth with a client ID you register in advance (automatic client registration is not offered); - PKCE with the S256 method; - resource indicators, sending the server address as `resource`; - a fixed callback URL that you can copy. The callback must be HTTPS, or HTTP on `localhost`, `127.0.0.1` or `[::1]` for a client that runs on your machine. Auto Lab matches it exactly. ### Register and connect ### Copy the server URL Open **Personal settings › MCP**. Under **Connect your client**, copy the **Server URL**. ### Register your client Under **Register a public client**, pick the organization in **Account**. Enter a **Client name** and paste the **Callback URL** your client shows. Leave **Allow project changes and plan approval** off unless the client needs to change things. Select **Register client**, then copy the **Client ID**. ### Sign in from your client Enter the server URL and the client ID in your client, then start its sign-in. Auto Lab shows a consent page with the organization, the server and the access asked for. Check them, then select **Allow**. Registering a client needs permission to create OAuth clients in the organization. If you do not have it, ask an organization admin to register the client for you. A registration gives no one access by itself. Each person who uses the client signs in and allows it separately. You need no API key and no client secret. ## What the client can do The server's tool names say "project" because the API calls a goal a project. With read access, the client can use: | Tool | What it returns | | --- | --- | | `list_projects` | The goals you can open in the organization you approved. | | `get_project` | One goal. | | `get_outcome` | The goal's objective, what it tracks, and its delegation level. | | `get_plan` | The approved plan. | | `preview_plan` | A proposed plan in a change request, without approving it. | | `list_tasks`, `get_task` | The task board, or one task by its key. | | `list_change_requests` | The goal's change requests. | With read and write access, it can also use: | Tool | What it does | | --- | --- | | `set_objective` | Save a new objective. It does not re-plan or start work. | | `create_task` | Add a draft task to the board. It does not start an agent. | | `update_task` | Move a task to another lane (Planned, Active, Blocked, For review, Done), or change its title or description. | | `approve_plan` | Approve a plan change request: merge it and queue its first routine. | Every call runs under your own permissions on that goal, and private session details stay hidden as they do in the app. The grant covers only the organization you approved, even if you belong to others. Lists come in pages: pass `offset` and a `limit` of up to 100. > **Plan approval starts work** > > `approve_plan` merges the plan and can start the goal's routines. Read the plan with `preview_plan` first, and only ask your client to approve it when you mean to. It needs permission to edit the goal, merge its changes and fire its routines. The goal's usual review rules still apply. If an approval reports a failure after the merge, keep the change request ID and retry the same approval once the repository problem is fixed. ## Revoke a client's access In **Personal settings › MCP**, **Your granted access** lists each client you allowed, marked **Read only** or **Read and change projects**. Select **Revoke** and confirm. The client loses your access and its refresh tokens at once. The client's registration and other people's grants stay in place. To use the client again, sign in from it and allow it again. Auto Lab never re-approves an MCP client on its own. ## Protocol details | Topic | Detail | | --- | --- | | Transport | Stateless. Send every message as a POST. There are no server sessions or GET event streams. | | Discovery | Protected-resource metadata at `https://api.auto-lab.ai/.well-known/oauth-protected-resource/v1/autolab/mcp`. It names the Auto Lab authorization server, described in [Sign in with Auto Lab](/docs/developers/api#sign-in-with-auto-lab). | | Scopes | `mcp:read`, plus `mcp:write` for write access. | | Resource | The server URL. Send the same value when you ask for a code, exchange it and refresh. | | Tokens | Access tokens last one hour. Refresh tokens last 30 days and work once each. | | Credentials | Only tokens from this sign-in work here. Personal access keys and browser sign-ins are refused. | | Size | A result over 256 KiB returns an error. Ask for a smaller page or one task. | ## Docs MCP `https://app.auto-lab.ai/mcp` is an anonymous, read-only MCP server with these docs and Auto Lab's public pages. It holds no goal data. Add it to any assistant that supports Streamable HTTP. The exact settings format depends on the assistant, for example: ```json { "mcpServers": { "autolab-docs": { "url": "https://app.auto-lab.ai/mcp" } } } ``` | Tool | What it does | | --- | --- | | `list_public_content` | List public pages with their title, description and path. Filter with `kind` (`docs`, `marketing`, `blog` or `use-case`) and `limit` (1 to 50, default 25). | | `get_public_markdown` | Return one page as Markdown, by the path from the list, such as `/docs/quickstart`. | The server also offers each page as a Markdown resource. Its server card is at `https://app.auto-lab.ai/.well-known/mcp/server-card.json`. ## Plain-text docs for AI tools Crawlers and assistants that do not speak MCP can read two plain-text files: | File | What it holds | | --- | --- | | `https://app.auto-lab.ai/llms.txt` | An index of the public pages, each linked to its Markdown copy. | | `https://app.auto-lab.ai/llms-full.txt` | The full text of every public page in one file. | --- # The goal's repository Every goal is a private git repository. What lives in it, how changes land in it, and the machines work runs on. Canonical page: https://app.auto-lab.ai/docs/developers/repository Every goal is backed by a private git repository that holds its instructions, memory, plan, agents, skills and settings as files, so every change has an author and a history and can be reviewed or undone. You never need to open it to use Auto Lab. This page is for developers who want to read it, clone it or change it by hand. ## Where the repository lives You choose where the repository lives when you create the goal. **Auto Lab managed** is the default. The GitHub options sit behind **Have code already? Import a GitHub repository** on the Describe page. | Option | What happens | |---|---| | **Auto Lab managed** | Auto Lab creates and manages a private repository for the goal. Its default branch is `main`. | | **Create in GitHub** | Auto Lab creates a private repository in a GitHub account connected to your organization. | | **Import from GitHub** | You pick an existing repository from that GitHub account. | The two GitHub options need a GitHub account connected to the organization first. ### Keep it small The goal's repository holds what the agents know and the rules they work under. It is not where your product lives. Every session clones it, so keep it small. Your product code stays in its own repositories. When a task needs to change one, a coder task clones that repository in its session and works there. Do not add a manifest to an existing codebase to turn it into a goal. Create a goal, and tell it which repositories it works on. ## Settings › Git repo **Settings › Git repo** shows the repository the goal runs from. | Row | What it shows | |---|---| | **Repository** | The repository, with a link to it on GitHub when it lives there. | | **Status** | **Connected**, **Needs attention**, **Connecting…** or **Not connected**. A banner explains a repository Auto Lab can't reach. | | **Base branch** | The branch new sessions and change requests start from. | | **Manifest file** | The path of the [goal manifest](/docs/developers/manifest), `kortix.yaml` by default. | ### Clone it with the CLI **Work on this locally** lists the commands. Install the CLI first, see [CLI](/docs/developers/cli). The CLI calls a goal a project. ```bash kortix projects clone cd kortix init --force kortix env pull ``` - `kortix projects clone` clones through Auto Lab with your CLI sign-in. No token is written into the remote URL. - `kortix init --force` connects the coding tools you use locally (OpenCode, Claude Code, Codex, Pi or Cursor) to the clone. It does not replace repository files. - `kortix env pull` writes a `.env` file with the names of the goal's secrets and empty values. Secret values never leave Auto Lab, so you fill them in yourself. ### Clone it with plain git Open **Use your own Git client** to copy the clone address. It looks like `https://api.auto-lab.ai/v1/git/.git`. When git asks for credentials, enter any username and a personal access key as the password. You create keys in **Personal settings › Personal access keys**, see [API and sign-in](/docs/developers/api). A push with your key acts as you. If your role lets you push, you can push to any branch, including the default one. Prefer a branch and a change request, so your change is reviewed like the agent's. Deleting a branch needs the goal admin role, and nobody can delete the default branch. ### Give someone direct access People who can manage the goal's members also see **People with access**. For an Auto Lab managed repository, invite a GitHub username with **Can edit** or **Can view**, and GitHub emails them an invitation. For a repository in your own GitHub account, manage access on GitHub with **Manage on GitHub**. ## What lives in the repository The UI calls `kortix.yaml` the project manifest and `.kortix/` the system files. ```text kortix.yaml the goal manifest .kortix/ memory/ what the goal knows objective.md the objective, in full instructions.md goal instructions a person approved profile.md a one-page profile, rewritten each night playbook.md the lessons that matter most, ranked each night knowledge/ facts, procedures, preferences, decisions, lessons entities/ people and organizations timeline/ notes from each turn, rolled up by day, week and month comms/ the text of messages sent and received, by channel workstreams/ active, completed and someday work plan/ PLAN.md this week's plan tasks.yaml its tasks, owners and check-ups opencode/ agents/.md an agent's prompt and behaviour skills//SKILL.md a skill; learned-/ folders are ones learning wrote opencode.jsonc settings for the agent runtime in sessions Dockerfile optional, a custom machine image ``` A few files need a word more: - **Goal instructions.** `instructions.md` is a short list of standing instructions. The agent reads it on every turn, right after its own prompt. Learning can propose one small edit at a time, always as a change request. You can edit it yourself in **Brain › Memory**. - **The plan.** Launch approves `PLAN.md` and `tasks.yaml` and copies the tasks to the Overview. From then on the Overview's **Work** board is the live state, not the file. - **Agents and skills.** The Chat's own prompt is built in, unless the repository has `.kortix/opencode/agents/harness-main.md`. The Chat and sessions read the same skills. See [Agents and skills](/docs/brain/agents-and-skills). - **Learned items.** Lessons, stated preferences and `learned-` skills are what learning applied on its own. Undo any of them in [Brain › Learning](/docs/brain/learning). ## How changes reach the default branch Changes from Auto Lab reach the default branch in one of three ways. 1. **The Chat commits memory directly.** It writes only its notes, message logs, rollups, lessons, stated preferences, the profile and playbook, and its own `learned-` skills. 2. **Everything else is a change request.** The plan, replacing or removing memory, knowledge the agent inferred, the objective, goal instructions, agents, skills a person wrote, the manifest, and any work done in a session. 3. **Some settings commit the manifest directly.** Triggers, connectors, tool rules and the **Delegation** dial write `kortix.yaml` on the default branch when you save them in the UI. Commits and change requests use a title prefix, so you can tell them apart in the history: | Prefix | Kind | What it carries | |---|---|---| | `plan:` | Change request | `PLAN.md`, `tasks.yaml` and sometimes `objective.md`, on a branch named `autolab/plan--`. **Launch** or **Update plan** merges it. | | `memory:` | Commit | The agent's notes after a turn, message logs and the nightly rollups. | | `memory:` | Change request | Replacing or removing memory, knowledge the agent inferred, or a new objective. | | `harness:` | Change request | Changes to agent prompts, skills or goal instructions. | | `learned:` | Commit | What learning applied on its own. Each item can be undone. | Review branches for `memory:` and `harness:` change requests are named `autolab/review--`. On older session goals, `harness:` change requests also come from the daily reflection. Whether a re-plan waits for you depends on the goal's autonomy, see [Approvals and autonomy](/docs/goals/approvals). ### Change requests from a session A session works on its own branch, named after the session id. When it is done, the agent commits, pushes the branch and opens a change request. A person reviews it in **Needs you** or the Review Center and merges it or asks for changes. A few rules always hold: - A session can push only to its own branch. - Its change request targets the branch the session started from. Only a person can retarget it. - No grant lets a session merge its own change request. Someone else has to. - The merge checks `kortix.yaml`. An invalid manifest blocks the merge. - A merged change reaches new sessions. A running session sees it only after it merges the default branch in. ## Where the work runs The Chat runs on Auto Lab's servers. Conversation, memory, connectors and planning need no machine, and the Chat reads the repository through Auto Lab. It picks up a merged change within about a minute. A machine is started only when work needs a shell or files: - **An environment.** The first time a turn or a task agent needs a shell or files, Auto Lab starts an environment: a machine with the repository checked out on its own branch, a shell, git, Node, Python and a browser. Scheduled routines, docs tasks that build a file and browser tasks all work in one. Later calls reuse it. It stops after an hour without use and starts again from its branch when it is needed. - **A session.** A coder task opens a full session with its own coding agent. It ends in a change request. Older goals without the Chat run all their work in sessions. A session's machine stops about 15 minutes after its last turn ends. An open browser tab does not keep it running. Git is the record that lasts. Work that was committed and pushed survives a stopped machine. ## Sandbox templates A sandbox template is the recipe for the machine a session runs on. **Settings › Sandbox templates** lists the goal's templates and the record of every time Auto Lab built a machine image from one. Every goal starts with the **Auto Lab default**, an Ubuntu image with Auto Lab's tools and the repository checked out at `/workspace`. Most goals need nothing else. Add a template when sessions need tools that the default does not have. ### Add a template Click **New template**. Give it a **Name** and a **Slug**. Under **Image source**, pick **Public image** with a pinned tag (not `latest`), or **Dockerfile** with a path inside the repository. Set **Resources** if you need more than the default: 1 to 32 vCPU, 1 to 128 GiB memory, 1 to 500 GiB disk. Leave **Entrypoint** blank. ### Choose which sessions use it A session uses the first of these that is set: the template picked for that session, its agent's `sandbox` key, the manifest's `sandbox.default`, then the Auto Lab default. `sandbox.default` must name a template declared in the manifest. See [Goal manifest](/docs/developers/manifest). ### Wait for the build Creating or changing a template starts a build of its machine image. The first build can take several minutes. Sessions started in the meantime wait for it; they don't fail. You can also declare templates in `kortix.yaml` under `sandbox.templates`. Each template card shows where it was defined: **Auto Lab platform**, **This dashboard** or `kortix.yaml`. The Chat's environment uses a lighter Auto Lab image. When the manifest sets `sandbox.default` to one of your templates, the environment uses that template instead, so your tools are there too. ### When the image is rebuilt A new template, an edited Dockerfile or a merged change to either starts a new build. The **Build log** has one row per build, with what triggered it. A failed row matters only while a banner at the top says sessions can't start. Then use **Rebuild**, or **Fix with agent** to have an agent look at the error. ### Dockerfile rules Auto Lab adds its own runtime layer on top of your Dockerfile. `kortix validate` checks these rules before you push: | Rule | Why | |---|---| | Base the final stage on Debian or Ubuntu. | The runtime layer installs with `apt-get`. | | Don't `COPY` files from the build context. | Your repository isn't in it. It is cloned to `/workspace` when a session starts. | | Don't use `RUN` heredocs. | Some builders can't read them and the build fails. | | Don't put credentials in the image. | Declare the name under `env` and store the value as a [secret](/docs/connect/secrets). | --- # Approvals and autonomy How much the goal's agent may do without asking, the rules behind it, where approvals reach you, and how change requests work. Canonical page: https://app.auto-lab.ai/docs/goals/approvals You decide how much the goal's agent does on its own. One setting, **Delegation**, sets the overall level; rules for single tools fine-tune it; and anything that needs a person reaches you as an approval, a question or a change request. This page covers each, plus the limits that keep automated work in bounds. ## How much it does on its own During setup this is **On its own** in the goal brief. Later you change it with the **Delegation** control in the Overview header, or in **Settings › Autonomy › Delegation**. | In setup | On the Overview | Actions in connected apps | Re-plans | |---|---|---|---| | **Asks before acting** | **Ask first** | Every call waits for your approval, reads included. | Every revision waits for you. | | **Acts within your rules** | **Within policy** | Your connector rules decide. With no rules of your own, reads run and writes and deletes wait for you. | Revisions that only change tasks and check-ups apply at once. | | **Acts on its own** | **Act freely** | Calls run without asking, writes and deletes included, unless one of your rules says otherwise. Connectors set to **Ask before every use** still ask. | Revisions that only change tasks and check-ups apply at once. | A few things to know: - A new goal stays at **Ask first** until you select **Launch**. Launch applies your choice, or **Within policy** if you made none. - The level is stored as the goal's connector rules. The control shows what it means right now, for example "Now: calls that only read run on their own; writes and deletes wait for your approval." If someone edits the rules later, the control says so and shows where the goal stands. - Moving from **Ask first** or **Act freely** back to **Within policy** restores the rules you had before. - Only people who can manage connector rules can change the level. - It does not change how the agent learns. That is the **Learning** setting on the same page; see [Learning](/docs/brain/learning). Website logins and daily limits, below, also apply whatever the level. ## Rules for single tools Open **Brain › Connectors**, or select **Edit connector rules** in the **Delegation** control. There are two layers, and the first rule that matches a call decides: 1. **Global rules** apply to every connector. Each matches a tool name pattern, such as `gmail.send_*`, and is **Allow** (runs without asking), **Ask first** (waits for your approval) or **Block** (never runs, and the agent cannot see it). 2. On a connector's own page, each tool is **Default**, **Block**, **Ask** or **Allow**. The **Ask before every use** switch makes every tool of that connector ask, reads included, unless a rule opens one. Use it for mail, files or anything where reading is itself sensitive. A call no rule covers follows the goal's default: **Ask before risky actions** (reads run, writes and deletes ask) or **Run everything**. See [Connectors](/docs/connect/connectors). ## Where approvals reach you When a rule asks first, the agent pauses that step and asks. You can decide in any of these places, and the first decision counts everywhere: | Where | What you see | |---|---| | Chat | A **Needs your approval** card pinned above the composer: the app and action, its risk (read, write or destructive) and the exact values, with **Approve** and **Deny**. | | **Overview › Needs you** | An **Approval** card with **Approve**, **Deny** and the **⋯** menu (**More choices**). | | Review Center | **Brain › Review** lists every approval. Open one to see its full values before you decide. | | Your channels | The approval also goes to the Slack, Teams, iMessage or email conversation the request came from, or where the schedule reports. In Slack and iMessage, a message the agent wants to send arrives as the draft itself, ending with "Go?": reply **go** to send it, **no** to stop it, or say what to change. | | An approval page | Each approval has its own page at a link like `/approve/`, opened from **Open approval page** on the card. Sign in, check the values and decide. The decision covers that one call. | If nobody decides in the app, **Escalate what needs you** can forward it after a delay; see [Plans, schedules and triggers](/docs/goals/schedules#escalate-what-needs-you). Only a signed-in person can decide. An agent never approves its own call, whatever access it has. A call that recorded no values can only be denied. ### Approve and make it a rule On an **Approval** card in **Needs you**, open the **⋯** menu (**More choices**) and select **Approve and make it a rule**. This approves the call and adds an **Allow** rule for that exact action at the top of the global rules, so it runs without asking from now on. It needs the right to manage connector rules. If the rule cannot be saved, the approval still stands and a message says so. ### Scheduled actions approved in advance When the agent sets a routine that repeats one gated action, such as posting a weekly summary to a channel, it can ask you to approve that action once, when it sets the schedule. Later runs then carry out exactly that action without a new card. Anything different still asks. ## Questions When the agent needs a decision or a fact, it asks. In Chat the question is pinned above the composer: pick an option, type your own under "Something else…", or select **Skip** to let it continue without an answer. If the question went to a channel, reply in that conversation and your reply answers it. A task agent never asks you directly; the goal's agent asks in Chat on its behalf. ## Change requests A **change request** is a proposed change to the goal's repository: its plan, instructions, skills, memory, settings or code. It waits on a separate branch until a person approves it, so nothing in it takes effect before that. Each one records who proposed what and who approved it, and you can send it back with a note. | What goes through a change request | Where it shows up | |---|---| | A new or revised plan that waits for you | A **Plan** card in **Needs you**, and a card in Chat | | Work from a Coder task | **Review change request #…** on the task card | | Changes learning proposes that need you, such as replacing memory or editing a skill a person wrote | **Brain › Learning › Needs your decision**, **Needs you** on the Overview and the Review Center | | An item you make with **Create in chat** in the Brain, such as a trigger or a skill | **Needs you** and the Review Center | Open a change request from **Needs you** or from the Review Center at **Brain › Review**. You see what was proposed, the changed files and, when there is one, the session that made it. Then: - **Approve** applies it. For a plan the button is **Approve plan**. Approving needs permission to merge changes on the goal. - **Request changes** (**Ask for changes** in the Review Center) asks what should change. For work that came from a session, **Send to the agent** hands your note over and the agent revises the same change request; otherwise the note is saved on it. - **Dismiss** in the Review Center closes it without applying anything. - If the change conflicts with newer work, or would break the goal manifest, **Fix with the agent** starts an agent that resolves it and opens a replacement. A change request is **Waiting on you**, **Applied** or **Dismissed**. An agent can open change requests but never applies its own: the session that opened one cannot merge it, whatever permissions it holds. A re-plan that only changes tasks, under **Within policy** or **Act freely**, is applied by Auto Lab under your rules, not by the agent. ## Action audit **Settings › Autonomy › Action audit** lists connector actions and approval decisions. Filter by result: **Awaiting approval**, **Succeeded**, **Denied** or **Failed**. Request values and secrets are never shown. The history needs audit access for your organization; without it the card says so, and your approval rules still apply. ## Automation limits The **Automation** card in **Settings › Autonomy** caps how much automated machine work the goal starts each day. | Setting | Default | What it limits | |---|---|---| | **Sandbox minutes per day** | 120 | Machine time used by sessions and by task agents that need a machine of their own | | **New sessions per day** | 20 | Sessions started in a day. Reusing a session that already exists still works. | The card shows today's use, and people who manage the goal's triggers can change the limits. Limits reset at midnight UTC. At a limit, the card says **Paused: daily automation budget reached** or **Daily session limit reached**, and new automated work that needs a machine does not start: a scheduled trigger skips its run, and a task agent that needs its own machine reports that the daily budget is used up. Sessions already running finish. Conversation in Chat, and task agents that need no machine, carry on. ### Approve website login use The **Approve website login use** switch sits on the same card. When it is on, the first time an agent uses a saved website login in a session, it asks for your approval. One approval covers that login for the rest of that session. Only people who can manage the goal's secrets can change it. See [Website logins and secure links](/docs/connect/website-logins). --- # Chat and runs The goal's one conversation across the web and your channels, the task agents it hands work to, and the sessions they work in. Canonical page: https://app.auto-lab.ai/docs/goals/chat **Chat** is the goal's single running conversation. You and the goal's other admins talk to its agent here, from the web app or from any channel connected to the goal. Goal members can read Chat but not send messages. This page covers what you can do in Chat, what shows up in it, how the agent hands work to task agents, and where sessions fit. ## One conversation per goal Select **Chat** in the goal's rail. Messages from the web app, Slack, Microsoft Teams, iMessage and email all land in the same conversation, so the agent has the whole story wherever you write from. Its answer goes back to the place the message came from, and the web page shows everything. To connect a channel, see [Channels](/docs/connect/channels). A message from someone who is not on the goal, such as an email from outside your organization, is answered in Chat only, with limited tools. Nothing goes back to that sender until someone on the goal gives the go. ## What you can do in Chat | To | Do this | |---|---| | Ask or hand over work | Type in the composer and send. Say what you need in your own words. | | Steer while it works | Send another message. The agent reads it at its next step instead of waiting for the current turn to end. | | Answer a specific message | Hover the message and select the reply arrow, double-click it, or long-press it on a phone. The composer names the message you are answering; press Esc to cancel. | | Attach files | Select the paperclip. Up to 10 files per message, 20 MB each: photos, PDFs, text and data files, Office documents. A message can be files alone. | | Stop the agent | Send `/stop`. It ends the running turn. Task agents that are already running carry on; cancel them on the **Runs** page. | | Shorten the history | Send `/compact`. The agent summarizes the older part of the conversation and keeps the recent part word for word. | The agent looks at photos directly. To read a document, it hands the file to a task agent. `/compact` changes what the agent carries into each turn, not what you see: every message stays on the page, and the agent can still search the full history. It also compacts on its own when the conversation grows long. Either way, Chat shows **History compacted**. When the agent answers something other than your last message, such as a task reporting back or a reminder firing, its reply quotes the message it belongs to. Select the quote to jump to the original. ## What shows up in Chat Chat also shows what happens between messages. | You see | What it means | |---|---| | **Needs your approval**, with **Approve** and **Deny** | The agent wants to take an action your rules gate. The card names the app and action, its risk (read, write or destructive) and the exact values. See [Approvals and autonomy](/docs/goals/approvals). | | A question above the composer | The agent needs a decision or a fact. The card stays pinned until you answer, so it never scrolls away. Pick an option, type your own, or select **Skip** to let it continue without an answer. | | **… task** cards, such as **Research task** | A task agent is working. Progress lines fill in, then its report. **Open run** opens it on the Runs page. | | **Connect …** | The agent needs access to an app. **Connect** opens the connection page in a new tab. Once the app is connected, Chat carries on with what you asked. | | **Learned: …** with **Undo** | The agent saved something it learned. **Undo** takes it back. See [Learning](/docs/brain/learning). | | **Scheduled reminder**, **Scheduled check-up**, **Scheduled routine** | One of the goal's schedules fired. The messages below it are that run. See [Plans, schedules and triggers](/docs/goals/schedules). | | **Reply arrived** | Something the agent was waiting for came in, such as an answer to an email it sent. | | **Delivery to … failed** | A reply could not reach Slack, Teams, iMessage or email. The agent does not claim a message was delivered when it was not. | Older messages load a page at a time: select **Load earlier messages** at the top. ## Task agents and runs To keep the conversation focused, the agent hands pieces of work to **task agents**. Each hand-off is a **run**. A run shows as a card in Chat that fills in as the task agent works. | Task agent | What it does | Limit | |---|---|---| | Research | Answers one question. It reads the goal's connected apps (read only), its memory and, when it needs them, its files, and searches and reads the web. It changes nothing in your apps. | 60 steps, 25 minutes | | Docs | Drafts or updates one document or message. It can read and write in connected apps; a write your rules gate comes back to Chat as an approval card. | 40 steps, 20 minutes | | Mail reader | Turns one email into a short summary: what it says, what it asks, the dates. It has no tools, so it cannot act on what the email says. | 1 step, 1 minute | | Browser | Uses one website in a browser of its own, signed in with a saved login when there is one. It never sees your password. A purchase stops at the final review and waits for you to confirm. | 60 steps, 20 minutes | | Coder | Opens a session on its own branch of the goal's repository, makes the change and ends with a change request for you to review. The card links **Review change request #…**. | 60 minutes | A few rules apply to every task agent: - It cannot ask you anything. When it needs you, it stops with **Needs input** and the agent asks you in Chat. - It cannot set schedules or start other task agents. - A goal runs up to 10 task agents at a time, counting queued ones. At the limit, the agent waits for one to finish or cancels one. - If the agent is waiting on your approval or answer when a run ends, the run's report waits until you decide. ### The Runs page Open **Runs** from a task card's **Open run**, or from the **⋯** menu on the sidebar's recent list while Chat is selected. Each row shows the role, the brief, the status, when it started, how long it took, the steps it used out of its limit, tokens, cost, and where it ran: | Environment | Meaning | |---|---| | **Shared** | It ran without a machine of its own. | | **Own box** | It had its own machine, for files or a browser. | | **Workbench** | It worked in a session. Coder runs work this way. | Select **Cancel** to stop a queued or running run. Select a row to open its brief, its report and **What the agent did**, step by step. ### Watch the browser live While a Browser run is working or waiting for input, open it to see a **Live view**: the page as the agent sees it. If the agent is stuck on a check it cannot clear, you can click the picture, **Type** a short text such as a code, or **Press** one key. ## Sessions: the workbench Chat is the conversation; sessions are the workbench. A **session** is an isolated cloud machine with its own branch of the goal's repository. On a goal that runs in Chat you do not talk in sessions. The agent uses them for hands-on work: - a Coder task works in a session and ends with a change request - a task agent that needs files or a browser gets a machine of its own - a scheduled trigger from **Brain › Triggers** starts a session for each run To see them all, open the **⋯** menu on the sidebar's recent list and select **All sessions**. Every row carries a **Workbench** tag, and a session a task agent opened links back to its run. Filter by **Mine** or **All sources**, group by status or source, or search by title. **Manage** lets you rename, share, restart, stop or delete sessions. **New session** opens one directly, for example to work on files with an agent; that conversation stays in the session and does not appear in Chat. A session's machine stops when it has been idle for a while and keeps its files. Only work committed to the session's branch lasts after the session is deleted. Each session has its own access setting, **Session access**: **Only you**, **Specific people**, or everyone on the goal. The person who started the session changes it. For sessions a trigger starts, set it on the trigger. ## Bring an earlier session into Chat A goal that worked in sessions before it moved to Chat opens with an empty conversation. Select **Import the last session as history** to copy the text of the most recent finished session into Chat. The agent can then refer to it and search it. Nothing runs, tool details are left out, and each session imports only once. If the agent is busy, try again when it finishes. ## Older goals without Chat A goal that has not moved to Chat opens **Chat** as a new session. Each conversation there is its own session, listed in the sidebar, and the agent works in that session's machine. These goals have no Runs page and no **Brain › Schedules**; recurring work runs from **Brain › Triggers**. --- # Working with goals What a goal is, the Goals home, moving around inside a goal, who can see it, and how to pause or delete it. Canonical page: https://app.auto-lab.ai/docs/goals A goal is one outcome you want Auto Lab to work toward over weeks, such as "find 10 qualified leads a week". Each goal has its own agent, its own weekly plan and its own Chat. This page shows how to find your goals, move around inside one, share it, pause it and delete it. ## What a goal is A goal belongs to one organization. Everything it knows lives in its own private git repository: its instructions, memory, skills, plan and settings. That is why every change to a goal has an author and a history, and why a change can be reviewed before it lands. You choose where that repository lives when you create the goal: | Repository | What happens | |---|---| | **Auto Lab managed** (default) | Auto Lab creates and hosts a private repository for the goal, on the `main` branch. Nothing to set up. | | **Create in GitHub** | Auto Lab creates a private repository in a GitHub account connected to your organization. | | **Import from GitHub** | The goal uses a repository that already exists in that GitHub account. | The two GitHub options sit behind **Have code already? Import a GitHub repository** on the first setup page. Keep the repository about the goal. Each session the agent opens works from a copy of it, so large files slow every start. Your product's code can stay where it is: name the repository during setup and the agent connects to it through GitHub like any other tool. Developers can read more in [The goal's repository](/docs/developers/repository). ## The Goals home **Goals** lists every goal you can open, under three headings: | Heading | A goal sits here when | |---|---| | **Needs you** | A decision waits for a person, or the goal stopped for today because it reached a daily limit. | | **In progress** | Nothing waits on you and its triggers are running. | | **Paused** | Its triggers are paused and nothing waits on you. | Inside each heading, goals with decisions waiting come first, then goals that slipped (overdue tasks, or a number moving away from its target), then quiet ones. Each row shows: - a progress ring for the current plan. Point at it to read, for example, "3 of 8 tasks done". - the goal's name and, on wider screens, its number against the target, such as "6 / 10 qualified leads this week · On track", with an arrow for the trend. - one line: the agent's latest update, or why the goal stopped, such as "Stopped for today: the daily session limit was reached." - the next one or two tasks with their state and due date, and how many decisions wait for you. Select a goal's name to open it. The **⋯** menu on the row has **Open**, **New session** and **Settings**. Below the list, **Start a goal** offers **Sales**, **Customers** and **Operations**. Each opens a new goal with a name filled in. The **+** next to the **Goals** heading opens a blank one. If you have no goals at all, Auto Lab creates a first one for you and opens its setup. ## Create a goal Choose **New goal** from the Goals home or **New goal…** from the goal switcher. Write the outcome in a sentence, then the goal's agent sets it up with you in a short conversation. See [Set up and launch a goal](/docs/goals/setup). Only organization owners and admins can create goals. Anyone else sees "You need owner or admin access in an organization to create a goal." ## Find your way around a goal Inside a goal, the sidebar lists its pages from top to bottom: | Row | What it opens | Read more | |---|---|---| | **All goals** | The Goals home. | [The Goals home](#the-goals-home) | | **Set up** | Setup, until the first plan is launched. It shows how far you got, such as "2 of 3". | [Set up and launch a goal](/docs/goals/setup) | | **Overview** | The goal, what needs you and the week's work. A number on the row counts what needs you. | [Overview, Needs you and Activity](/docs/goals/overview) | | **Chat** | The goal's one conversation, on the web and in your channels. | [Chat and runs](/docs/goals/chat) | | **Activity** | What the goal did, day by day. | [Activity](/docs/goals/overview#activity) | | **Brain** | What the agents know and how that changes, starting with Learning. | [What's in the Brain](/docs/brain) | | **Files** | A read-only view of the goal's repository. | [Browse the goal's files](#browse-the-goals-files) | | **Apps** | Only when the Apps feature flag is on for the goal. | [Feature flags](/docs/goals/settings#feature-flags) | | **Settings** | The goal's configuration. | [Goal settings](/docs/goals/settings) | You see the rows your role allows. A goal member sees Overview, Chat, Activity and the Learning tab of Brain. **Files**, **Settings** and the rest of Brain are for goal admins. **Set up** shows only to people who can change the goal. ## Switch between goals Select the goal's name at the top of the sidebar. The menu has: - **Switch goal**: type in **Find a goal…**, pick a goal from the list (grouped by organization when you belong to more than one), open **Organization settings**, or start **New goal…** - **All goals**: back to the Goals home - **Settings**: your personal settings, not the goal's ## Who can see a goal Organization owners and admins can open every goal in their organization. Everyone else sees a goal only after someone adds them to it, directly or through a group, as a goal member or a goal admin. A member can open the goal and follow its work, but cannot write in Chat. An admin can also talk to the agent and change the goal, its Brain, its settings and who has access. To add or remove people, open **Settings › Access**. It lists the people and groups on the goal, pending invitations and requests for access. The exact rights of each role are in [Roles and access](/docs/organization/access). The Goal brief also has an **Access** row: **Only you** or **Everyone in your organization**, changed with **Share** and **Make private**. It records who the goal is meant for. It does not add anyone by itself: use **Settings › Access** for that. ## Pause a goal Where you pause depends on the kind of work: - **Triggers.** Open **Brain › Triggers**, choose the gear (**Trigger settings**) and switch on **Pause all triggers**. No trigger starts on its own until you switch it off, though you can still start one by hand. The goal moves to **Paused** on the Goals home. This needs permission to update triggers, which goal admins have. - **The plan's routine and check-ups.** On a goal that runs in Chat, these are schedules the agent keeps. Open **Brain › Schedules** to see each one's next run, run it now or cancel it. See [Plans, schedules and triggers](/docs/goals/schedules). - **How much runs each day.** **Settings › Autonomy** sets **Sandbox minutes per day** and **New sessions per day**. When a limit is reached, nothing that needs a new machine starts until the limits reset at midnight UTC. Chat and check-ins carry on, and the goal shows under **Needs you** on the Goals home. > **Pausing triggers does not hold the plan's schedules** > > On a goal that runs in Chat, **Pause all triggers** stops triggers only. The routine and check-ups installed at > Launch keep running until you cancel them in **Brain › Schedules**. ## Delete a goal Open **Settings › Archive** and choose **Delete goal**. Type the goal's name to confirm. You need permission to delete the goal, which goal admins and organization owners and admins have. Deleting cannot be undone from Auto Lab. Everyone loses the goal at once: its sessions and their history, all scheduled runs and triggers, and every connection, secret and API key scoped to it. The goal's git repository is not deleted, and anything already pushed to it stays there. ## Browse the goal's files **Files** shows the goal's repository as folders and files. It is read-only: changes to a goal arrive as change requests that you review, not as edits here. - Open a file to preview it. Right-click a file for **Download** or its **Version history**. **Download folder** is in the view options menu. - The version picker (**Switch version**) chooses what you are reading: the **Main version**, or another version, such as the one a session is working in. - **Version history** at the top lists every saved version. **Proposed changes** lists change requests waiting for review. Files needs permission to read the goal's files, which goal admins have. --- # Overview, Needs you and Activity Read a goal's progress, act on what needs you, follow the week's work, and see what the goal did day by day. Canonical page: https://app.auto-lab.ai/docs/goals/overview The **Overview** is the first page of every goal. From top to bottom it shows the goal and its progress, what needs you, the week's work and what the agent learned. **Activity** is the record of what the goal did. ## The goal card The card at the top holds: - **Goal** with a pencil (**Edit goal**). The pencil opens setup in edit mode. See [Edit the goal later](/docs/goals/setup#edit-the-goal-later). - the goal sentence, with its **Tracking** line under it, such as "Tracking 10 qualified leads per week". - **Progress** on the right, such as "6 / 10 qualified leads this week · On track". A goal without a number shows the plan's tasks instead, such as "3 of 8 tasks done". - **This week**: a short summary of the week, written from the goal's work, with when it was last updated. The state next to the number tells you how the period is going: | State | Meaning | |---|---| | **On track** | The count keeps pace with the target, or a limit is being kept. | | **Behind** | The count is under 80% of where it should be by now, once 40% of the period has passed. For a limit, it is over the limit. | | **Done** | The target for the period is reached. | | **No reading yet** | Nothing has been counted in this period. | A week counts Monday to Friday, so a goal is never Behind on Monday morning. How to write a sentence the agent can track is in [Write a good goal sentence](/docs/goals/setup#write-a-good-goal-sentence). If you change the goal after its plan was approved, the card says so, for example "The plan was approved 3 days ago, before the objective changed yesterday." Choose **Replan** to open edit mode and update the plan. A goal that has no sentence yet shows **No goal yet** and **Set the goal**. ## Needs you **Needs you** lists everything waiting on a person, one row each, with the decision in the row. The count next to the heading is the same number shown on the **Overview** row in the sidebar. When nothing waits, it says "You're caught up." | Row | What it is | What to do | |---|---|---| | **Approval** | A connector call the agent wants to make, such as sending an email, with its details. | **Approve** or **Deny**. If no details were recorded, you can only deny. | | **Waiting on you** | A session stopped for your answer. | **Open** it and answer. | | **Review** | Work waiting for your review in the Review Center. | **Open** it and review. | | **Change request** | A proposed change to the goal's files. | **Review**, then **Approve** to apply it or **Request changes** to send it back with a note. | | **Plan** | A proposed plan, or an approved plan that never finished applying. | **Review plan**, then **Approve plan** or **Request changes**. A plan that did not finish shows **Apply this plan**. | | **Your task** | A plan task the agent gave you, such as a login or a decision. | Do it, then **Mark done**. The row says how many tasks wait on it. | | **Suggestion** | Older goals only: **Turn on daily learning**. | **Turn on**, or leave it. It never counts as waiting. | Each row also says how long it has waited and, when a task or check-up gives one, when it is due. Finished work marked for your review shows here too. Questions the agent asks in Chat wait above the Chat composer instead. See [Chat and runs](/docs/goals/chat). ### Approve and make it a rule On an approval row, the **⋯** menu (**More choices**) has **Approve and make it a rule**. It approves this call and adds a connector rule so the same action runs without asking from now on. You see, for example, "Approved. New rule: Gmail · send email runs without asking from now on." The option shows only if you can manage the goal's connector rules. See [Approvals and autonomy](/docs/goals/approvals). ### Review Center When the Review Center is on for the goal, which it is by default, a **Review Center** link sits next to the **Needs you** heading. It opens **Brain › Review**, one inbox for change requests, approvals and agent output. ## Work **Work** is the agent's work for the week. Switch between **List** and **Board**; the goal remembers your choice in this browser. Under the heading, one line sums up the plan, such as "2 of 6 done", with **Open plan**. When a new plan is proposed, the line offers **Review proposed plan**. Both views use the same four groups, in this order: | Group | What is in it | |---|---| | **In progress** | Tasks the agent is working on now. | | **Blocked** | Tasks held back by unfinished tasks or by a recorded reason. | | **Planned** | Tasks not started yet. | | **Done this week** | What finished in the last seven days. | Each row or card has one more line: what the agent last said about the task, why it is blocked, or who holds it. The list also keeps itself short: blocked tasks waiting on the same tasks share one row, and **Done this week** is one line you can open up. An empty week says "Nothing planned yet." with **Plan the week**. ### Move a task Select a task to open it in a drawer. It shows the description, owner, due date, what it depends on, and the linked session or change request. The footer holds the moves you make most: | Action | What it does | |---|---| | **Mark done** | Moves the task to done. | | **Reopen** | Moves a done task back to in progress. | | **Block** | Asks "Why is it blocked?". A reason is required, because it is what the next run reads first. Then choose **Block task**. | | **Unblock** | Moves a blocked task back to in progress and clears the reason. | The **Lane** menu sets the task's status: **Planned**, **Active** (listed under **In progress**), **Blocked**, **For review** (listed under **Needs you**) or **Done**. Moving tasks needs permission to edit the goal. The agent moves tasks the same way as it works. ## Learned this week This section appears once the agent has learned something this week. Each item is marked **Fact**, **Decision**, **Preference** or **Lesson**. **Everything it has learned** opens **Brain › Learning**. See [Learning](/docs/brain/learning). ## The Delegation dial The dial at the top of the Overview sets how much the agent does without asking: | Position | What it means | |---|---| | **Ask first** | Every connector call waits for your approval before it runs. | | **Within policy** | Your connector rules decide which calls run and which wait for you. | | **Act freely** | Connector calls run without asking, writes and deletes included, unless a rule says otherwise. Connectors set to **Ask before every use** still ask. | Under the positions, a line starting "Now:" says what the current rules actually do, with a link to edit them. Moving the dial needs permission to manage connectors. The same dial is in **Settings › Autonomy**. See [Approvals and autonomy](/docs/goals/approvals). ## Activity **Activity** in the sidebar is the goal's record, grouped by day. It opens on what was done: one line per piece of work, such as a request and everything the agent did for it, or one scheduled run. Small runs that changed nothing fold into a line such as "And 3 smaller things". Select a line that names a session or a change request to open it in place. **Load earlier** goes further back. **See every event** opens the full log, with a filter: | Filter | Shows | |---|---| | **All** | Every event. | | **Sessions** | Sessions started, finished or failed, Chat turns, matched replies, feedback, failed deliveries and task board updates. | | **Runs** | Scheduled runs, schedule fires, task runs and learning reviews. | | **Changes** | Change requests opened, merged or closed, memory and skill edits, and background reviews. | **Back to what was done** returns to the summary. If your deployment has no model to write the summary lines, Activity shows the full log straight away. The written summary of the week is on the Overview, under **This week**. --- # Plans, schedules and triggers The week plan you approve at Launch, how the agent re-plans, the schedules that wake it, and triggers you set up yourself. Canonical page: https://app.auto-lab.ai/docs/goals/schedules Nothing in Auto Lab runs all the time. The goal's agent wakes when someone writes to it, when one of its schedules fires, or when something it waits for arrives. This page covers the plan that drives the week, the schedules the agent keeps, and the triggers you can set up yourself. ## The week plan At the end of setup the agent drafts the first week, and the **First week** panel shows it: | Part | What it is | |---|---| | Tasks | The work for the week. Each task is owned by **Agent** or **You**. | | **Check-ins** | When the agent's routine runs, for example **Weekdays 9:00**. | | **Tracking** | How progress is measured: the number in your goal, or **Tasks done**. | **Launch** approves the plan. It puts the tasks on the Overview's board, installs the routine and the plan's check-ups in **Brain › Schedules**, and runs the first check-in right away. Check-ins report to the place you picked under **Reaches you** during setup. Microsoft Teams is the exception: it gets escalations only, and routine output stays in Chat. Tasks you own show in **Needs you** as **Your task**. See [Set up and launch a goal](/docs/goals/setup). At each check-in the agent: 1. reads the goal, its progress and the open tasks, and takes the next planned task that is ready 2. asks you for exactly what it needs when the task is yours or needs something only you can give, such as a login, a connection or a choice, and meanwhile does the work that does not depend on it 3. moves the task on the board as it goes and records progress 4. ends with what it did and the next step, or, when it is blocked, what it will do if you do not answer ### Change the plan yourself Select the pencil on the Overview to open **Edit goal**, then say what to change or edit the brief. A revision shows as a list of **New**, **Changed** and **Dropped** tasks with **Update plan** and **Keep current plan**. Nothing changes until you select **Update plan**. You can also ask for a change in Chat; a revision you ask for waits for your approval, at every autonomy level. If you change the goal itself after a plan was approved, the Overview notes that the plan is older than the goal and offers **Replan**. ## Re-planning The agent proposes the next plan on its own when: - the week ends - no planned task is left - progress falls behind pace (the Overview shows **Behind**) - the same task fails twice Whether its revision applies at once depends on the goal's Delegation dial ([Approvals and autonomy](/docs/goals/approvals)): | Revision | **Ask first** | **Within policy** or **Act freely** | |---|---|---| | Changes only tasks and check-ups | Waits for you | Applies at once. Chat shows **Plan updated** with the task count. | | Changes the goal, the check-in cadence, or adds a task for you | Waits for you | Waits for you | A revision that waits shows as a **Plan** card in **Needs you** and as a card in Chat. Open it and select **Approve plan**, or request changes. A change you asked for in Chat always waits for you. A revision that applied on its own was approved by Auto Lab under your rules, never by the agent, and its change request stays in the history. To reverse it, tell the agent in Chat what you want back. ## Schedules **Brain › Schedules** lists everything that wakes the agent on a clock: "Reminders, check-ups and routines the agent keeps for itself, with their next fires and last results." | Kind | What it does | |---|---| | **Reminder** | Messages you once, at a set time. | | **Check-up** | A one-time job the agent set for itself, such as checking on Thursday whether a vendor replied. The plan's check-ups are this kind. | | **Routine** | Work that repeats. The plan's check-ins are the goal's routine. | | **Heartbeat** | Every 30 minutes, goes through a checklist and speaks only when something needs attention. It is paused by default. | | **Event wait** | A deadline for something the agent is waiting for, such as a reply to an email. If it arrives first, Chat shows **Reply arrived**. If not, the agent decides at the deadline whether to follow up. | To add one, ask in Chat: "remind me Friday at 4 pm to send the invoice", or "every Monday at 9, send me the pipeline summary". The agent replies with the exact time it set. It understands times such as "in 45 minutes", "tomorrow at 9", "every weekday" and "every 90 minutes", in the goal's time zone. Each row shows the kind, its status (**Active** or **Paused**), the next fire, the last result, and where it reports: **here**, meaning where it was set, or a recipient the agent named, such as a Slack channel, an iMessage number or an email address. A red row means the last delivery failed or a fire is overdue. - **Run now** fires a schedule immediately. It is not offered for an event wait. - **Cancel** stops it for good. Auto Lab also keeps a few schedules of its own on every launched goal, such as memory upkeep, the learning review and an **Evening recap** at 21:00 in your time zone: what got done today, what is still open with you and what slipped. The recap skips days with no activity. You cannot cancel these rows. Schedules fire within about a minute of their time. If a fire is missed, for example during an outage, it is skipped unless the agent set it to run once late, and Chat notes the missed slot. ## Pause scheduled work **Brain › Triggers** has its own **Pause all triggers** switch, described below. The routine, check-ups and reminders in **Brain › Schedules** have no pause switch yet: cancel the ones you want to stop, or ask the agent in Chat to change its schedule. See [Pause a goal](/docs/goals#pause-a-goal). ## Triggers A trigger is work you set up yourself in **Brain › Triggers**: an instruction that runs on a schedule, or when another app sends a request. Select **New trigger**, then **Create in chat** to have an agent draft it as a change request, or **Set up manually**. | Kind | Starts | On a goal that runs in Chat | |---|---|---| | **Scheduled** | On a repeating schedule, or once at a set time | Each run starts a session with your instruction as its first message. The work shows under **All sessions**, not in Chat. | | **Webhook** | When another app sends a request to the trigger's private address | Each request goes to Chat with your instruction and a summary of what arrived. The agent answers there with limited tools: it reads and reports, and takes no action from the request alone. If it was waiting for that event, it wakes with its usual tools. | For recurring work that should talk to you in Chat, ask the agent for a routine instead of a scheduled trigger. A repeating scheduled trigger can start up to 30 minutes after the time you set, so that goals with the same schedule do not all start at once. A frequent schedule shifts less: at most a quarter of its interval. A trigger set to run once at a set time is not shifted. Monitors, a third kind that watches a command's output, are set up in the goal manifest and run only where they are switched on. See [Goal manifest](/docs/developers/manifest). ### Set up a webhook trigger ### Choose Webhook In **Brain › Triggers**, select **New trigger**, then **Set up manually**, then **Webhook**. ### Say what it does Give it a **Name** and an **Instruction**: what the agent should do each time a request arrives. Leave **Agent** and **Model** as they are unless you need another. ### Add a signing key Paste a key under **Signing key** or select **Generate**. Auto Lab saves it as one of the goal's secrets. Under **Advanced** you can add conditions under **Only run when**, so that requests you do not care about are recorded but start nothing, and choose the end of the address under **Custom ID**. Turn off **Start it right away** to create it paused. ### Give the address to the other app Open the new trigger, select **Copy address** and paste it into the other app. That app must sign each request with the same key. **Sample request** shows a signed example; the signature has to cover the request body exactly as it is sent. To start a trigger by hand, open it and select **Run now**. To stop every trigger at once, select the gear next to **New trigger** and turn on **Pause all triggers**; only people who manage the goal see the gear. Paused triggers ignore incoming requests, and you can still start one by hand. ### Daily digest **Daily digest** sends one summary a day of the goal's shared activity to up to four destinations: linked channels or your verified email. Turn on **Enable daily digest**, set the **Delivery time (UTC)**, choose the destinations and select **Save digest**. Quiet days send nothing, and private sessions and conversation text are left out. **Send today's digest now** sends it at once. Pausing the goal's triggers pauses digests too. ### Escalate what needs you **Escalate what needs you** sends a question, approval, change request or plan that is still waiting to up to four channels or your email, after a delay you set (**Wait before escalating**, 10 minutes by default). Anything answered in the app within the delay is never sent, and nothing goes out during **Quiet hours (UTC)**. Launch turns escalation on for the channel you picked in setup, when that channel is linked. **Recent escalations** shows what went out and why anything was not sent. --- # Goal settings Each section of a goal's Settings page, what it controls and who can change it, including feature flags. Canonical page: https://app.auto-lab.ai/docs/goals/settings **Settings** is the last row in a goal's sidebar. It opens the goal's configuration, with one section per row on the left. This page walks through the sections in that order and links to the page that covers each in depth. ## Who can open Settings The **Settings** row shows to people who can configure the goal: goal admins, and organization owners and admins. Inside, each section checks your rights again. A section you cannot read is hidden, and one you can read but not change is shown without its controls. The page lives at `/projects//customize/settings`. The older address `/projects//settings` opens the same page. A link that names a personal tab, such as `/projects//settings/profile`, opens your personal settings over the goal instead. ## General - **Goal name** and **Icon**: how the goal appears in the switcher and on the Goals home. Changing them needs permission to edit the goal. - **Goal brief**: the answers from setup, which the agent reads each time it drafts a plan. The rows are read-only here. **Edit goal** opens setup in edit mode, or **Edit in setup** for goals set up with the form, or **Start setup** if setup never started. See [Set up and launch a goal](/docs/goals/setup#edit-the-goal-later). - **Danger zone**: **Delete goal**, the same action as [Archive](#archive). ## Access The people and groups who can open this goal, their roles, pending invitations and requests for access. Invite someone, change a role or remove access here. Seeing the list needs permission to see members; changing it needs permission to manage members, which goal admins have. See [Roles and access](/docs/organization/access). ## Autonomy How much the agent does on its own, in four cards: | Card | What it controls | Read more | |---|---|---| | **Delegation** | The same dial as on the Overview: **Ask first**, **Within policy** or **Act freely**. | [Approvals and autonomy](/docs/goals/approvals) | | **Learning** | On goals that run in Chat: **Off**, **Ask me first** or **Learn on its own** (the default). | [Learning](/docs/brain/learning) | | **Automation** | **Approve website login use**, **Sandbox minutes per day** (120 by default) and **New sessions per day** (20 by default). Limits reset at midnight UTC. Older goals also have **Daily reflection** here. | [Usage and limits](/docs/organization/usage) | | **Action audit** | A history of connector actions and approval decisions, filtered by result. It needs audit access. | [Approvals and autonomy](/docs/goals/approvals) | Each card checks its own permission. Goal admins can change all four. ## Channels Link the goal to Slack and, when they are switched on for the goal, Microsoft Teams, iMessage and email. This is also where you see which Slack workspace or inbox the goal uses. Changing channels needs permission to manage connectors. See [Channels](/docs/connect/channels). ## Connectors The same page as **Brain › Connectors**: the apps, MCP servers and API keys the goal can use, and the rule for each tool. Changing them needs permission to manage connectors. See [Connectors](/docs/connect/connectors). ## Secrets The same page as **Brain › Secrets**: encrypted values, such as API keys, that the goal's agents can use. Changing them needs permission to manage secrets. See [Secrets](/docs/connect/secrets). ## Triggers The same page as **Brain › Triggers**: schedules and webhooks that start work, including **Daily digest** and **Escalate what needs you**. The gear (**Trigger settings**) holds **Pause all triggers**. Adding a trigger needs permission to create triggers. See [Plans, schedules and triggers](/docs/goals/schedules). ## Git repo The goal's repository and who can reach it: - the **Repository** and its **Status** - the **Base branch**: new sessions and change requests start from it - the **Manifest file**: the goal manifest, `kortix.yaml` by default - **Work on this locally** and **Use your own Git client**: commands and a clone address for developers - **People with access**: for a repository Auto Lab created, invite someone by GitHub username with **Can edit** or **Can view**. For one Auto Lab did not create, use **Manage on GitHub**. Seeing this section needs permission to read the repository; changing it needs permission to push. See [The goal's repository](/docs/developers/repository). ## Sandbox templates The recipe for the machine a session runs on, and a record of each time one was prepared. Anyone who can open Settings can read it; changing it needs permission to configure the goal. See [Sandbox templates](/docs/developers/repository#sandbox-templates). ## Feature flags Some features can be switched on for one goal before they are generally available. **Feature flags** lists them. Each row has the feature's name, one sentence about it, whether it is on by default or set for this goal, and a switch. - A switch changes this goal only, straight away. Other goals and other organizations are not affected. - The setting is kept by Auto Lab, not in the goal's repository, so it does not travel with a copy of the repository. - A flag appears only when your Auto Lab deployment supports it. If the deployment does not offer a feature, its row is hidden, whatever the goal chose. - Anyone who can open Settings can see the list. Turning a flag on or off needs permission to configure the goal, which goal admins have. Flags a goal owner is most likely to meet: | Flag | What it turns on | Default | |---|---|---| | **Apps** | The **Apps** row in the goal's sidebar, for publishing sites and services at stable addresses. | Off | | **Microsoft Teams** | Teams as a channel for the goal. An admin of your Microsoft 365 tenant also has to grant consent. | Off | | **iMessage** | An iMessage line for the goal, once the line and its keys are added. | Off | | **AgentMail Email** | Email as a channel: an inbox for the goal whose threads reach the agent. | Off | | **Review Center** | The review inbox in **Brain › Review**, and its link on the Overview. | On | | **Harness v2 thread** | Chat as one conversation for the goal, with its schedules. | On | Leave **Harness v2 thread** on. Without it, Chat opens a separate session for each conversation instead of the goal's one thread. The list also shows other flags, such as **Marketplace** (the Brain tab of that name), **Warm Sessions** and **Network-Enforced Secrets**. Leave any flag you do not recognize as it is. Setting up each channel is covered in [Channels](/docs/connect/channels). ## Upgrades Changes an agent makes to the goal's setup for you. Each run opens a change request for you to review, and nothing merges on its own. A known upgrade shows here only while it applies, such as **Upgrade to v2** for a goal whose manifest still uses the first version. While one is waiting, the **Upgrades** row shows a dot. You can also describe a one-off change for an agent to make. See [Goal manifest](/docs/developers/manifest). ## Archive **Delete goal** removes the goal for everyone. You type the goal's name to confirm, and it needs permission to delete the goal. The goal's git repository is kept. See [Delete a goal](/docs/goals#delete-a-goal). --- # Set up and launch a goal Describe the outcome, set the goal up with its agent, launch the first week, and change the goal later. Canonical page: https://app.auto-lab.ai/docs/goals/setup Setting up a goal takes about two minutes. You describe the outcome, the goal's own agent asks for what it still needs, and you launch a first week of work. Nothing runs on its own until you launch. ### Describe Choose **New goal** and answer "What should Auto Lab work toward?" in a sentence or two. Choose **Start**. ### Set up together The goal's agent asks only for what is missing. The **Goal brief** on the right fills in as you answer. Then choose **Draft my first week**. ### Launch Read the first week, ask for any changes, and choose **Launch**. The goal opens on its Overview. Only organization owners and admins can create a goal, and only people who can change a goal can set it up. ## Write a good goal sentence The agent reads the number in your sentence as what it tracks, and shows it as a **Tracking** line under the goal. A good sentence names one outcome, a number, what is counted, and a period or a date. | You write | Under the goal | |---|---| | Find 10 qualified leads a week for our Series A outreach | Tracking 10 qualified leads per week | | Book 15 demos per week, counted in HubSpot | Tracking 15 demos per week | | Publish 3 blog posts a month | Tracking 3 blog posts per month | | Grow MRR to $50k by December 31 | Tracking $50,000 MRR by Dec 31 | | Keep first response time under 4 hours | Tracking at most 4 hours | | Send me a competitor brief every week | Tracking 1 competitor brief per week | | Get more leads | No Tracking line. Progress counts the plan's tasks done. | - Say the period plainly: "a day", "per week", "a month", "weekly", or "by" and a date. - Use "at most", "under", "within" or "no more than" for something you want to keep low. - Say where the number lives, such as "counted in HubSpot", and the agent reads it there. For work it does itself, such as leads it finds or briefs it sends, it counts its own work. Otherwise it asks you for the number when it checks in. - Leave other numbers out. In "Follow up with every new customer in their first two weeks", the agent tracks "2 weeks". - The agent never asks you for a target. To change the number, change the sentence. ## Describe On the **Describe** page, write your sentence, or start from an example: **Weekly competitor brief**, **Qualify inbound leads**, **Customer onboarding follow-ups** or **Recruiting coordinator**. - **Add a doc or spec** attaches up to 10 files of 20 MB each, such as a brief, a spreadsheet or a PDF. The agent reads them with your sentence. - Auto Lab suggests a name and an icon: "We'll call it … · **Rename**". - If you can create goals in more than one organization, pick the **Organization**. - **Have code already? Import a GitHub repository** switches the goal from an Auto Lab managed repository to one in GitHub. See [What a goal is](/docs/goals#what-a-goal-is). **Start** creates the goal and opens its setup. ## Set up together The agent opens with one sentence saying the goal as it understands it and the role it will play. Then it asks at most two questions at a time, each with options. Pick an option, type your own answer, or choose **Skip**. It always asks where to reach you. It asks how much it may do alone, and for rules, only when the goal acts on the outside world, for example by sending email, writing to a CRM, posting or spending. If your goal names a team, it offers to share the goal. It never asks for a number. ### The Goal brief The brief shows what is stored, so it looks the same after a reload. Every row can be changed in place. | Row | What it holds | What it changes | |---|---|---| | **Goal** | Your sentence, with its Tracking line. | What the agent works toward and the number on the Overview. | | **Role** | The agent's job in a few words, such as "market researcher". Shows "From your goal" until set. | How the agent describes its own job in its instructions. | | **Works with** | The apps and websites the goal uses. | What the agent can read and use. See below. | | **Reaches you** | Where updates and questions go. **Here in Auto Lab** by default. | Where the plan's routine and check-ups deliver after Launch. Microsoft Teams gets escalations only; routine output stays in Chat. | | **On its own** | **Asks before acting**, **Acts within your rules** (default) or **Acts on its own**. | How often the agent asks before it acts. After Launch this is the Delegation dial. | | **Rules** | Plain rules, one per line, such as "never email customers without asking". | Instructions the agent follows once the plan is approved. | | **Access** | **Only you** (default) or **Everyone in your organization**. | Records who the goal is for. It adds no one: use **Settings › Access**. | Changing the goal, role, rules or access needs permission to edit the goal. Connecting tools and changing **On its own** need permission to manage connectors. Goal admins have both. Read more about the three levels in [Approvals and autonomy](/docs/goals/approvals). For **Reaches you**, the agent asks "Where should I reach you?" and offers **Slack** and **Here in Auto Lab**. **Email**, **iMessage** and **Microsoft Teams** appear when they are switched on for the goal. Slack asks you to **Add to Slack** and pick a channel first. See [Channels](/docs/connect/channels). ### Connect the tools it works with Every app or site you name becomes a card in the conversation and a chip on the **Works with** row: | Chip | Card | What to do | |---|---|---| | **connected** | **Connected** | Nothing. The goal already has the app. | | **needs connect** | **Connect** | Choose **Connect** and sign in to the app. Without permission, the card says "Ask an admin to connect …" and may offer **Copy link** to send them. | | **web** | **Ready** | Nothing. It is a public site the agent reads with its own browser. | | **needs sign-in** | **Sign in** | Choose **Sign in**. The agent sends a login link and you type the password there, never in chat. | If a name matches several apps, the card asks "Which one do you use?". To add something you did not mention, choose **Add another tool**, or **Add** or **Manage** on the **Works with** row. See [Connectors](/docs/connect/connectors) and [Website logins and secure links](/docs/connect/website-logins). ## Launch Once the goal is filled in, choose **Draft my first week**. A line above the button says what is still open, such as a connection or a channel. You can skip both: the agent asks again when it needs them. The **First week** opens on the right: usually 5 to 12 tasks, each with a day and an owner (**Agent** or **You**), then **Check-ins**, **Reaches you**, **On its own**, **Tracking**, **Rules** and **Access**. You only get a task for something the agent cannot do itself, such as a login, a connection or a decision you have not given yet. Ask for changes in the conversation, such as "make it daily", and the agent redrafts. **Brief** goes back to the brief, and **See the first week** returns to the plan. When you choose **Launch**, Auto Lab: 1. checks that you can edit the goal, merge changes and run triggers. Otherwise it says "Ask the owner to launch." 2. saves the goal sentence and reads its number again. 3. approves the first week: the tasks appear on the Overview, and the routine and check-ups start, delivering to where the goal reaches you. The first routine run is queued straight away. 4. moves the Delegation dial from **Ask first** to the level you chose under **On its own**. 5. turns on **Escalate what needs you** for your channel, when that channel is linked to the goal. 6. ends setup: the **Set up** row leaves the sidebar and you land on the Overview. ### Before Launch Until you launch: - The goal runs at **Asks before acting** (**Ask first** on the Delegation dial): every connector call waits for your approval, reads included. - Apps connected during setup are read-only to the agent. - There are no tasks and no schedules. The agent's own background jobs, such as its evening recap, start at Launch. **Finish later**, at the top of the setup page, takes you to the Overview. The **Set up** row in the sidebar brings you back, and shows where you stopped, such as "2 of 3". ## Edit the goal later Choose the pencil (**Edit goal**) on the Overview's goal card, or **Edit goal** in **Settings › General**. Setup opens again in edit mode, under **Overview › Edit goal**. Change things in either of two ways: - **Say it**, for example "Make it 15 demos a week, and look for leads on LinkedIn too." The agent rewrites the goal sentence, so the Tracking line follows, and adds any new source as a card. - **Edit the brief**: the goal is a text field, and every other row has its own button, such as **Edit**, **Change** or **Share**. Changes save as you go. When a change affects the plan, the agent shows the difference in the conversation, with tasks marked **New**, **Changed** or **Dropped**. Choose **Update plan** to apply it, or **Keep current plan**. The plan does not change until you choose **Update plan**. If you change the goal but not the plan, the brief says **The plan still follows the old goal.** Choose **Update plan** there and the agent redrafts the week. **Done** returns to the Overview. Plan changes the agent proposes on its own later are covered in [Plans, schedules and triggers](/docs/goals/schedules). ## Set up with the form instead If the agent cannot be reached, setup says "The agent can't be reached right now." and offers **Set up with the form instead**. Older goals that do not run in Chat always use the form. The form asks the same things in steps: **Objective**, **Measure**, **Tools**, **Work**, **Channels**, **Autonomy** and **Plan**. **Finish later** leaves at any step, and the **Set up** row counts the steps, such as "3 of 8". The **Autonomy** step offers **Ask first**, **Within policy** and **Act freely**, then **Continue to plan** drafts the week for you to approve. --- # How Auto Lab works The ideas behind Auto Lab in one page: goals, Chat, task agents, plans, approvals, the Brain and learning. Canonical page: https://app.auto-lab.ai/docs/how-it-works This page explains the parts of Auto Lab and how they fit together. Read it once and the rest of the docs will make sense in any order. ## Organizations and goals Your **organization** holds your goals, the people who work on them and shared settings such as members, roles and single sign-on. You can belong to more than one organization. A **goal** is one outcome you want Auto Lab to work toward, such as "follow up with every new customer in their first two weeks". A goal has: - one **agent** that owns the work, plus task agents it hands pieces to - a **plan** of tasks for the current week - one running conversation, **Chat** - a **Brain**: what its agents know and the rules they follow - the **connectors**, **channels** and **secrets** it may use You can run many goals side by side. The **Goals** home shows every goal you can see, grouped by whether it needs you, is in progress or is paused. ## Everything a goal knows is kept in a repository Each goal has its own private git repository. Auto Lab creates and manages it for you, or you can connect one on GitHub. The goal's instructions, memory, skills, plan and settings are files in that repository. This is why every change to a goal has an author, a date and a history, and why a change can be reviewed before it lands or undone after. You never need to open the repository to use Auto Lab. Developers can clone it; see [The goal's repository](/docs/developers/repository). ## The agent, task agents and runs The goal's agent runs on Auto Lab's servers. It reads messages, keeps the plan up to date, decides what to do next and talks to you. When a piece of work needs focus, it hands that piece to a **task agent** with one job: | Task agent | Does | |---|---| | Research | Answers one question from the web, the goal's memory and its connected apps | | Docs | Drafts or updates one document or message | | Mail reader | Turns an incoming email into a short summary. It has no tools, so it cannot act on what the email says | | Browser | Uses websites, including ones that need a login | | Coder | Changes files in a repository and hands the result back as a change request for review | Each hand-off is a **run**. Runs show up as cards in Chat and on the goal's **Runs** page, where you can follow them, including a live view of the browser. When work needs a real computer, for example to run a script or edit files, the agent starts an isolated cloud machine for it. A Coder task or a scheduled trigger gets a **session**: a machine with its own branch of the goal's repository, whose work ends in a change request. Machines stop when the work is done or has been idle for a while. ## Chat: one conversation per goal **Chat** is the goal's single running thread. Messages from the web app and Slack land in it, and so do Microsoft Teams, iMessage and email when they are switched on for the goal. The agent has the whole story wherever you write from. When it asks you something, you can answer from any of those places, and its reply goes back where you asked. Chat also shows what happened in between: approvals waiting for you, questions, task cards, and short notes such as "Learned: …" with an **Undo** button. ## Plans, tasks and schedules At launch you approve a plan for the first week. Each task is owned by the agent or by you. On the Overview, tasks sit under **In progress**, **Blocked**, **Planned** and **Done this week** as the work happens. Nothing in Auto Lab runs all the time. The agent wakes up when: - a **schedule** fires: the routine, a check-up it set for itself, or a reminder - a message arrives in Chat or a channel - something it is waiting for happens, such as a reply to an email or a request from another app (a webhook) The agent re-plans as it learns more. How much of that it may do without asking depends on the goal's autonomy. See [Plans, schedules and triggers](/docs/goals/schedules). ## Autonomy, approvals and Needs you Each goal has a **Delegation** level, set during setup as **On its own**: | Level | Meaning | |---|---| | Asks before acting | Every action in a connected app, even reading, waits for your approval | | Acts within your rules | Your rules decide. By default, reading runs and anything that writes or deletes asks first | | Acts on its own | Actions run without asking, unless a rule says otherwise or the connector is set to **Ask before every use** | Approvals, reviews, plan changes and tasks assigned to you collect in **Needs you** on the goal's Overview. Questions from the agent wait above the Chat composer. When you are away, both reach you in the channel you picked during setup. When you approve an action, you can also select **Approve and make it a rule** so the same kind of action runs without asking next time. Bigger changes arrive as a **change request**: a proposed set of edits to the goal's repository that you can review, approve or send back. A plan revision, a new skill or a code change can each be a change request. An agent never approves its own. See [Approvals and autonomy](/docs/goals/approvals). ## The Brain and learning The **Brain** is where you see and edit what the goal's agents know: agents, skills, memory, tools, connectors, schedules and more. Each item shows who changed it last and where it is used. The goal learns from its own work. After a stretch of turns, and again overnight, it reviews what happened. Small, safe lessons, such as a preference you stated or a better way to do a task, apply at once and appear in **Brain › Learning** with **Undo**. Larger changes, such as rewriting memory or editing a skill a person wrote, wait for your approval. See [Learning](/docs/brain/learning). ## Keeping credentials safe - Connectors keep their credentials on Auto Lab's servers. The agent asks for an action; the server makes the call. - When the agent needs a website login, it sends you a **login link**. You type the password on that page, never in Chat. See [Website logins and secure links](/docs/connect/website-logins). - Secrets you add can be granted to specific agents only. See [Secrets](/docs/connect/secrets). ## Words used in these docs | Term | Meaning | |---|---| | Organization | The group that holds goals, members and shared settings | | Goal | One outcome Auto Lab works toward, with its own agent, plan, Chat and Brain | | Chat | The goal's one running conversation, shared across web and channels | | Task agent, run | A focused helper the agent hands work to, and one piece of work it did | | Session | An isolated cloud machine with its own branch, used for code changes and scheduled triggers | | Needs you | The list on a goal's Overview of approvals, reviews and tasks waiting on a person | | Change request | A proposed change to the goal's repository that a person reviews | | Brain | Everything the goal's agents know, and its history | | Connector | Access to an outside app or API | | Channel | A place the agent talks to people: Slack, Teams, iMessage or email | --- # Introduction Auto Lab works toward a goal you describe, checks in with you when it needs a decision, and learns from its own work. Canonical page: https://app.auto-lab.ai/docs Auto Lab is an AI coworker for running part of your business. You describe an outcome in a sentence, such as "qualify 20 inbound leads a week". Auto Lab plans the first week with you and does the work across the days that follow. It asks for you only when it needs a decision, a login or an approval. Each outcome is a **goal**. A goal has its own agent, its own plan, one running conversation and a record of everything it knows and has changed. Goals live in your **organization**, next to the people who work on them. ## How a goal runs 1. **Describe.** You write the goal in a sentence or two. 2. **Set up together.** The goal's agent asks only what it still needs: which tools to use, where to reach you, and how much it may do on its own. 3. **Launch.** You approve a plan for the first week. Auto Lab schedules its check-ins and starts. 4. **Work.** The agent works through the plan, hands research, writing, browsing and code to task agents, and posts progress in the goal's Chat and in the channel you picked. 5. **Needs you.** Approvals, reviews and your own tasks collect in one list on the goal's Overview, and the agent's questions wait above the Chat composer. When you are away, they reach you in the channel you picked. 6. **Learn.** After its work, the agent notes what went well and what went wrong. Small lessons apply right away and can be undone. Bigger changes wait for your approval. ## Where to start - [Quickstart](/docs/quickstart): Sign in, describe your first goal and launch its first week. - [How Auto Lab works](/docs/how-it-works): The ideas behind goals, Chat, the Brain and approvals, in one page. ## Guides - [Working with goals](/docs/goals): Set up, follow and steer a goal from its Overview and Chat. - [What's in the Brain](/docs/brain): What the goal's agents know, and how that changes over time. - [Connecting tools](/docs/connect): Connectors, channels, website logins and secrets. - [Organizations and members](/docs/organization): People, roles, access and usage. - [Developers](/docs/developers/cli): The CLI, the goal's repository, the manifest, MCP and the API. > **Asking for help** > > Email [hello@auto-lab.ai](mailto:hello@auto-lab.ai) with what you expected and what happened. Include the > goal's name and a link to the page you were on. --- # Roles and access Who can see and change what in your organization and its goals, and how to grant, narrow and take back access. Canonical page: https://app.auto-lab.ai/docs/organization/access Access works at two levels: the organization, and each goal inside it. This page explains the roles at each level, how to give someone a goal, how agents are shared, and which keys can act for you. ## How access works Every grant has the same shape: - **Who.** A person, a group, an agent, or an email address that has not joined yet. - **A role.** A named set of permissions. - **Where.** The whole organization, one goal, or one agent inside a goal. - **Until when.** Optional. The grant ends on its own at that time. Three rules follow from it. - Roles only add. No role takes a permission away, so a group never removes what a person already has. Remove someone's direct grant and they keep whatever their groups still give them. - Owners and admins of the organization are admins on every goal. A goal grant cannot lower that. To limit what someone reaches goal by goal, make them a member of the organization first. - A grant that names one agent narrows who may use that agent. It never adds permissions of its own. ## Organization roles Each person holds one role in the organization. The role picker shows the names in the second column. | Role | Shown as | Can | |---|---|---| | Owner | **Account owner** | Everything, including deleting the organization and transferring ownership. Admin on every goal. | | Admin | **Account admin** | Everything an owner can do except delete the organization or transfer ownership: invite and remove people, manage groups, roles and API keys, create goals. Admin on every goal. | | Member | **Account member** | See the goals they are added to, directly or through a group, and use only the agents granted there. Cannot create goals in this organization. | To change someone's role, open **Organization settings › Members**, open the person and choose **Edit access**. To change several people at once, tick their rows and choose **Change role**. ## Goal roles Inside a goal, a person is either an admin or a member. | Role | Shown as | Can | |---|---|---| | Admin | **Project admin** | Everything in the goal: Chat, the Brain (agents, skills, memory, connectors, secrets, triggers and schedules), settings, who has access, and deleting the goal. | | Member | **Project member** | Open the goal and follow its work: Overview, Chat, Activity and Learning. Start and stop sessions with the agents granted to them. No changes to the Brain, settings or access. | > **Who can talk to the agent** > > Sending messages in a goal's Chat and answering the agent's questions need the admin role on that goal. Give > **Project admin** to anyone who should work with the agent day to day. ## Give someone access to a goal You need the admin role on the goal, or the owner or admin role in the organization. ### Open the goal's access In the goal, open **Settings › Access** and choose **Grant access**. ### Pick who Under **Grant to**, pick people or groups from the organization, or type an email address to invite someone new. Everyone you select gets the same role. ### Pick the role and agents Choose the **Role**, then which **Agents** they may use: **All agents** or **Only these…**. ### Set an end date if you want one Fill in **Expires** to make the access temporary. Leave it empty to keep it until you remove it. People invited by email wait under **Invited to this project** until they join. To change or end someone's access later, open their row and choose **Edit access** or **Remove access**. **Organization settings › Projects** shows the same list for every goal in one place. Someone who opens a link to a goal they cannot reach sees **Ask for access.** and can send a note with **Request access**. The request appears under **Asked to join** in the goal's **Settings › Access**, where any admin of the goal can **Approve** or **Decline** it. While you set up a goal, the goal brief also shows an **Access** line: **Only you** or **Everyone in your organization**. It records who the goal is meant for. It does not add anyone by itself, so grant access here. ## Agents are closed by default A goal member can use an agent only when a grant names them or one of their groups. With no grant, they can use none of the goal's agents. - **All agents** grants each agent the goal has at that moment. When the goal gets a new agent later, grant it to the members who need it. - Once an agent has any grant, only the people and groups it names can use it, goal admins included. Owners and admins of the organization are never limited this way. - Whoever can use an agent can also use the secrets and connectors it declares, but cannot edit them. ## Groups A group lets you grant access once instead of person by person. Attach a group to a goal with a role, and every member of the group gets that role on that goal. Pick the group under **Grant to** like a person. Groups live in **Organization settings › Groups**. Creating them is an enterprise feature. With SCIM, your identity provider can keep groups and their members in sync, including when someone leaves. ## Enterprise features If your organization has them, owners and admins also get: | Feature | Where | What it does | |---|---|---| | Custom roles | **Organization settings › Roles › New role** | A role with exactly the permissions you pick. Assign it like a built-in role, on a person or a group, across the organization or on one goal. It only adds permissions; there is no deny. | | Single sign-on and SCIM | **Organization settings › Identity** | Sign-in through Okta, Microsoft Entra ID or another SAML identity provider, with members created at first sign-in. SCIM keeps people and groups in sync. | | Audit log | **Organization settings › Audit log** | Every admin and agent action: who, what, where and when. Filter it, export it as CSV or JSONL, or stream it out through webhooks. | | Branding | **Organization settings › Branding** | Your logo, icon, favicon and product name for everyone in the organization. | Without them, those panes explain the feature and offer **Request a demo**. The built-in roles always work. ## Require two-factor authentication In **Organization settings › Settings**, owners and admins can turn on **Require two-factor authentication**. Members without a verified second factor are then blocked from protected actions until they add one in **Personal settings › Security**. API keys are not affected. The same section sets how long someone stays signed in, and when an idle sign-in ends. ## What an agent may do on its own A running agent passes two checks: the roles of the identity it runs as, and the permissions the goal manifest (`kortix.yaml`) grants that agent under `agents..kortix_cli`. It can only do what both allow, and neither widens the other. An agent whose manifest lists an action still cannot do it without the role, and an agent started by an owner still cannot do what its manifest leaves out. See [Goal manifest](/docs/developers/manifest). ## Access keys Two kinds of key let a program act in Auto Lab. | Key | Where | Acts as | Use it for | |---|---|---|---| | Personal access key | **Personal settings › Personal access keys** | You, with your roles and groups | The CLI, a script or a CI job that works as you | | Service account token | **Organization settings › API keys** | Its own identity, with only the access you grant it | CI jobs and integrations that should keep working after the person who made them leaves | - A personal access key belongs to one organization, and you can limit it to one goal. Creating one needs the owner or admin role in that organization. It stops working if you leave the organization. - A key is shown once, when you create it. Copy it then; a lost key has to be replaced. - Under **Key rules** in **Organization settings › API keys**, owners and admins can require an end date, cap how long a key may last and turn off keys nobody has used for a set number of days. See [CLI](/docs/developers/cli) for signing the CLI in, and [API and sign-in](/docs/developers/api) for apps that sign people in with Auto Lab. Auto Lab's own platform admins handle sign-ups, invitations and suspensions from a separate console, outside your organization's roles. --- # Organizations and members What an organization is, how people sign in and join, and where organization and personal settings live. Canonical page: https://app.auto-lab.ai/docs/organization Your organization is the level above your goals. It holds the goals, the people who work on them and the settings they share. This page covers signing in, inviting people and finding your way around both kinds of settings. ## What an organization holds - **Goals.** Every goal belongs to one organization. - **People.** Each member has an organization role, and a role on each goal they work on. See [Roles and access](/docs/organization/access). - **Shared settings.** The organization's name and sign-in rules, its GitHub connection, its API keys and, if your organization has them, single sign-on and branding. The first time you sign in, Auto Lab creates an organization of your own, named after your email address. If it has no goals yet, Auto Lab creates a first one and opens its setup. You can rename the organization in **Organization settings › Settings**. An organization becomes a team when more people join it. Only owners and admins of an organization can create goals in it. You can belong to several organizations at once. ## Sign in ### Enter your email Open Auto Lab, type your email address and choose **Continue**. There is no separate sign-up: a new address gets an Auto Lab account automatically. ### Enter the code Auto Lab emails you an 8-digit code. Type or paste it on the **Check your email** screen. If it does not arrive, choose **Resend** once the timer runs out. Other ways in: - **Use a password instead** on the code screen. **Forgot your password?** sends a reset link. - **Continue with Google**, when Google sign-in is switched on. - **Use single sign-on (SSO)**, if your organization signs in through its identity provider. If your email domain requires it, **Continue** takes you straight there. Auto Lab can run invite-only. Then an address without an invitation sees **Auto Lab is invite-only** and a short form: email, company and what you hope to automate. Choose **Request access** and the Auto Lab team replies by email when there is a spot. ## Accept an invitation Invitations come in two kinds. | Invitation | What you see | What happens | |---|---|---| | To Auto Lab itself | An email titled "You're invited to Auto Lab", or "Set up Acme on Auto Lab" for a team called Acme | **Accept invitation** opens sign-in with your address filled in. Sign in with the emailed code. | | To a colleague's organization | An email with a link to the invitation | Open the link and choose **Accept** or **Decline**. Signing in with the invited address also adds you. | A team invitation carries a number of seats. The first person to accept sets the team up: their organization takes the team's name and seats, and they can invite colleagues from there. Invitations to Auto Lab expire after 14 days. If you are signed in with a different address from the one invited, the page says whose invitation it is. Sign out and sign back in with the invited address. If a link has expired or was withdrawn, ask the person who invited you for a new one. ## Invite teammates Owners and admins can invite people. ### Open Members Open **Organization settings › Members** and choose **Invite**. ### Pick people and a role Type an email address to invite someone new, or pick people who are already in the organization. Everyone you select gets the same role. ### Send Each person gets an email with a link. Open invitations wait under **Invited**, with the date each one expires. Use the menu on a row to **Resend invite**, **Copy invite link** or **Cancel invite**. If Auto Lab set your team up with a number of seats, each person uses one. When they are all taken, the invite is refused with "Your team has used all its seats. Ask Auto Lab for more." Write to hello@auto-lab.ai for more. To bring someone into one goal only, grant them access from that goal instead. See [Give someone access to a goal](/docs/organization/access#give-someone-access-to-a-goal). ## Switch organizations - **In a goal:** open the goal switcher at the top of the rail and choose **Switch goal**. With more than one organization, the list groups goals under each organization's name. Picking a goal in another organization moves you there. - **On the Goals home:** the menu at the top left scopes the page to **All accounts** or to one organization. - **In Personal settings › Profile:** **Organizations** lists each one with your role. **Manage** opens its settings. ## Organization settings Open the goal switcher, choose **Switch goal**, then **Organization settings**. Owners and admins see every section; members see only the ones their role can use. | Section | What it holds | |---|---| | **Settings** | The organization's name, its two-factor and sign-in rules, and deleting the organization (owner only). | | **Branding** | Your logo, icon, favicon and product name for everyone in the organization. An enterprise feature. | | **Git** | The GitHub connection your goals use to create or import repositories. | | **API keys** | Service account tokens for CI and automations, apps that sign people in with Auto Lab, and key rules. | | **Members** | Everyone in the organization, their roles, and open invitations. | | **Groups** | Sets of people you grant access to together. | | **Projects** | Every goal's access in one list. Pick a goal to see who is in it. | | **Roles** | The built-in roles and, if your organization has them, custom roles. | | **Identity** | Single sign-on and SCIM provisioning from your identity provider. An enterprise feature. | | **Audit log** | Who did what, where and when. An enterprise feature. | | **Help** | A short explanation of how access works. | | **Usage** | What each goal and session cost. See [Usage and limits](/docs/organization/usage). | Enterprise features show an explanation and **Request a demo** until Auto Lab switches them on for your organization. ## Personal settings Personal settings belong to you, not to an organization. Open the goal switcher and choose **Settings**, or press ⌘, on a Mac or Ctrl+, elsewhere. | Section | What it holds | |---|---| | **Profile** | Your picture, name and email, and the organizations you belong to. | | **Security** | Two-factor authentication with an authenticator app, and signing out your other devices. | | **Chat identities** | The Slack, Teams and iMessage identities you linked, so a goal knows who is writing. See [Channels](/docs/connect/channels). | | **Connectors** | Your own connections to a goal's apps. See [Connectors](/docs/connect/connectors). | | **MCP** | Connect an AI client to your goals. See [MCP](/docs/developers/mcp). | | **Secrets** | Your own values for a goal's secrets, which override the shared ones for you. See [Secrets](/docs/connect/secrets). | | **Appearance** | Theme, wallpaper and how much detail a conversation shows. | | **Notifications** | Browser notifications for finished work, errors, questions and permission requests. | | **Language & shortcuts** | The app's language and keyboard shortcuts. | | **Personal access keys** | Keys that act as you, for the CLI, a script or a CI job. See [Access keys](/docs/organization/access#access-keys). | ## When access ends An owner or admin can remove a member from **Organization settings › Members**. The person loses that organization's goals, and their personal access keys for it stop working. Their other organizations are not affected. The Auto Lab team can also end access, for example when a pilot finishes. The person then sees "Your access to Auto Lab has ended", with **Talk to us** and **Sign out**. When a whole organization's access ends, its agents and API keys stop working too. Nothing is deleted: goals and data stay as they were, and access can be restored. --- # Usage and limits Where to see what your goals cost, the daily limits each goal runs under, and how to keep usage down. Canonical page: https://app.auto-lab.ai/docs/organization/usage Auto Lab has no plans, credits or top-ups: billing is off. It still records what each goal's work costs, and each goal has daily limits on how much automated work it may start. This page shows where to find both. Auto Lab supplies the models a goal uses, so a new goal needs no provider key. If you add your own key in **Brain › Models** for a provider Auto Lab does not supply, that provider bills you for those calls. See [Models](/docs/brain/models). ## See what your organization used Owners and admins open **Organization settings › Usage**. The **Session costs** tab shows: - **A date range.** **Last 24 hours**, **Last 7 days**, **Last 30 days** (the default), **Last 90 days**, or dates you pick. - **Totals.** **Total**, **LLM** for model calls and **Compute** for sandbox time, each with its change from the previous period. A sandbox is the isolated cloud machine a session or task agent works on. - **Cost per goal.** Open a goal to list its sessions, filter them by **Owner**, then open one to see its model usage, compute time and each cost entry. **Export CSV** downloads the list you are looking at. Ignore the **Credit ledger** tab while billing is off. ## See what one goal used Inside a goal, costs show up next to the work that caused them. | Where | What it shows | |---|---| | **Activity** | Chat turns, schedule fires and task agent runs with their tokens, cost and sandbox minutes, for example "1.2k tok · $0.002 · 3.2 box-min", where **box-min** is sandbox minutes. | | **Runs** | **Tokens** and **Cost** for each task agent run. Open a run to see its sandbox minutes too. | | **Brain › Models › Costs** | The goal's model spend over time, when your goal has this tab. **Set budget** caps spend for a period, and you choose whether reaching it blocks new model requests or only warns. | ## Daily limits for each goal Every goal has two limits in **Settings › Autonomy**, on the **Automation** card. They count from midnight UTC and reset there. A session here is the isolated cloud machine a piece of work runs on. | Setting | Default | What it counts | |---|---|---| | **Sandbox minutes per day** | 120 | Minutes the goal's sandboxes ran today, start-up included | | **New sessions per day** | 20 | Sessions the goal started today. Reusing a session it already has does not count. | The line under the fields shows today's use. To change a limit, type the new number and choose **Save limits**. You need the admin role on the goal. Minutes go from 1 to 14,400 and sessions from 1 to 1,000. ### What happens at a limit When a goal reaches a limit, it stops starting new work for the rest of the day. - **Triggers.** A scheduled trigger is skipped, and firing one by hand is refused. At the session limit, only triggers that would start a new session are affected. - **Chat and its schedules.** The agent still replies and check-ins still run. When the agent needs a new sandbox, or a task agent needs its own, it is told that the daily budget is used up and nothing starts. - **Running work.** Work that is already running finishes as usual and stops when it goes idle. At the session limit, the goal can still reuse sessions it already has. The **Goals** home marks the goal "Stopped for today", and the **Automation** card says which limit was reached. Raise the limit if the work should go on today, or wait for the reset at midnight UTC. ## Keep usage down - **Write a clear goal and rules.** A precise objective and a few rules at setup mean fewer questions and fewer retries. See [Set up and launch a goal](/docs/goals/setup). - **Stay in the goal's Chat.** The agent already has the history there, so you do not pay to explain the same background twice. See [Chat and runs](/docs/goals/chat). - **Check in only as often as things change.** Every check-up and routine is a turn that costs something. See [Plans, schedules and triggers](/docs/goals/schedules). - **Use a smaller model for simple work.** Where **Brain › Models** lets you choose the goal's default model, pick a smaller one for routine goals and keep the largest models for work that needs them. - **Start new goals with low limits.** Lower **Sandbox minutes per day** while you try a goal out, then raise it. - **Look at Usage now and then.** Sort by cost and start with the goals and sessions that cost the most. ## Questions Write to hello@auto-lab.ai with questions about usage or limits, or if a number looks wrong. --- # Quickstart Sign in, describe your first goal, set it up with its agent and launch the first week. Canonical page: https://app.auto-lab.ai/docs/quickstart This page takes you from signing in to a goal that is running on its own. Setup takes about two minutes of conversation, plus the time it takes to connect the tools the goal needs. ### Sign in Open [app.auto-lab.ai](https://app.auto-lab.ai) and enter your work email. Auto Lab emails you a code; type it in to sign in. If you prefer a password, choose **Use a password instead**. If you were invited, use **Accept invitation** in the email instead. It signs you in to the right organization. If sign-up is closed, Auto Lab shows a short form to request access. ### Describe the goal Choose **New goal**. Auto Lab asks: **What should Auto Lab work toward?** Write the outcome in a sentence or two. Name a number and a period when you have one, because the agent tracks progress against it. For example: - "Qualify 20 inbound leads a week from our website form and hand the good ones to sales." - "Send me a brief on our competitors every Monday: launches, pricing changes and hiring." Attach a doc or spec if you already have one. Auto Lab suggests a name for the goal; select **Rename** to change it. Then select **Start**. If Auto Lab has already created a first goal for you, it opens straight into setup. Type your goal as the first message there. ### Set up together The goal's agent reads what you wrote and asks only what is missing. As you answer, the **Goal brief** on the right fills in: - **Works with**: the apps and data the goal uses. Select **Connect** on a card to sign in to that app now, or skip it and connect later. - **Reaches you**: where the agent sends updates and questions, such as Slack or **Here in Auto Lab**. - **On its own**: how much it may do without asking. The brief suggests **Acts within your rules**; choose **Asks before acting** if you want to approve every action at first. - **Rules**: anything it must never do, one rule per line. You can edit any field on the brief directly instead of answering in the conversation. To bring teammates into the goal, add them under **Settings › Access** after launch; see [Roles and access](/docs/organization/access). ### Launch the first week Select **Draft my first week**. The agent turns the conversation into a plan: tasks owned by the agent or by you, the times it checks in, and what it tracks. Ask for changes in the conversation until the plan looks right, then select **Launch**. Auto Lab approves the plan, schedules the check-ins and opens the goal's Overview. The agent starts on the first task. ## After launch - **Overview** shows progress, the week's work and a **Needs you** list. Check it once a day, or let the channel you picked bring items to you. - **Chat** is the goal's one running conversation. Ask questions, change direction or hand it a new task. - **Brain › Learning** shows what the goal has learned. You can undo anything it applied on its own. You can edit the goal or re-plan it from the Overview at any time. To hold scheduled work, see [Pause a goal](/docs/goals#pause-a-goal). ## Next steps - [How Auto Lab works](/docs/how-it-works): Goals, Chat, task agents, the Brain and approvals. - [Set up and launch a goal](/docs/goals/setup): Every setup field, and how to edit a goal later. - [Overview, Needs you and Activity](/docs/goals/overview): What to check, and what each kind of request means. - [Connectors](/docs/connect/connectors): Give the goal access to the apps it works with.