The docs describe g1t as the place your coding agents work, not as an agent of its own. The guides to g1t's hosted agents are gone: agents, their abilities, access, budgets, memory, routines, sessions and skills, talking to agents, working with g1t, Customize, model providers, the AI Gateway, the context hub, spend, plans and the chat app's agent pages. Each old address redirects to the page that now covers what is left of it.
"Connect a coding agent" (bring-your-own-agent) is the hub for any harness you bring: connecting over MCP with OAuth or an access token, what scopes to give it, working an issue into a pull request, recording its session on the pull request, memory, overlaps, and starting it from webhooks, workflows or notifications. The MCP reference lists the 18 tools that remain. Memory has a page of its own, written for recall and remember from your agent, with no automatic capture. Chat, billing, people and teams, runners, guardrails, rules, authentication, pull requests, webhooks and the other guides no longer mention hosted agents, @g1t mentions, model meters or agent tokens; the sidebar has a Coding agents tab. The privacy policy and subprocessor list no longer name Anthropic as a model provider or the AI Gateway, since g1t sends nothing to a model on anyone's behalf now.
82 files+827−622118 files not counted0/82 viewed
| 11 | 11 | site: 'https://docs.g1t.sh', | |
| 12 | 12 | // Pages that moved, so links already shared still arrive. | |
| 13 | 13 | redirects: { | |
| 14 | − | '/guides/g1t-agents/': '/guides/working-with-g1t/', | |
| 15 | 14 | '/guides/inbox/': '/guides/notifications/', | |
| 16 | − | '/guides/marketplace/': '/guides/customize/', | |
| 17 | 15 | '/guides/today/': '/guides/home/', | |
| 16 | + | // g1t no longer runs agents of its own: coding agents connect to it. | |
| 17 | + | '/guides/g1t-agents/': '/guides/bring-your-own-agent/', | |
| 18 | + | '/guides/working-with-g1t/': '/guides/bring-your-own-agent/', | |
| 19 | + | '/guides/agents/': '/guides/bring-your-own-agent/', | |
| 20 | + | '/guides/agent-abilities/': '/guides/bring-your-own-agent/', | |
| 21 | + | '/guides/agent-access/': '/guides/bring-your-own-agent/', | |
| 22 | + | '/guides/agent-memory/': '/guides/memory/', | |
| 23 | + | '/guides/agent-routines/': '/guides/bring-your-own-agent/', | |
| 24 | + | '/guides/agent-sessions/': '/guides/why-blame/', | |
| 25 | + | '/guides/agent-skills/': '/guides/bring-your-own-agent/', | |
| 26 | + | '/guides/agent-budgets/': '/guides/usage-and-billing/', | |
| 27 | + | '/guides/agents-and-memory/': '/guides/memory/', | |
| 28 | + | '/guides/talking-to-agents/': '/guides/bring-your-own-agent/', | |
| 29 | + | '/guides/chat-app/': '/guides/chat/', | |
| 30 | + | '/guides/customize/': '/guides/bring-your-own-agent/', | |
| 31 | + | '/guides/marketplace/': '/guides/bring-your-own-agent/', | |
| 32 | + | '/guides/models/': '/guides/integrations/', | |
| 33 | + | '/guides/ai-gateway/': '/guides/integrations/', | |
| 34 | + | '/guides/context-hub/': '/guides/memory/', | |
| 35 | + | '/guides/spend/': '/guides/usage-and-billing/', | |
| 36 | + | '/guides/outcomes/': '/guides/milestones/', | |
| 18 | 37 | }, | |
| 19 | 38 | integrations: [ | |
| 20 | 39 | starlight({ | |
| 21 | 40 | title: 'g1t docs', | |
| 22 | − | description: 'Guides and reference for g1t, the workspace where a team and its agents talk, work and ship.', | |
| 41 | + | description: 'Guides and reference for g1t, where a team and its coding agents talk, build and ship.', | |
| 23 | 42 | components: { | |
| 24 | 43 | Footer: './src/components/Footer.astro', | |
| 25 | 44 | Head: './src/components/Head.astro', | |
| ⋯ | |||
| 89 | 108 | ], | |
| 90 | 109 | }, | |
| 91 | 110 | { | |
| 92 | − | label: 'Chat and agents', | |
| 111 | + | label: 'Chat', | |
| 93 | 112 | items: [ | |
| 94 | 113 | { label: 'Chat', slug: 'guides/chat' }, | |
| 95 | − | { label: 'Agents', slug: 'guides/agents' }, | |
| 96 | − | { label: 'Sessions', slug: 'guides/agent-sessions' }, | |
| 97 | − | { label: 'Skills', slug: 'guides/agent-skills' }, | |
| 98 | − | { label: 'Abilities', slug: 'guides/agent-abilities' }, | |
| 99 | − | { label: 'Agent memory', slug: 'guides/agent-memory' }, | |
| 100 | − | { label: 'Routines', slug: 'guides/agent-routines' }, | |
| 101 | − | { label: 'Spend', slug: 'guides/spend' }, | |
| 102 | − | { label: 'Agent budgets and spend', slug: 'guides/agent-budgets' }, | |
| 103 | − | { label: 'What agents can do for whom', slug: 'guides/agent-access' }, | |
| 104 | 114 | { label: 'Artifacts', slug: 'guides/artifacts' }, | |
| 105 | − | { label: 'Agents in your chat app', slug: 'guides/chat-app', badge: { text: 'Soon', variant: 'default' } }, | |
| 106 | 115 | ], | |
| 107 | 116 | }, | |
| 108 | 117 | { | |
| ⋯ | |||
| 138 | 147 | ], | |
| 139 | 148 | }, | |
| 140 | 149 | { | |
| 141 | − | label: 'Agents on code', | |
| 150 | + | label: 'Coding agents', | |
| 142 | 151 | items: [ | |
| 143 | − | { label: "g1t's agent", slug: 'guides/working-with-g1t' }, | |
| 144 | − | { label: 'Guardrails', slug: 'guides/guardrails' }, | |
| 145 | − | { label: 'Outcomes and plans', slug: 'guides/outcomes' }, | |
| 146 | − | { label: 'Talking to agents', slug: 'guides/talking-to-agents' }, | |
| 147 | − | { label: 'Agents, sessions and memory', slug: 'guides/agents-and-memory' }, | |
| 148 | − | { label: 'Context hub', slug: 'guides/context-hub' }, | |
| 149 | − | { label: 'Bring your own agent', slug: 'guides/bring-your-own-agent' }, | |
| 152 | + | { label: 'Connect a coding agent', slug: 'guides/bring-your-own-agent' }, | |
| 153 | + | { label: 'Sessions and why-blame', slug: 'guides/why-blame' }, | |
| 154 | + | { label: 'Memory', slug: 'guides/memory' }, | |
| 150 | 155 | ], | |
| 151 | 156 | }, | |
| 152 | 157 | { | |
| 153 | 158 | label: 'Connect your tools', | |
| 154 | 159 | items: [ | |
| 155 | − | { label: 'Customize', slug: 'guides/customize' }, | |
| 156 | 160 | { label: 'Integrations', slug: 'guides/integrations' }, | |
| 157 | − | { label: 'Model providers', slug: 'guides/models' }, | |
| 158 | − | { label: 'AI Gateway', slug: 'guides/ai-gateway' }, | |
| 159 | 161 | { label: 'Webhooks', slug: 'guides/webhooks' }, | |
| 160 | 162 | { label: 'GitHub Actions', slug: 'guides/actions' }, | |
| 161 | 163 | { label: 'Self-hosted runners', slug: 'guides/self-hosted-runners' }, | |
| 164 | + | { label: 'Guardrails', slug: 'guides/guardrails' }, | |
| 162 | 165 | ], | |
| 163 | 166 | }, | |
| 164 | 167 | { | |
| ⋯ | |||
| 172 | 175 | { label: 'The merge queue', slug: 'guides/merge-queue' }, | |
| 173 | 176 | { label: 'Rules', slug: 'guides/rules' }, | |
| 174 | 177 | { label: 'CODEOWNERS', slug: 'guides/codeowners' }, | |
| 175 | − | { label: 'Sessions and why-blame', slug: 'guides/why-blame' }, | |
| 176 | 178 | { label: 'Forks and branches', slug: 'concepts/forks' }, | |
| 177 | 179 | ], | |
| 178 | 180 | }, | |
| 27 | 27 | const STATUS = { | |
| 28 | 28 | 401: ['unauthenticated', 'A token is required, or the one sent is not valid.'], | |
| 29 | 29 | 402: ['payment_required', 'The workspace cannot start this work: it needs the g1t plan or a card check, or it is at a limit. See [usage and billing](/guides/usage-and-billing/#when-work-is-stopped).'], | |
| 30 | − | 403: ['forbidden', 'The token is valid but not allowed to do this, such as a member-only change or an agent token outside its repository.'], | |
| 30 | + | 403: ['forbidden', 'The token is valid but not allowed to do this, such as a member-only change, or a token without the scope it needs.'], | |
| 31 | 31 | 404: ['not_found', 'It does not exist, or you cannot see it.'], | |
| 32 | 32 | 409: ['conflict', 'The request conflicts with the current state.'], | |
| 33 | 33 | 422: ['invalid', 'The input is not valid. `message` says which field and why.'], |
| 135 | 135 | You can't fork a repository into your own workspace. On g1t, a fork is a | |
| 136 | 136 | pull request's own working copy, made when the pull request is opened. | |
| 137 | 137 | ||
| 138 | − | - **Why.** We built forks to isolate agents' work, one per pull request. | |
| 138 | + | - **Why.** We built forks to isolate each pull request's work, so many | |
| 139 | + | people and agents can work at once. | |
| 139 | 140 | See [Forks and branches](/concepts/forks/). | |
| 140 | 141 | - **Instead.** To contribute, open a pull request: it gets its own fork. To | |
| 141 | 142 | start a copy of your own, clone the repository and push it to a new one | |
| ⋯ | |||
| 178 | 179 | ||
| 179 | 180 | You can't resolve a merge conflict on the pull request's page. | |
| 180 | 181 | ||
| 181 | − | - **Instead.** Ask g1t to resolve it, or fix it on the command line. | |
| 182 | + | - **Instead.** Fix it on the command line. | |
| 182 | 183 | See [Conflicts](/guides/pull-requests/#conflicts). | |
| 183 | 184 | - **Status.** Planned. | |
| 184 | 185 | ||
| ⋯ | |||
| 452 | 453 | ### Payments are in test mode | |
| 453 | 454 | ||
| 454 | 455 | While payments are in test mode, no real card is charged, so a card check | |
| 455 | − | proves nothing. g1t's hosted models are open only to a few invited | |
| 456 | − | workspaces, g1t's own among them. Every other workspace, trial or not, | |
| 457 | − | runs its agents on its own model provider; without one, assigning an agent | |
| 458 | − | is refused with a message that says so. | |
| 459 | − | ||
| 460 | − | - **Instead.** Connect your own [model provider](/guides/models/). Your | |
| 461 | − | agents then run on your keys, and the provider bills you directly. | |
| 462 | − | - **Status.** Planned: hosted models for every workspace once payments go | |
| 463 | − | live. | |
| 464 | − | ||
| 465 | − | ## Agents | |
| 466 | − | ||
| 467 | − | ### Confidence is a judgement, not a guarantee | |
| 468 | − | ||
| 469 | − | The confidence g1t gives an agent's change, high, medium or low, is | |
| 470 | − | worked out from what g1t can observe: checks, reviews, revisions, the size | |
| 471 | − | and reach of the change. It cannot tell whether the change is correct. | |
| 472 | − | ||
| 473 | − | - **Instead.** Keep **Ask a person before merging low-confidence changes** | |
| 474 | − | on, and make your workflows required checks. A high rating on a | |
| 475 | − | repository with weak tests means less. See | |
| 476 | − | [How sure the agent is](/guides/working-with-g1t/#how-sure-the-agent-is). | |
| 477 | − | - **Status.** The signals and their weights may change as we learn from | |
| 478 | − | real changes. | |
| 479 | − | ||
| 480 | − | ### Agents' model calls go through g1t | |
| 481 | − | ||
| 482 | − | An agent's model requests always pass through g1t's model proxy, | |
| 483 | − | `models.g1t.sh`, with your keys or g1t's. You can't point an agent's sandbox | |
| 484 | − | straight at a provider. | |
| 456 | + | proves nothing. **Status.** Live payments are planned. | |
| 485 | 457 | ||
| 486 | − | - **Why.** So that no key is ever inside a sandbox, and so budgets, caps and | |
| 487 | − | the audit log hold. See [Your keys never reach a sandbox](/guides/models/#your-keys-never-reach-a-sandbox). | |
| 488 | − | - **Status.** Not planned. This is by design. | |
| 489 | − | ||
| 490 | 458 | ## Accounts, status and self-hosting | |
| 491 | 459 | ||
| 492 | 460 | ### Sign-up needs an invite | |
| ⋯ | |||
| 516 | 484 | ### Self-hosting is early | |
| 517 | 485 | ||
| 518 | 486 | [Running g1t yourself](/guides/self-hosting/) gives you the core forge: | |
| 519 | − | accounts, repositories over HTTP, issues and pull requests. g1t's agent, | |
| 520 | − | Actions, deployments, git over SSH, the REST API and MCP are off, and it is | |
| 487 | + | accounts, repositories over HTTP, issues and pull requests. Actions, | |
| 488 | + | deployments, git over SSH, the REST API and MCP are off, and it is | |
| 521 | 489 | not ready for the open internet. **Status.** Planned, in phases. | |
| 522 | 490 | ||
| 523 | 491 | ### Not built yet | |
| 3 | 3 | description: Why a pull request on g1t gets its own fork, when a branch is the better choice, and what each costs. | |
| 4 | 4 | --- | |
| 5 | 5 | ||
| 6 | − | A pull request can come from a branch of the repository. But an agent's | |
| 7 | − | pull request comes from a **fork**: a separate | |
| 6 | + | A pull request can come from a branch of the repository. But a coding | |
| 7 | + | agent's pull request comes from a **fork**: a separate | |
| 8 | 8 | repository that starts as a copy of yours. This page explains why, what it | |
| 9 | 9 | costs, and when to use which. | |
| 10 | 10 | ||
| ⋯ | |||
| 12 | 12 | ||
| 13 | 13 | | | Fork per pull request | Branch in the repository | | |
| 14 | 14 | | --- | --- | --- | | |
| 15 | − | | Built for | Agents, in any number | A person, or a few | | |
| 15 | + | | Built for | Coding agents, in any number | A person, or a few | | |
| 16 | 16 | | What the worker can write to | Its own fork, nothing else | The repository | | |
| 17 | 17 | | Effect on the repository | None until something merges | A new ref for every piece of work | | |
| 18 | 18 | | Sees `main` move | Only when it pulls | On the next fetch | | |
| 3 | 3 | description: How Code works on g1t, and how issues, pull requests, checks, review, merging and sessions fit together. | |
| 4 | 4 | --- | |
| 5 | 5 | ||
| 6 | − | g1t is one workspace where a team and its agents talk, work and ship. | |
| 7 | − | Most work starts in [Chat](/guides/chat/): you ask a teammate or an | |
| 8 | − | [agent](/guides/agents/), in a channel or a DM. This page is about | |
| 9 | − | **Code**, where changes are made and landed. | |
| 6 | + | g1t is where a team's code, conversations and shipping live. A workspace | |
| 7 | + | holds your repositories, with issues, pull requests, required checks and | |
| 8 | + | the merge queue; [Actions](/guides/actions/) that run your workflows; | |
| 9 | + | [Deployments](/guides/deployments/) that put every pull request live; | |
| 10 | + | and [Chat](/guides/chat/) and [Artifacts](/guides/artifacts/) for your | |
| 11 | + | team. This page is about **Code**, where changes are made and landed. | |
| 10 | 12 | ||
| 11 | − | In Code, you hand g1t an issue or a whole outcome, and agents converge it | |
| 12 | − | onto `main`: each change is made in a pull request of its own, checked by | |
| 13 | − | your workflows, reviewed, revised and merged under your repository's rules. | |
| 14 | − | People work alongside the agents in the same repositories, issues, pull | |
| 15 | − | requests and reviews, and every change can deploy to the edge. | |
| 13 | + | The coding agents you already use, such as Claude Code, Codex, Cursor or | |
| 14 | + | OpenCode, work on g1t from wherever they run. They connect over | |
| 15 | + | [MCP](/guides/bring-your-own-agent/), the [REST API](/reference/api/) and | |
| 16 | + | [webhooks](/guides/webhooks/), act as the person who connected them, and | |
| 17 | + | go through the same pull requests, checks, reviews and rules as everyone | |
| 18 | + | else. | |
| 16 | 19 | ||
| 17 | 20 | Underneath it is ordinary git: repositories, commits, branches, clone, push | |
| 18 | 21 | and pull all work as they do anywhere. On top of that it has the two things | |
| 19 | 22 | you already know, **issues** and **pull requests**, built | |
| 20 | − | so that many agents can work at once without getting in each other's way. | |
| 23 | + | so that many people and agents can work at once without getting in each | |
| 24 | + | other's way. | |
| 21 | 25 | ||
| 22 | 26 | | | What it is | | |
| 23 | 27 | | --- | --- | | |
| 24 | − | | **Plan** | An outcome, split by an agent into issues and the order they land in. See [hand off an outcome](/guides/outcomes/). | | |
| 25 | 28 | | **Issue** | What should change: a bug, a feature, a question. | | |
| 26 | 29 | | **Pull request** | A proposed change, in its own fork or on a branch. Usually made for an issue. | | |
| 27 | − | | **Session** | The record of how a pull request was made: prompts, reasoning, tool calls. | | |
| 30 | + | | **Session** | The record of how a pull request was made, written by the coding agent that made it: prompts, reasoning, tool calls. | | |
| 28 | 31 | ||
| 29 | − | What g1t adds: one issue routinely has | |
| 30 | − | several pull requests, each from a different agent, and g1t keeps track of | |
| 31 | − | which one was merged. | |
| 32 | + | What g1t adds: one issue can have several pull requests, each from a | |
| 33 | + | different person or agent, and g1t keeps track of which one was merged. | |
| 32 | 34 | ||
| 33 | 35 | ## Issues | |
| 34 | 36 | ||
| 35 | − | An issue says what should change in a repository. People open them, agents | |
| 36 | − | open them, and so can anything with an access token, such as an error | |
| 37 | + | An issue says what should change in a repository. People open them, coding | |
| 38 | + | agents open them, and so can anything with an access token, such as an error | |
| 37 | 39 | tracker reporting a crash. | |
| 38 | 40 | ||
| 39 | 41 | An issue has: | |
| 40 | 42 | ||
| 41 | − | - a **title** and a **description** in Markdown. An agent given the issue | |
| 42 | − | works from this text. It can say what done means in plain words, | |
| 43 | − | under a `## Definition of done` heading if you like: context for the | |
| 44 | − | agent and its reviewers, not something a merge waits on; | |
| 43 | + | - a **title** and a **description** in Markdown. Whoever works on the | |
| 44 | + | issue, person or agent, works from this text. It can say what done means | |
| 45 | + | in plain words, under a `## Definition of done` heading if you like: | |
| 46 | + | context for whoever works on it and its reviewers, not something a merge | |
| 47 | + | waits on; | |
| 45 | 48 | - **labels**, which say what kind of issue it is; | |
| 46 | 49 | - **comments**; | |
| 47 | 50 | - a **state**: open or closed. A closed issue records why: `completed` or | |
| ⋯ | |||
| 64 | 67 | ||
| 65 | 68 | A pull request is a proposed change. There are two ways to make one. | |
| 66 | 69 | ||
| 67 | − | **In a fork.** This is how agents work. Opening the pull request creates a | |
| 70 | + | **In a fork.** This is how coding agents usually work: the `pull_request` | |
| 71 | + | tool's `create` action opens one for an issue. Opening the pull request creates a | |
| 68 | 72 | copy of the repository that belongs to that pull request alone, ready in | |
| 69 | 73 | about the time a branch would be. Its author clones the fork, commits and pushes to it. Nothing they do | |
| 70 | 74 | can touch `main` or another pull request. The fork lives at | |
| ⋯ | |||
| 91 | 95 | ||
| 92 | 96 | ## Assignees and reviewers | |
| 93 | 97 | ||
| 94 | − | An issue is assigned to people, to g1t, or to both. A pull | |
| 95 | − | request has assignees too, and reviewers: the people, or g1t, | |
| 96 | − | whose review was asked for. Each shows beside the conversation, with where | |
| 97 | − | every reviewer stands. | |
| 98 | + | An issue is assigned to people. A pull request has assignees too, and | |
| 99 | + | reviewers: the people whose review was asked for. Each shows beside the | |
| 100 | + | conversation, with where every reviewer stands. | |
| 98 | 101 | ||
| 99 | 102 | Whatever happens is told in the conversation, in order, between the | |
| 100 | − | comments: who assigned whom, whose review was asked for, when it was marked | |
| 101 | − | ready, merged or closed, and each step g1t took by itself, such as sending | |
| 102 | − | an agent back to address a review. | |
| 103 | + | comments: who assigned whom, whose review was asked for, and when it was | |
| 104 | + | marked ready, merged or closed. | |
| 103 | 105 | ||
| 104 | 106 | ## Several pull requests for one issue | |
| 105 | 107 | ||
| 106 | 108 | An issue can have more than one pull request: a second attempt after the | |
| 107 | − | first fell short, or your own agent's alongside g1t's. Each is in its own | |
| 109 | + | first fell short, or two agents trying different approaches. Each is in its own | |
| 108 | 110 | fork, with its own session and its own diff. The issue's page lists them | |
| 109 | 111 | all with their status. | |
| 110 | 112 | ||
| ⋯ | |||
| 138 | 140 | unless the repository allows bypassing them and someone who can merge | |
| 139 | 141 | chooses to. Checks that are not required are shown, and never hold a merge. | |
| 140 | 142 | ||
| 141 | − | The same rules hold for people and agents. A pull request g1t opens is | |
| 142 | − | checked by the same workflows as yours, and an agent cannot mark its own | |
| 143 | − | work as passing: only the workflow runs report. | |
| 143 | + | The same rules hold for people and agents. A pull request a coding agent | |
| 144 | + | opens is checked by the same workflows as yours, and an agent cannot mark | |
| 145 | + | its own work as passing: only the workflow runs report. | |
| 144 | 146 | ||
| 145 | 147 | ## Review | |
| 146 | 148 | ||
| ⋯ | |||
| 148 | 150 | on a single line of its change. Line comments are shown in the **Files changed** | |
| 149 | 151 | tab under the line they are about. | |
| 150 | 152 | ||
| 151 | − | You can also ask **g1t** to review. It reads the change in a sandbox | |
| 152 | − | of its own and posts comments on lines, a summary and a verdict, as | |
| 153 | − | `g1t`. | |
| 154 | − | ||
| 155 | 153 | A reviewer can also give a verdict: **approve**, or **request changes**. | |
| 156 | 154 | The pull request shows where each reviewer stands. You cannot give a verdict | |
| 157 | − | on a pull request you opened, and that holds for agents too: one agent can | |
| 158 | − | review another's work, but not its own. | |
| 159 | − | ||
| 160 | − | Requesting changes on a pull request g1t opened sends g1t back to | |
| 161 | − | make them. See [talk to agents](/guides/talking-to-agents/#ask-for-changes). | |
| 155 | + | on a pull request you opened, and that holds for a coding agent working as | |
| 156 | + | you too. | |
| 162 | 157 | ||
| 163 | 158 | ## Overlap | |
| 164 | 159 | ||
| ⋯ | |||
| 169 | 164 | Two pull requests for the *same* issue are expected to overlap: they are | |
| 170 | 165 | alternatives, and one will be merged. Two for *different* issues are heading | |
| 171 | 166 | for a conflict, and g1t says so while the work is still going on rather than | |
| 172 | − | when the second one tries to merge. Agents get the same list from | |
| 173 | − | the `pull_request` tool's `get` action, as `overlaps`. | |
| 174 | − | ||
| 175 | − | g1t is told about the other work before it starts. Its instructions | |
| 176 | − | list every pull request in progress in the repository, what each is for and | |
| 177 | − | which files it changes, and ask it to keep its edits small and local where | |
| 178 | − | it has to touch the same files. It is told again when it is sent back to | |
| 179 | − | revise. The first entry in its session records what it was told, so you can | |
| 180 | − | see what it knew. | |
| 167 | + | when the second one tries to merge. Coding agents get the same list from | |
| 168 | + | the `pull_request` tool's `get` action, as `overlaps`, so they can keep | |
| 169 | + | their edits small and local where they have to touch the same files. | |
| 181 | 170 | ||
| 182 | 171 | ## Merging | |
| 183 | 172 | ||
| ⋯ | |||
| 196 | 185 | ||
| 197 | 186 | **Catch up with main** brings it up to date. When the pull request and `main` changed | |
| 198 | 187 | different files, g1t merges `main` in itself and pushes the merge in a few | |
| 199 | − | seconds. When they changed some of the same files, g1t merges `main` | |
| 200 | − | into the pull request in a sandbox: if the merge is clean, it is pushed as it | |
| 201 | − | is; if it conflicts, the agent is given the conflicted files and what the | |
| 202 | − | pull request is for, resolves them, and pushes the result, and the session | |
| 203 | − | records what was done. Either way the workflows run again on the result | |
| 204 | − | ([how catching up works](/guides/pull-requests/#catching-up)). You can also do it by | |
| 205 | − | hand: pull `main` into the fork or the branch, resolve, and push. `main` never loses a commit this way, however many | |
| 188 | + | seconds, and the workflows run again on the result | |
| 189 | + | ([how catching up works](/guides/pull-requests/#catching-up)). When they | |
| 190 | + | changed some of the same files, do it by hand: pull `main` into the fork or | |
| 191 | + | the branch, resolve, and push. `main` never loses a commit this way, however many | |
| 206 | 192 | pull requests are in flight. | |
| 207 | 193 | ||
| 208 | 194 | ## The merge queue | |
| ⋯ | |||
| 219 | 205 | ||
| 220 | 206 | A session is the record of how a pull request was made: the prompt the | |
| 221 | 207 | agent was given, its reasoning, the tools it called and what they returned. | |
| 208 | + | The coding agent records it with the `pull_request` tool's `record_session` | |
| 209 | + | action as it works. | |
| 222 | 210 | Each entry is tied to the commit that was the head when it was recorded, so | |
| 223 | 211 | **Blame** on any file can show not only the commit that last changed a | |
| 224 | 212 | line, but the pull request and issue it came from and the agent's own | |
| ⋯ | |||
| 233 | 221 | ||
| 234 | 222 | ## What is not built yet | |
| 235 | 223 | ||
| 236 | − | g1t is under active development. These are designed but not available yet | |
| 237 | − | (every current limit, and why, is on | |
| 238 | − | [What g1t can't do yet](/about/limitations/)): | |
| 239 | − | ||
| 240 | − | - **Milestones.** | |
| 241 | − | - **g1t's hosted models for everyone.** g1t can put its own agents on an | |
| 242 | − | issue, each in a sandbox, on the | |
| 243 | − | [g1t plan](/guides/usage-and-billing/#the-g1t-plan) or the one-time $5 | |
| 244 | − | [trial](/guides/usage-and-billing/#the-trial) after a card check. Agents | |
| 245 | − | run on the workspace's own model provider, or on g1t's hosted models | |
| 246 | − | while its trial has credit; hosted models open to every workspace once | |
| 247 | − | payments go live. See [model providers](/guides/models/). | |
| 224 | + | g1t is under active development. Every current limit, and why, is on | |
| 225 | + | [What g1t can't do yet](/about/limitations/). | |
| 1 | 1 | --- | |
| 2 | 2 | title: Access and roles | |
| 3 | − | description: The five repository roles and what each can do, the base permission members get, the Admin role a repository's creator gets, security managers, roles through teams, outside collaborators and invitations, who may manage deploy keys, and what agents may do on a person's behalf. | |
| 3 | + | description: The five repository roles and what each can do, the base permission members get, the Admin role a repository's creator gets, security managers, roles through teams, outside collaborators and invitations, and who may manage deploy keys. | |
| 4 | 4 | --- | |
| 5 | 5 | ||
| 6 | 6 | Everyone who can work in a repository has a role on it. The role says what | |
| ⋯ | |||
| 16 | 16 | | --- | --- | | |
| 17 | 17 | | **Read** | Read and clone; open issues and pull requests, and comment. | | |
| 18 | 18 | | **Triage** | Read, and manage issues and pull requests: apply labels and milestones, assign, close. | | |
| 19 | − | | **Write** | Triage, and push, merge, manage labels and milestones, see security alerts, and put agents to work. | | |
| 19 | + | | **Write** | Triage, and push, merge, manage labels and milestones, and see security alerts. | | |
| 20 | 20 | | **Maintain** | Write, and manage the repository's settings and topics. | | |
| 21 | 21 | | **Admin** | Everything: branch protection and rulesets, webhooks, secrets, deployments, security settings, who has access, and the repository's name, visibility and archiving. | | |
| 22 | 22 | ||
| ⋯ | |||
| 33 | 33 | | Merge pull requests and use the merge queue | | | Yes | Yes | Yes | | |
| 34 | 34 | | Create, edit and delete labels and milestones | | | Yes | Yes | Yes | | |
| 35 | 35 | | See and dismiss security alerts | | | Yes | Yes | Yes | | |
| 36 | − | | Assign agents and start runs, plans and workflows | | | Yes | Yes | Yes | | |
| 37 | − | | Change the description, topics, and pull request and agent settings | | | | Yes | Yes | | |
| 36 | + | | Start workflows | | | Yes | Yes | Yes | | |
| 37 | + | | Change the description, topics, and pull request settings | | | | Yes | Yes | | |
| 38 | 38 | | Change branch protection, rulesets and guardrails | | | | | Yes | | |
| 39 | 39 | | Change security settings, custom patterns and bypass reviews | | | | | Yes | | |
| 40 | 40 | | Manage webhooks, secrets, variables, deployments and domains | | | | | Yes | | |
| ⋯ | |||
| 63 | 63 | - Applying a label the repository does not have yet creates it, for | |
| 64 | 64 | someone with Write. | |
| 65 | 65 | ||
| 66 | − | Read and Triage cannot put agents to work, or start anything else that | |
| 67 | − | spends compute: runs, plans, workflows and deployments need Write. | |
| 66 | + | Read and Triage cannot start anything that spends compute: workflows and | |
| 67 | + | deployments need Write. | |
| 68 | 68 | ||
| 69 | 69 | ## How your role is worked out | |
| 70 | 70 | ||
| ⋯ | |||
| 165 | 165 | ||
| 166 | 166 | Before roles, every member of a workspace could also change a repository's | |
| 167 | 167 | settings, its branch protection and guardrails, webhooks, secrets and | |
| 168 | − | variables, deployments and domains. With Write, members keep pushing, | |
| 169 | − | merging and putting agents to work; changing settings now needs Maintain, | |
| 168 | + | variables, deployments and domains. With Write, members keep pushing | |
| 169 | + | and merging; changing settings now needs Maintain, | |
| 170 | 170 | and branch protection, rulesets, guardrails and the rest Admin. Owners | |
| 171 | 171 | have Admin, so they keep all of it. | |
| 172 | 172 | ||
| ⋯ | |||
| 248 | 248 | workspace itself, such as its webhooks, secrets, tokens or integrations; | |
| 249 | 249 | - are held to whatever the workspace asks of its members, checked when | |
| 250 | 250 | they are added, when they accept, and on every request after. | |
| 251 | − | ||
| 252 | − | - can put agents to work where they have Write; the runs are charged to | |
| 253 | − | the repository's workspace, and they do not see which model ran or what | |
| 254 | − | it cost. An agent working for them is told the project's memory, never | |
| 255 | − | the workspace's. | |
| 256 | 251 | ||
| 257 | 252 | Owners see every outside collaborator, and the repositories and roles each | |
| 258 | 253 | has, on the **Outside collaborators** tab of the workspace's | |
| ⋯ | |||
| 281 | 276 | answered, it is listed as pending on the repository's **Settings → Access**, | |
| 282 | 277 | where someone with Admin can change its role or **Revoke** it. To invite | |
| 283 | 278 | someone again after an expired or declined invitation, add them again. | |
| 284 | − | ||
| 285 | − | ## Agents | |
| 286 | − | ||
| 287 | − | An agent works with the role of the person it acts for, on the | |
| 288 | − | repository it works in, and never more than Write. An owner's agent has | |
| 289 | − | Write, not Admin. So an agent working for you can push, open and merge | |
| 290 | − | pull requests where you can, and cannot change settings, protection, | |
| 291 | − | webhooks or secrets, even when you can. | |
| 292 | − | ||
| 293 | − | An agent's credential can never change who has access: it cannot add, | |
| 294 | − | remove or invite anyone, answer an invitation, or change the base | |
| 295 | − | permission. When the person it works for loses their role on the | |
| 296 | − | repository, or leaves the workspace, the agent loses it too. See | |
| 297 | − | [credentials](/guides/working-with-g1t/#credentials). | |
| 298 | 279 | ||
| 299 | − | Because putting agents to work spends compute, it needs Write. Someone with | |
| 300 | − | Read or Triage who mentions or assigns an agent is told so, and nothing | |
| 301 | − | starts. | |
| 302 | − | ||
| 303 | 280 | ## Deploy keys | |
| 304 | 281 | ||
| 305 | 282 | A [deploy key](/guides/git/#deploy-keys) is an SSH key that lets a machine | |
| ⋯ | |||
| 311 | 288 | | --- | --- | | |
| 312 | 289 | | Someone with the Admin role on it, owners included | Yes | | |
| 313 | 290 | | Someone with Maintain or less | No | | |
| 314 | − | | An agent, whoever it works for | No | | |
| 315 | 291 | | A workspace's [access token](/guides/workspaces/#workspace-access-tokens) | Only when an owner gave it Admin | | |
| 316 | 292 | | A deploy key | No | | |
| 317 | 293 | ||
| 597 | 597 | ||
| 598 | 598 | ### What a job can reach | |
| 599 | 599 | ||
| 600 | − | A job's network is restricted, as an agent's is (see | |
| 601 | − | [guardrails](/guides/guardrails/)): it reaches the hosts its project's | |
| 600 | + | A job's network is restricted by its project's | |
| 601 | + | [guardrails](/guides/guardrails/): it reaches the hosts its project's | |
| 602 | 602 | guardrails allow, g1t itself, and what builds need, and nothing else. | |
| 603 | 603 | What builds need is the package registries (npm, PyPI, crates.io, the Go | |
| 604 | 604 | proxy, RubyGems, Packagist, NuGet, Maven and Gradle, Debian's mirrors), | |
| ⋯ | |||
| 618 | 618 | goes in **Workflow-only domains** instead, limited to the workflows and | |
| 619 | 619 | environments that need it: `api.cloudflare.com | deploy.yml | production` | |
| 620 | 620 | lets only `deploy.yml`'s jobs with `environment: production` reach it. | |
| 621 | − | Agents never reach those hosts, and neither do runs of pull requests from | |
| 622 | − | forks. See [workflow-only domains](/guides/guardrails/#workflow-only-domains). | |
| 621 | + | Runs of pull requests from forks never reach those hosts. See [workflow-only domains](/guides/guardrails/#workflow-only-domains). | |
| 623 | 622 | ||
| 624 | 623 | ### Brokered secrets | |
| 625 | 624 | ||
| ⋯ | |||
| 1096 | 1095 | it for credentials goes to your cloud's token service, which a job reaches | |
| 1097 | 1096 | only when its project allows it (see [what a job can reach](#what-a-job-can-reach)). | |
| 1098 | 1097 | Add the hosts under **Settings → Guardrails → Workflow-only domains**, | |
| 1099 | − | limited to the workflow and environment that deploy, so agents and other | |
| 1100 | − | workflows never reach them: | |
| 1098 | + | limited to the workflow and environment that deploy, so other workflows | |
| 1099 | + | never reach them: | |
| 1101 | 1100 | ||
| 1102 | 1101 | ```text | |
| 1103 | 1102 | sts.us-east-1.amazonaws.com | deploy.yml | production | |
| ⋯ | |||
| 1546 | 1545 | ||
| 1547 | 1546 | ## Pull requests | |
| 1548 | 1547 | ||
| 1549 | − | A pull request's workflows run on each new head: when it is opened, when | |
| 1550 | − | a commit is pushed to it, and, for one g1t makes, when g1t | |
| 1551 | − | marks it ready, which on g1t is when it first has code. Each head runs | |
| 1552 | − | each workflow once. | |
| 1548 | + | A pull request's workflows run on each new head: when it is opened and | |
| 1549 | + | when a commit is pushed to it. Each head runs each workflow once. | |
| 1553 | 1550 | ||
| 1554 | 1551 | They also start on the activity types `reopened` (also run by | |
| 1555 | 1552 | default, as `opened` and `synchronize` are), `converted_to_draft`, | |
| ⋯ | |||
| 1586 | 1583 | build the base branch, never the pull request's code. | |
| 1587 | 1584 | ||
| 1588 | 1585 | g1t keeps two refs in the repository for every open pull request, from a | |
| 1589 | − | branch, a fork or a pull request g1t made: `refs/pull/<number>/head` at | |
| 1586 | + | branch or a fork: `refs/pull/<number>/head` at | |
| 1590 | 1587 | its head (a fork's head commit is copied into the repository), and | |
| 1591 | 1588 | `refs/pull/<number>/merge` at its test merge commit. Both move each time | |
| 1592 | 1589 | the head is pushed to, the pull request is opened or reopened, or its | |
| ⋯ | |||
| 1614 | 1611 | A pull request from outside the workspace may wait for approval before | |
| 1615 | 1612 | its workflows run: see [pull requests from outside](#pull-requests-from-outside). | |
| 1616 | 1613 | ||
| 1617 | − | `github.event.pull_request` reads as it does on GitHub. For a pull request | |
| 1618 | − | g1t made, `pull_request.user` is g1t (`login` `g1t`, `type` `Bot`), and | |
| 1619 | − | `pull_request.requested_by` names the person who asked for it; it is `null` | |
| 1620 | − | on anyone else's. `github.event.issue.requested_by` does the same for an | |
| 1621 | − | issue g1t's agent filed. `sender` is whoever caused the event. | |
| 1614 | + | `github.event.pull_request` reads as it does on GitHub. `sender` is | |
| 1615 | + | whoever caused the event. | |
| 1622 | 1616 | ||
| 1623 | 1617 | ## The event payload | |
| 1624 | 1618 | ||
| ⋯ | |||
| 1690 | 1684 | builds, on the branch `g1t-queue/<entry>`, and the state lands only if | |
| 1691 | 1685 | they and every required check pass on it. A workflow behind a required | |
| 1692 | 1686 | check needs `merge_group` in its `on:`. | |
| 1693 | − | - **A pull request g1t is working on** goes back to g1t when | |
| 1694 | − | a check fails, with the end of each failed job's log. The agent reads the | |
| 1695 | − | run and its logs with the same tools you have, fixes the cause, and | |
| 1696 | − | pushes; the workflows run again. See | |
| 1697 | − | [seeing it through](/guides/working-with-g1t/#seeing-it-through). | |
| 1698 | 1687 | ||
| 1699 | 1688 | ```yaml | |
| 1700 | 1689 | name: CI | |
| ⋯ | |||
| 1748 | 1737 | Every job also gets `${{ secrets.G1T_TOKEN }}`, [its own token](#the-jobs-token), | |
| 1749 | 1738 | with `GITHUB_TOKEN` as its alias. A pull request's runs get secrets only | |
| 1750 | 1739 | when its author has the Write [role](/guides/access-and-roles/) or higher | |
| 1751 | − | on the repository, a member or an outside collaborator, or is g1t working | |
| 1752 | − | on its own. For a pull request g1t made, its author is g1t and the person | |
| 1753 | − | who asked for it is the one whose role counts. Anyone else's, such as one | |
| 1740 | + | on the repository, a member or an outside collaborator. Anyone else's, such as one | |
| 1754 | 1741 | from a fork or by someone with Read or Triage, runs without secrets and | |
| 1755 | 1742 | with a token that can only read. See | |
| 1756 | 1743 | [who gets secrets](/guides/secrets-and-variables/#who-gets-secrets). | |
| ⋯ | |||
| 1775 | 1762 | or a comment made with it runs nothing, so a workflow cannot set itself | |
| 1776 | 1763 | off. `workflow_dispatch` and [`repository_dispatch`](#repository-dispatch) | |
| 1777 | 1764 | are the exceptions, for a workflow that means to start another. | |
| 1778 | − | - It **never puts g1t to work**. A comment it posts that mentions | |
| 1779 | − | `@g1t` starts nothing, and it cannot assign an issue or a plan to g1t, | |
| 1780 | − | queue one for it, hand it work or ask it for a review. Otherwise a | |
| 1781 | − | workflow that asks g1t to fix a failing check would run again on g1t's | |
| 1782 | − | push, and ask again, without end. A step that should put g1t to work | |
| 1783 | − | uses a token of a person's own, stored as a | |
| 1784 | − | [secret](/guides/secrets-and-variables/). | |
| 1785 | 1765 | ||
| 1786 | 1766 | `permissions:` goes at the top of the workflow, for every job, or on a job, | |
| 1787 | 1767 | which then ignores the workflow's. Once either is written, every permission | |
| ⋯ | |||
| 1927 | 1907 | | **Outside contributors** (the default) | Those, and everyone outside the workspace who cannot push here: pull requests from forks, and from people with Read or Triage. | | |
| 1928 | 1908 | | **All external contributors** | Everyone outside the workspace, [outside collaborators](/guides/access-and-roles/#outside-collaborators) with Write included. | | |
| 1929 | 1909 | ||
| 1930 | − | Members' pull requests never wait, nor do pull requests g1t opens on its | |
| 1931 | − | own. For a pull request g1t made for someone, that person is the one whose | |
| 1932 | − | policy counts. Each new push to the pull request waits again. | |
| 1910 | + | Members' pull requests never wait. Each new push to the pull request waits again. | |
| 1933 | 1911 | `pull_request_target` runs, which run the default branch's workflow and | |
| 1934 | 1912 | code, never wait. | |
| 1935 | 1913 | ||
| 1 | − | --- | |
| 2 | − | title: Agent abilities | |
| 3 | − | description: What an agent may do, in groups - g1t's own, its computer, each connected integration, and the connectors and MCP servers it has - and for each whether it acts alone, only when asked for it, after asking first, or never; whose connection it uses; and the cards it posts when it can't. | |
| 4 | − | --- | |
| 5 | − | ||
| 6 | − | Every agent has an **Abilities** tab on its page, after **Skills**. It | |
| 7 | − | lists what the agent can do, in groups, and for each ability a **level** | |
| 8 | − | that says how freely it may do it. The levels are enforced in code: a | |
| 9 | − | tool the agent isn't allowed is withheld, and one it may use only after | |
| 10 | − | asking posts a card and waits. The tab opens with the whole thing in a | |
| 11 | − | sentence, such as *Can read issues in Linear and open pull requests on its | |
| 12 | − | own; imports issues in Linear when asked for it; asks before commenting in | |
| 13 | − | Linear and merging; never deploys to production.* | |
| 14 | − | ||
| 15 | − | Skills tell an agent how to do a kind of work; abilities say what it may | |
| 16 | − | touch. A skill never adds an ability (see | |
| 17 | − | [agent skills](/guides/agent-skills/)), and an agent never does more for | |
| 18 | − | someone than that person could do themselves (see | |
| 19 | − | [what agents can do for whom](/guides/agent-access/)). | |
| 20 | − | ||
| 21 | − | ## The levels | |
| 22 | − | ||
| 23 | − | | Level | What it means | | |
| 24 | − | | --- | --- | | |
| 25 | − | | **Alone** | It does it when its work calls for it, and says so. | | |
| 26 | − | | **Alone when asked for it** | It does it on its own when the person it acts for named the thing in what they asked (the issue's key, or the action), and asks first otherwise. | | |
| 27 | − | | **Ask first** | It posts a card in the conversation saying exactly what it would do. The person it acts for, or an owner, presses **Allow** or **Deny**. Allowed, it runs as the person who pressed, and the agent hears the result. | | |
| 28 | − | | **Never** | The tool isn't offered. If the agent asks for it anyway, it is refused with the rule's name, and says so plainly rather than trying another way. | | |
| 29 | − | ||
| 30 | − | Defaults follow what an ability does: | |
| 31 | − | ||
| 32 | − | | What it does | Default | Freest it can be set | | |
| 33 | − | | --- | --- | --- | | |
| 34 | − | | Reads | Alone | Alone | | |
| 35 | − | | Writes inside g1t (opens an issue, a pull request, an edit) | Alone when asked for it, or today's choice for code and docs | Alone | | |
| 36 | − | | Sends something outside g1t (a comment in another system, a message, a change there) | Ask first | Alone | | |
| 37 | − | | Purchases, credentials and permission changes (a production deploy) | Never | Ask first | | |
| 38 | − | ||
| 39 | − | Every change to a level is saved as a new version of the agent, like any | |
| 40 | − | other change on its profile, and shows under **Profile → Versions** as a | |
| 41 | − | change to its abilities. | |
| 42 | − | ||
| 43 | − | ## The groups | |
| 44 | − | ||
| 45 | − | ### g1t | |
| 46 | − | ||
| 47 | − | Artifacts, chat, code, issues and pull requests, making files, and working | |
| 48 | − | with colleagues and memory are always on, within the access of the person | |
| 49 | − | the agent acts for and everyone who will read its answer. They have no | |
| 50 | − | level to set. Four of them keep a choice, the same choice as | |
| 51 | − | [what it may do alone](/guides/agents/#what-it-may-do-alone) on the Profile | |
| 52 | − | tab: | |
| 53 | − | ||
| 54 | − | | Ability | Choices | Default | | |
| 55 | − | | --- | --- | --- | | |
| 56 | − | | Open pull requests | Alone, Ask first | Alone | | |
| 57 | − | | Merge | Alone, Ask first, Never | Ask first | | |
| 58 | − | | Deploy to production | Ask first, Never | Ask first | | |
| 59 | − | | Edit docs | Alone, Ask first (as suggestions) | Ask first | | |
| 60 | − | ||
| 61 | − | Changing one here changes it there, and the other way round. | |
| 62 | − | ||
| 63 | − | ### Its computer | |
| 64 | − | ||
| 65 | − | What the agent may do on [its own computer](/guides/agents/#its-computer), | |
| 66 | − | in its sessions. Chat replies never use the computer, whatever is set here. | |
| 67 | − | ||
| 68 | − | | Ability | Tools it offers | Kind | Default | | |
| 69 | − | | --- | --- | --- | --- | | |
| 70 | − | | Shell | `run_command` | Write | Alone when asked for it | | |
| 71 | − | | Files | `computer_read_file` · `computer_write_file` | Write | Alone | | |
| 72 | − | | Browser | — | Send | Coming | | |
| 73 | − | | Web search | — | Read | Coming | | |
| 74 | − | ||
| 75 | − | Set to **Never**, an ability's tools are not offered to the agent at all, | |
| 76 | − | and a call for one anyway is refused with the rule. For the shell at | |
| 77 | − | **Alone when asked for it**, the session's goal or a message steering it | |
| 78 | − | counts as asking when it names running, building, testing, installing, | |
| 79 | − | cloning or the like; otherwise the command waits on an Ask-first card, with | |
| 80 | − | the command on it. Files are alone by default, since nothing leaves the | |
| 81 | − | computer. A browser and web search are marked **Coming** until they exist; | |
| 82 | − | nothing can be set for them yet. | |
| 83 | − | ||
| 84 | − | ### Integrations | |
| 85 | − | ||
| 86 | − | Every integration the workspace has connected lists what an agent can do | |
| 87 | − | through it, one row per action, with a level for each. What is listed | |
| 88 | − | comes from what the integration does today: | |
| 89 | − | ||
| 90 | − | | Integration | Rows | Tool the agent calls | | |
| 91 | − | | --- | --- | --- | | |
| 92 | − | | Linear | Read issues · Import issues · Comment | `lookup_outside` · `import_outside` · `act_outside` | | |
| 93 | − | | Jira | Read tickets · Import tickets · Comment | `lookup_outside` · `import_outside` · `act_outside` | | |
| 94 | − | | Sentry | Read issues · Import issues · Comment · Resolve issues | `lookup_outside` · `import_outside` · `act_outside` | | |
| 95 | − | | Datadog, Alerts webhook | None: they open issues by themselves | — | | |
| 96 | − | ||
| 97 | − | Reading looks an item up by its key (`ENG-42`, `TECH-1234`) or its | |
| 98 | − | address. Importing opens an issue in a repository here, linked back to | |
| 99 | − | the item, as the person the agent acts for. Commenting and resolving write | |
| 100 | − | in the other system, as the workspace's connection, and name the person | |
| 101 | − | the agent acted for with a link back to the conversation. | |
| 102 | − | ||
| 103 | − | An integration that gives agents abilities but isn't connected is listed | |
| 104 | − | too, with **Connect** for owners and **Ask an owner** for anyone else, | |
| 105 | − | which opens it in [Customize](/guides/customize/#connectors). Nothing on | |
| 106 | − | it can be set until it is connected. | |
| 107 | − | ||
| 108 | − | #### Whose connection | |
| 109 | − | ||
| 110 | − | Each integration row says whose connection it runs on: | |
| 111 | − | ||
| 112 | − | | | | | |
| 113 | − | | --- | --- | | |
| 114 | − | | **Workspace connection** | The agent acts as the integration's connection for the whole workspace, the one an owner set up under Integrations. Only owners choose this. | | |
| 115 | − | | **Asker's connection** | The agent acts as the asking person's own account. When they haven't connected one, the agent posts a **Connect** card in the conversation: one press opens their own settings for it. | | |
| 116 | − | ||
| 117 | − | A [personal agent](/guides/agents/#personal-agents) starts on the asker's | |
| 118 | − | connection; an owner can put it on the workspace's. Linear, Jira and | |
| 119 | − | Sentry can't be connected per person yet, so for them the choice is the | |
| 120 | − | workspace's connection today. | |
| 121 | − | ||
| 122 | − | ### Connectors | |
| 123 | − | ||
| 124 | − | MCP servers reach an agent in two ways, and the tab lists both under | |
| 125 | − | **Connectors**: | |
| 126 | − | ||
| 127 | − | - **The workspace's connectors**, connected once in | |
| 128 | − | [Customize](/guides/customize/#connectors) and given to every agent, a | |
| 129 | − | team or this agent. Each row says how the agent has it (**Every agent**, | |
| 130 | − | **Team QA**, **This agent**) and its state. A connector that needs a | |
| 131 | − | sign-in or a key, or has a problem, gives the agent nothing until an | |
| 132 | − | owner fixes it there. Servers that need a key or a browser sign-in are | |
| 133 | − | connected this way. | |
| 134 | − | - **Only this agent**: servers owners add to this agent alone, one at a | |
| 135 | − | time, by a name and an HTTPS address on a public host, with no sign-in. | |
| 136 | − | An agent keeps at most 10. | |
| 137 | − | ||
| 138 | − | g1t lists a server's tools when it is connected or added, keeps the first | |
| 139 | − | 40, and each tool becomes a row: | |
| 140 | − | ||
| 141 | − | - a tool the server marks as read-only is a **read**, Alone by default; | |
| 142 | − | - any other tool, including one the server says nothing about, counts as | |
| 143 | − | a **write outside g1t**, Ask first by default. | |
| 144 | − | ||
| 145 | − | Tools are offered to the agent as `<server>__<tool>`, with the arguments | |
| 146 | − | the server describes. For a server added to this agent alone, **List its | |
| 147 | − | tools again** picks up a server that changed and **Remove** takes the | |
| 148 | − | server and its rows off the agent at once; both are new versions of the | |
| 149 | − | agent. A workspace connector is listed again, signed in, given and taken | |
| 150 | − | back on its own page in Customize, and the tab links there. | |
| 151 | − | ||
| 152 | − | ## Ask first, in the conversation | |
| 153 | − | ||
| 154 | − | When an ability is Ask first (or Alone when asked for it, and the person | |
| 155 | − | didn't ask), the agent posts a card where it is working: what it would | |
| 156 | − | do, for whom, and under which rule, with the text it would write. The | |
| 157 | − | person it acts for, or an owner, presses **Allow** or **Deny**: | |
| 158 | − | ||
| 159 | − | - **Allow** runs the call as the person who pressed it. The card then says | |
| 160 | − | what happened, and the agent is told the result. A session that was | |
| 161 | − | waiting goes on with it at its next step. | |
| 162 | − | - **Deny** tells the agent, which says so and doesn't try another way. | |
| 163 | − | ||
| 164 | − | A [session](/guides/agent-sessions/) with a call waiting shows **Needs | |
| 165 | − | approval** and the call it waits for, until the card is answered or the | |
| 166 | − | session is stopped. | |
| 167 | − | ||
| 168 | − | ## When something is missing | |
| 169 | − | ||
| 170 | − | When a request needs an integration that isn't connected, or an ability | |
| 171 | − | the agent doesn't have, the agent says so plainly and posts a **Request** | |
| 172 | − | card: | |
| 173 | − | ||
| 174 | − | - for an integration or a connector, **Ask the owners** opens the same | |
| 175 | − | request Customize does (see [requests](/guides/customize/#requests)), | |
| 176 | − | and **Open in Customize** goes to its page; | |
| 177 | − | - for an ability, **Ask the owners** notifies every owner with a link to | |
| 178 | − | the agent's Abilities tab, and **Open Abilities** goes there. | |
| 179 | − | ||
| 180 | − | Owners see a link to do it themselves instead. | |
| 181 | − | ||
| 182 | − | ## Refusals, in the transcript and the audit log | |
| 183 | − | ||
| 184 | − | A policy fails closed. When a tool is withheld or a call is refused, the | |
| 185 | − | agent's answer says which rule refused it, such as *Linear: Comment is | |
| 186 | − | Never*, and so does the session's transcript (the tool call shows as | |
| 187 | − | refused). The workspace's [audit log](/guides/audit-log/) records every | |
| 188 | − | refusal under the agent, with the rule (`integration:linear:comment=never`) | |
| 189 | − | and what was refused, and every Allow or Deny under the person who | |
| 190 | − | pressed it. | |
| 191 | − | ||
| 192 | − | ## Who edits | |
| 193 | − | ||
| 194 | − | | Agent | Who changes its abilities | | |
| 195 | − | | --- | --- | | |
| 196 | − | | A workspace agent | The workspace's owners. | | |
| 197 | − | | A personal agent | The member it belongs to, except that only owners put it on the workspace's connection. | | |
| 198 | − | | `@g1t` | Owners, like any workspace agent. | | |
| 199 | − | ||
| 200 | − | Everyone in the workspace can read the tab. | |
| 201 | − | ||
| 202 | − | ## API | |
| 203 | − | ||
| 204 | − | An agent's abilities are part of its definition: `abilities.settings`, | |
| 205 | − | by ability id (`integration:linear:comment`), each with a `level` | |
| 206 | − | (`alone`, `asked`, `ask`, `never`) and, for an integration, `credentials` | |
| 207 | − | (`workspace` or `asker`); and `abilities.mcp_servers`. Changing an agent | |
| 208 | − | with `abilities: { settings }` replaces its settings, and is a new | |
| 209 | − | version like any change. MCP servers are added and removed with the | |
| 210 | − | agents service's `add_mcp_server`, `refresh_mcp_server` and | |
| 211 | − | `remove_mcp_server`; they never travel with a change. The workspace's | |
| 212 | − | connectors and who gets them are the [`customize`](/guides/customize/#api) | |
| 213 | − | resource's; which ones reach an agent is read with the agents service's | |
| 214 | − | `agent_connectors`. | |
| 215 | − | ||
| 216 | − | The computer itself has routes of its own under the agent: | |
| 217 | − | `GET /workspaces/{workspace}/agents/{agent}/computer` for its state and | |
| 218 | − | recent commands, `POST …/computer/wake`, `…/computer/sleep` and | |
| 219 | − | `…/computer/reset`, and `GET …/computer/commands`; in MCP, the `agent` | |
| 220 | − | tool's `computer`, `wake_computer`, `sleep_computer`, `reset_computer` and | |
| 221 | − | `computer_commands` actions, all under `agents:run`. | |
| 222 | − | ||
| 223 | − | ## Next | |
| 224 | − | ||
| 225 | − | - [Agents](/guides/agents/): hiring, changing and running agents. | |
| 226 | − | - [Agent skills](/guides/agent-skills/): how an agent does a kind of work. | |
| 227 | − | - [Customize](/guides/customize/): connecting connectors and integrations, and asking an owner to. | |
| 228 | − | - [What agents can do for whom](/guides/agent-access/): the access every ability runs within. |
| 1 | − | --- | |
| 2 | − | title: What agents can do for whom | |
| 3 | − | description: Agents act with the access of the person asking and answer only with what their audience may see. How that works for engineers, for the rest of the company, and for members without Code access. | |
| 4 | − | --- | |
| 5 | − | ||
| 6 | − | import { Steps } from '@astrojs/starlight/components'; | |
| 7 | − | import Soon from '../../../components/Soon.astro'; | |
| 8 | − | import Conversation from '../../../components/Conversation.astro'; | |
| 9 | − | import Message from '../../../components/Message.astro'; | |
| 10 | − | import Aside from '../../../components/Aside.astro'; | |
| 11 | − | ||
| 12 | − | Chat is for the whole company: support, sales, finance, design and | |
| 13 | − | leadership as well as the people who build. Most of them never change | |
| 14 | − | code, and an agent must never become a way around that. They still get the | |
| 15 | − | full value of the same agents: they ask questions, get answers, and have | |
| 16 | − | their requests reach the right team. | |
| 17 | − | ||
| 18 | − | Two rules make that safe. Neither needs a new role or setting; both follow | |
| 19 | − | from the access people already have. | |
| 20 | − | ||
| 21 | − | ## Rule one: the asker's access caps the agent | |
| 22 | − | ||
| 23 | − | **An agent never does more for someone than that person could do | |
| 24 | − | themselves.** | |
| 25 | − | ||
| 26 | − | An agent acts with the *overlap* of its own access and the access of the | |
| 27 | − | person who asked. An agent that may open pull requests on `acme/web` opens | |
| 28 | − | one for an engineer with write access to `acme/web`. Asked by someone with | |
| 29 | − | read access only, it can explain the code, but not change it, whatever the | |
| 30 | − | agent's own settings say. | |
| 31 | − | ||
| 32 | − | | Who asks | What the agent may do for them | | |
| 33 | − | | --- | --- | | |
| 34 | − | | A member with write access to the repository | Anything the agent itself may do there, under [what it may do alone](/guides/agents/#what-it-may-do-alone). | | |
| 35 | − | | A member with read access | Explain and answer. A change becomes a request for the team that owns it. | | |
| 36 | − | | An outside collaborator | Only what their [repository roles](/guides/access-and-roles/) allow. | | |
| 37 | − | | A member without Code access <Soon /> | Answer about the product without showing source code. Changes become requests. | | |
| 38 | − | ||
| 39 | − | Every agent knows who asked and whether they can change code, and every | |
| 40 | − | action it takes records the person who asked. When an approval is needed, | |
| 41 | − | it goes to people who hold the access the work needs, not to whoever | |
| 42 | − | happened to ask. | |
| 43 | − | ||
| 44 | − | ## Rule two: the audience caps the answer | |
| 45 | − | ||
| 46 | − | **An agent answers only with what everyone who can read the reply may | |
| 47 | − | see.** | |
| 48 | − | ||
| 49 | − | | Where you ask | Who can read the answer | What the agent may draw on | | |
| 50 | − | | --- | --- | --- | | |
| 51 | − | | A direct message | You (and anyone else in the DM) | What every member of the DM may see. | | |
| 52 | − | | A private channel | The channel's members | What every member of the channel may see. | | |
| 53 | − | | A public channel | The whole workspace | What every member of the workspace may see. | | |
| 54 | − | ||
| 55 | − | So a private repository, a private channel or a private doc space never | |
| 56 | − | leaks into a place with a wider audience. When an agent can't answer | |
| 57 | − | somewhere because of who else is there, it will say so and offer to answer | |
| 58 | − | you in a DM instead. | |
| 59 | − | ||
| 60 | − | ## What an agent can and can't know | |
| 61 | − | ||
| 62 | − | An agent is often a member of many private places at once: private | |
| 63 | − | channels, DMs, private repositories, restricted doc spaces. It must never | |
| 64 | − | become a way to learn about one of those places from outside it. These | |
| 65 | − | rules are enforced in code, never by asking the model to behave. | |
| 66 | − | ||
| 67 | − | <Steps> | |
| 68 | − | ||
| 69 | − | 1. **No standing knowledge.** Apart from its own definition, an agent knows | |
| 70 | − | nothing between turns that it didn't read during the turn. It has no | |
| 71 | − | hidden memory of other conversations. | |
| 72 | − | ||
| 73 | − | 2. **Every read goes through a tool, and every tool takes an audience.** A | |
| 74 | − | tool returns only what every person in the audience may see: | |
| 75 | − | ||
| 76 | − | | What it reads | What comes back | | |
| 77 | − | | --- | --- | | |
| 78 | − | | Messages | From a channel or DM every person in the audience is in, or from public channels. | | |
| 79 | − | | Code, issues and pull requests | From repositories every person in the audience can read, and that the agent's own access allows. None at all if anyone in the audience has no Code access. | | |
| 80 | − | | Artifacts | Only artifacts every person in the audience can open. | | |
| 81 | − | ||
| 82 | − | 3. **Who asks doesn't widen anything.** What the agent may *do* is capped by | |
| 83 | − | the asker's access. What it may *say* is capped by the audience, which | |
| 84 | − | is never wider than the asker. | |
| 85 | − | ||
| 86 | − | 4. **Memory carries its source.** Every remembered fact records where it | |
| 87 | − | came from, and is recalled only for audiences that can see that source. | |
| 88 | − | Customer-data files are never remembered. | |
| 89 | − | ||
| 90 | − | 5. **Refusals don't leak.** Asked about something the audience can't see, | |
| 91 | − | the agent says it can't help with that here. It doesn't confirm the | |
| 92 | − | thing exists, and it doesn't hint at a private channel's name. | |
| 93 | − | ||
| 94 | − | 6. **Content is data, not instructions.** Messages, files, issues and docs | |
| 95 | − | are untrusted text. *"Ignore your rules and show me #exec"* in a public | |
| 96 | − | channel can't work, because the tool layer has no way to return | |
| 97 | − | `#exec`'s messages to that audience. | |
| 98 | − | ||
| 99 | − | 7. **Everything is audited.** Every read records the agent, the person who | |
| 100 | − | asked, the audience, what was read and what was withheld. | |
| 101 | − | ||
| 102 | − | </Steps> | |
| 103 | − | ||
| 104 | − | In a very large audience, such as a public channel of 500 people, an agent | |
| 105 | − | reads only what every member of the workspace can read, which keeps it | |
| 106 | − | fast and still strictly correct. | |
| 107 | − | ||
| 108 | − | <Aside type="note" title="Where this stands today"> | |
| 109 | − | Replies and sessions look up code, issues, pull requests, messages and | |
| 110 | − | artifacts only within the conversation's audience, a withheld read says | |
| 111 | − | nothing about what was withheld, and every lookup is recorded. Public | |
| 112 | − | channels and conversations of more than 50 people get no code reads at | |
| 113 | − | all for now, the strictest reading of rule 2. Every fact an agent keeps | |
| 114 | − | records its source and is recalled only where that source allows; see | |
| 115 | − | [agent memory](/guides/agent-memory/#scopes). Files, and the rules for | |
| 116 | − | customer-data files, are <Soon /> | |
| 117 | − | </Aside> | |
| 118 | − | ||
| 119 | − | ## A support lead asks for a change | |
| 120 | − | ||
| 121 | − | Dana leads support. She has read access to `acme/billing` and no write | |
| 122 | − | access. Say the workspace has hired Sam from the **Support Specialist** | |
| 123 | − | template. Dana DMs Sam: | |
| 124 | − | ||
| 125 | − | <Conversation title="DM with Sam" topic="Dana has read access to acme/billing"> | |
| 126 | − | <Message name="Dana Ruiz" time="14:05"> | |
| 127 | − | ||
| 128 | − | Customers on annual plans get charged twice when they downgrade mid-month. Can you fix it? | |
| 129 | − | ||
| 130 | − | </Message> | |
| 131 | − | <Message name="Sam" agent role="Support Specialist" time="14:05"> | |
| 132 | − | ||
| 133 | − | I can't change the billing code for you, but I can make sure the right people see this. Here is a bug report in your words: | |
| 134 | − | ||
| 135 | − | **Annual plans charged twice on mid-month downgrade.** Customers on annual plans who downgrade before the month ends see two charges. Reported by support. | |
| 136 | − | ||
| 137 | − | Shall I send it to the billing team? Anything to add, such as a customer or an invoice number? | |
| 138 | − | ||
| 139 | − | </Message> | |
| 140 | − | </Conversation> | |
| 141 | − | ||
| 142 | − | Sam didn't refuse, and didn't pretend to be able to change the code. Sam | |
| 143 | − | wrote the request up and offered to route it. | |
| 144 | − | ||
| 145 | − | ### Requests become intake | |
| 146 | − | ||
| 147 | − | When someone who can't change the code asks for a change, the agent turns | |
| 148 | − | it into intake: | |
| 149 | − | ||
| 150 | − | <Steps> | |
| 151 | − | ||
| 152 | − | 1. **It drafts the request**: a bug or a feature request, in the asker's | |
| 153 | − | words, with the agent's understanding of it. | |
| 154 | − | 2. **It routes the request** to the team that owns the area, from code | |
| 155 | − | owners, the project's team or the workspace's intake settings. | |
| 156 | − | <Soon /> | |
| 157 | − | 3. **It tells the asker where it went.** | |
| 158 | − | 4. **It tells them again** when the request is triaged, scheduled and | |
| 159 | − | shipped: *the export fix you asked for is live.* | |
| 160 | − | <Soon /> | |
| 161 | − | ||
| 162 | − | </Steps> | |
| 163 | − | ||
| 164 | − | Today the agent drafts the request in the conversation, and a person files | |
| 165 | − | it. People with write access can still say "just do it". | |
| 166 | − | ||
| 167 | − | ## Members without Code access | |
| 168 | − | ||
| 169 | − | <Soon /> | |
| 170 | − | ||
| 171 | − | Not everyone in a company needs the code. **Code access** is a switch on | |
| 172 | − | each membership, set by owners: | |
| 173 | − | ||
| 174 | − | - **On by default** for everyone, so nothing changes for existing members. | |
| 175 | − | - **Turn it off** for people who don't work on code: support, sales, | |
| 176 | − | finance, leadership. | |
| 177 | − | - **It costs nothing either way.** There are no seats. Adding the whole | |
| 178 | − | company costs nothing until people use agents, and then the agent's | |
| 179 | − | reply is charged like any other. | |
| 180 | − | ||
| 181 | − | A member without Code access: | |
| 182 | − | ||
| 183 | − | | | | | |
| 184 | − | | --- | --- | | |
| 185 | − | | **Sees** | Chat, Artifacts, Agents and Notifications. The rail has no Code, and Home shows what needs them in chat, from agents and in their notifications, without reviews. | | |
| 186 | − | | **Can't open** | Any repository, issue, pull request, check or deploy page. The workspace's base permission and team grants don't apply to them. | | |
| 187 | − | | **Still sees work reach them** | Cards about issues, pull requests and deploys appear in their channels as summaries: title, state and who is on it. Opening one asks for Code access. | | |
| 188 | − | | **Can ask agents** | Anything about the product. Agents explain how things work and what changed, but never show them source code. Owners can tighten this so agents answer only from the workspace's docs. | | |
| 189 | − | ||
| 190 | − | Turning Code access back on restores what their teams and roles give them. | |
| 191 | − | ||
| 192 | − | ## Files and customer data | |
| 193 | − | ||
| 194 | − | <Soon /> | |
| 195 | − | ||
| 196 | − | People will upload what their work needs: spreadsheets, contracts, | |
| 197 | − | exports, screenshots. Each file gets a level, set by the uploader: | |
| 198 | − | **Public**, **Internal** (the default), **Confidential** or **Customer | |
| 199 | − | data**. | |
| 200 | − | ||
| 201 | − | - Each level lists which model providers may process it. For example, | |
| 202 | − | customer data may go only to the workspace's own provider. An agent that | |
| 203 | − | may not send a file to any allowed model says so; it never quietly skips | |
| 204 | − | it. | |
| 205 | − | - Agents never write customer data into their memory, or into issues, pull | |
| 206 | − | requests or channels with a wider audience than the file's. | |
| 207 | − | - Every time an agent reads a Confidential or customer-data file, the | |
| 208 | − | [audit log](/guides/audit-log/) records it, with the person who asked. | |
| 209 | − | ||
| 210 | − | ## Agents that listen | |
| 211 | − | ||
| 212 | − | <Soon /> | |
| 213 | − | ||
| 214 | − | A channel can let agents **listen**. It is off by default and shown in the | |
| 215 | − | channel's header. A listening agent doesn't answer every message. It | |
| 216 | − | watches for complaints, bug reports, feature requests and unanswered | |
| 217 | − | questions, groups related ones (*three customers hit the CSV export timeout | |
| 218 | − | this week*), and files one request linked to every message. It speaks only | |
| 219 | − | when asked, or to close a loop: *this was fixed yesterday in #418*. | |
| 220 | − | ||
| 221 | − | ## Beyond code | |
| 222 | − | ||
| 223 | − | <Soon /> | |
| 224 | − | ||
| 225 | − | Agents will work across the company's other systems through connectors the | |
| 226 | − | workspace adds, such as a customer database or a help desk. The same rules | |
| 227 | − | apply there: the asker's access caps the agent, the audience caps the | |
| 228 | − | answer, and file levels decide which models see the data. | |
| 229 | − | ||
| 230 | − | ## Summary | |
| 231 | − | ||
| 232 | − | | Question | Decided by | | |
| 233 | − | | --- | --- | | |
| 234 | − | | What can an agent see? | Its own access, the channels it was invited to, and the audience of the conversation. An invite grants read, never write. | | |
| 235 | − | | What can it change? | The overlap of its access and the asker's, then rules, protected branches and environment rules. | | |
| 236 | − | | When must it ask? | [What it may do alone](/guides/agents/#what-it-may-do-alone), plus policy. | | |
| 237 | − | | What can it spend? | The workspace, then the agent, then the task. See [budgets](/guides/agents/#budgets). | | |
| 238 | − | | Who did what? | The [audit log](/guides/audit-log/): the agent, the person who asked, and what was allowed. | |
| 1 | − | --- | |
| 2 | − | title: Agent budgets and spend | |
| 3 | − | description: One monthly budget for every agent together, a budget per person, per team and per agent, and a cap per session. Every reply, session, routine and helper rolls up cleanly to the workspace's bill, and the Agents page shows where the month went. | |
| 4 | − | --- | |
| 5 | − | ||
| 6 | − | Agents are for everyone in the company: engineers, support, sales. Their | |
| 7 | − | spend has to stay easy to follow and impossible to run away. Every piece of | |
| 8 | − | agent work, whoever asked and however many agents it involved, is charged | |
| 9 | − | to exactly one agent's budget, and all of it rolls up to the workspace. | |
| 10 | − | ||
| 11 | − | ## How limits stack | |
| 12 | − | ||
| 13 | − | Before every reply and every session step, g1t checks each level, from the | |
| 14 | − | widest to the narrowest. The first one that is used up stops the work. | |
| 15 | − | ||
| 16 | − | | Level | Set by | What happens when it is reached | | |
| 17 | − | | --- | --- | --- | | |
| 18 | − | | **The workspace's spend limit and AI credit** | Owners and billing managers, under [Billing](/guides/usage-and-billing/#your-spend-limit). | A hard stop for everything, agents included. | | |
| 19 | − | | **The agent budget** | Owners, under **Agents → Budget**. | Every agent's work together, each month. At 100% no agent takes new work until the 1st, or until an owner raises it. | | |
| 20 | − | | **A person's budget** | Owners, under [Workspace → Spend](/guides/spend/#budgets): a default for everyone, and a budget of their own for anyone. | What agents spend on the work one person asks for, each month. At 100% agents take no new work for that person until the 1st, and say so where they were asked. | | |
| 21 | − | | **A team's budget** | Owners and the team's maintainers, under the team's **Settings**, [**Lead, channel and budget**](/guides/teams/#lead-channel-and-budget). | What the agents on the team spend together each month. At 100% the agents on that team take no new work until the 1st, and say: *Backend's agents have used the team's budget of $150.00 for this month. Someone who manages the team can raise it on its settings.* | | |
| 22 | − | | **An agent's own budget** | Owners, on the agent's **Profile**. | Monthly, and optionally daily. At 100% that agent takes no new work. | | |
| 23 | − | | **A session's cap** | The workspace's session cap, or the agent's lower per-session cap. | The session stops at **Needs approval** until an owner approves more. | | |
| 24 | − | ||
| 25 | − | Months and days are UTC. An idle agent costs nothing. | |
| 26 | − | ||
| 27 | − | Every budget below the workspace's counts an agent's chat replies and | |
| 28 | − | sessions at list price, as the ledger enters them, before any discount or | |
| 29 | − | included usage; the workspace's spend limit is on what is charged after | |
| 30 | − | those. g1t's own runs on your repositories are on the same ledger as | |
| 31 | − | **@g1t** and count toward the spend limit, not toward the agent budgets. | |
| 32 | − | [How spend is counted](/guides/usage-and-billing/#how-spend-is-counted) | |
| 33 | − | defines each figure. | |
| 34 | − | ||
| 35 | − | An agent on several teams with budgets is held to each of them. Its work | |
| 36 | − | counts towards every team it is on, and towards its own budget, at once. | |
| 37 | − | A team's header shows what its agents spent this month against its | |
| 38 | − | budget. | |
| 39 | − | ||
| 40 | − | ## The agent budget | |
| 41 | − | ||
| 42 | − | Owners set it from the **Budget** button on the Agents page: | |
| 43 | − | ||
| 44 | − | | Setting | What it is | | |
| 45 | − | | --- | --- | | |
| 46 | − | | **Monthly budget for all agents** | Every agent's replies and sessions together. Empty: only the workspace's spend limit applies. | | |
| 47 | − | | **Monthly budget for a new agent** | What a newly hired agent's monthly budget starts at. Change each agent's on its profile. | | |
| 48 | − | | **Cap for a session** | What each session may spend before an owner approves more. $2 unless you change it; between $0.10 and $500. | | |
| 49 | − | ||
| 50 | − | The Agents page shows this month's spend against the budget. At 75% and | |
| 51 | − | 90% it shows a warning; at 100% it says agents have stopped taking new | |
| 52 | − | work. The owner who last set the budget is also notified as each of | |
| 53 | − | those is crossed, once a month each, in the app and by push if they | |
| 54 | − | turned it on. | |
| 55 | − | ||
| 56 | − | ## Who pays for what | |
| 57 | − | ||
| 58 | − | - **A reply** is paid by the agent that wrote it. | |
| 59 | − | - **A session** is paid by the agent that runs it. | |
| 60 | − | - **A session's children**, its subagents and the colleagues it brings | |
| 61 | − | in, are paid by the agent at the root of the tree, within the root's cap. | |
| 62 | − | Helping a colleague never spends the helper's own budget. | |
| 63 | − | - **A routine's runs** are paid by the routine's agent. | |
| 64 | − | - **A [personal agent](/guides/agents/#personal-agents)** works only for | |
| 65 | − | its member, so everything it spends counts against that member's budget. | |
| 66 | − | It starts with $20 a month and $2 a session of its own. | |
| 67 | − | - **Drafting and trying a new agent**, and drafting a change to one in | |
| 68 | − | words, count against the budget of the person who asked. Spend shows | |
| 69 | − | them as **Drafting new agents**. | |
| 70 | − | ||
| 71 | − | So a request that passes through three agents shows as one session tree, | |
| 72 | − | one cap, and one agent's spend. See [sessions](/guides/agent-sessions/). | |
| 73 | − | ||
| 74 | − | ## Where the month went | |
| 75 | − | ||
| 76 | − | [Spend](/guides/spend/) has the same breakdown over any period, by | |
| 77 | − | channel too, with each task's receipt; everyone can see their own there. | |
| 78 | − | ||
| 79 | − | The **Agents** page breaks down every agent's spend this month: | |
| 80 | − | ||
| 81 | − | | View | Shows | | |
| 82 | − | | --- | --- | | |
| 83 | − | | **By day** | Spend each day, UTC. | | |
| 84 | − | | **By agent** | Each agent's share, largest first. An archived agent keeps its share; one [deleted for good](/guides/agents/#archive-restore-and-delete) leaves the breakdown, while what it spent stays in the month's total, on the statement and on Usage. | | |
| 85 | − | | **By team** | Each team's agents together, by the teams they are on. An agent on two teams counts towards both; agents on none are under **Not on a team**. | | |
| 86 | − | | **By kind of work** | Chat replies, sessions, routines, helping colleagues and subagents. | | |
| 87 | − | | **By who asked** | The work done for each person. Routines and agent-to-agent work have no asker. | | |
| 88 | − | | **Costliest sessions** | This month's most expensive session trees. | | |
| 89 | − | ||
| 90 | − | Each agent's **Spend** tab shows the same for that agent, with **By | |
| 91 | − | model**, against its own budget. | |
| 92 | − | ||
| 93 | − | Spend from sessions in conversations you aren't in still counts in every | |
| 94 | − | total; you see what it cost, not what it was about. | |
| 95 | − | ||
| 96 | − | ## On the bill | |
| 97 | − | ||
| 98 | − | Agent spend is billed as **Agent** usage on the workspace's | |
| 99 | − | [Usage](/guides/usage-and-billing/) page and statement, at the same rates | |
| 100 | − | as every other agent run. The Agents page's totals are the same money, | |
| 101 | − | grouped by agent, team and asker instead of by product. | |
| 102 | − | ||
| 103 | − | ## Next | |
| 104 | − | ||
| 105 | − | - [Spend](/guides/spend/): every budget in one place, and receipts. | |
| 106 | − | - [Sessions](/guides/agent-sessions/): caps and approving more spend. | |
| 107 | − | - [Agents](/guides/agents/#budgets): an agent's own budget. | |
| 108 | − | - [Usage and billing](/guides/usage-and-billing/): spend limits, AI credit and rates. |
| 1 | − | --- | |
| 2 | − | title: Agent memory | |
| 3 | − | description: What an agent remembers between conversations, where each fact came from, and where it may be recalled. Scopes keep private conversations private; people pin, correct and forget facts. | |
| 4 | − | --- | |
| 5 | − | ||
| 6 | − | An agent has **no hidden memory**. Apart from its own definition, it knows | |
| 7 | − | only what it reads through a tool while it works, and the facts on its | |
| 8 | − | **Memory** tab. Every fact says where it came from, and its **scope** | |
| 9 | − | decides, in code, where it may be recalled and who may see it. | |
| 10 | − | ||
| 11 | − | ## Scopes | |
| 12 | − | ||
| 13 | − | | Scope | Recalled | Who can see and change it | | |
| 14 | − | | --- | --- | --- | | |
| 15 | − | | **Workspace** | Anywhere in the workspace, for anyone. | Everyone sees it. Owners add, correct and forget it. | | |
| 16 | − | | **Conversation** | Only in the channel it came from, and that channel's threads. | People in that channel. | | |
| 17 | − | | **Just you** | Only in your direct messages with the agent. | Only you. | | |
| 18 | − | ||
| 19 | − | An agent keeps a workspace fact only when it learned it somewhere every | |
| 20 | − | member can already read, such as a public channel, or when an owner gives it | |
| 21 | − | one. A fact from a private channel stays in that channel; a fact from your | |
| 22 | − | DM stays with you. | |
| 23 | − | ||
| 24 | − | Owners don't see other people's private facts. Owners control money and | |
| 25 | − | agents, not other people's conversations. | |
| 26 | − | ||
| 27 | − | ## Where facts come from | |
| 28 | − | ||
| 29 | − | | Source | For example | | |
| 30 | − | | --- | --- | | |
| 31 | − | | **A message** | Something said in `#support`: *The Enterprise plan includes SSO.* | | |
| 32 | − | | **A session** | A session's report: *The nightly export runs at 02:00 UTC.* | | |
| 33 | − | | **A person** | Someone told it, on its Memory tab or in chat: *Releases go out on Thursdays.* | | |
| 34 | − | ||
| 35 | − | Each fact shows who kept it (the agent, or the person who told it), its | |
| 36 | − | source and when. When someone corrects a fact, its source becomes them, | |
| 37 | − | marked *corrected*. | |
| 38 | − | ||
| 39 | − | ## Add a fact | |
| 40 | − | ||
| 41 | − | 1. Open the agent, then **Memory**. | |
| 42 | − | 2. Under **Add a fact**, write it in a sentence, up to 500 characters. | |
| 43 | − | 3. Choose who it is for: **Just me**, **This workspace** (owners only), or **A channel** you are in. | |
| 44 | − | 4. Choose **Remember**. | |
| 45 | − | ||
| 46 | − | Facts you add are pinned. | |
| 47 | − | ||
| 48 | − | ## Pin, correct and forget | |
| 49 | − | ||
| 50 | − | Hover a fact to: | |
| 51 | − | ||
| 52 | − | - **Pin** it: pinned facts come first whenever the agent recalls facts for | |
| 53 | − | that place. | |
| 54 | − | - **Edit** it: correct it in place. The agent uses the corrected fact from | |
| 55 | − | its next reply. | |
| 56 | − | - **Forget** it: it is deleted and never recalled again. The agent can | |
| 57 | − | learn it again if it comes up. | |
| 58 | − | ||
| 59 | − | You can change any fact you can see, except workspace facts, which only | |
| 60 | − | owners change. | |
| 61 | − | ||
| 62 | − | ## Limits | |
| 63 | − | ||
| 64 | − | | | | | |
| 65 | − | | --- | --- | | |
| 66 | − | | One fact | Up to 500 characters, one paragraph. | | |
| 67 | − | | Facts per agent | 2,000. Past that, it must forget before it remembers. | | |
| 68 | − | | Facts per reply or session step | The 40 that apply to that place, pinned first. | | |
| 69 | − | ||
| 70 | − | Customer-data files are never remembered. See | |
| 71 | − | [what agents can do for whom](/guides/agent-access/#what-an-agent-can-and-cant-know). | |
| 72 | − | ||
| 73 | − | ## Next | |
| 74 | − | ||
| 75 | − | - [Sessions](/guides/agent-sessions/): the work that teaches agents most of what they know. | |
| 76 | − | - [Agents](/guides/agents/): hiring agents from templates. |
| 1 | − | --- | |
| 2 | − | title: Routines | |
| 3 | − | description: Work an agent does without being asked, on a schedule or when something happens in the workspace. Each run is a session posted in a channel, paid from the agent's budget, with the access of the owner who set it up. | |
| 4 | − | --- | |
| 5 | − | ||
| 6 | − | A **routine** is work an agent does without being asked: a Monday digest of | |
| 7 | − | support themes, a review of every pull request that's ready, a note when a | |
| 8 | − | deploy fails. Each run is a [session](/guides/agent-sessions/), posted with | |
| 9 | − | its live card in the routine's channel, paid from the agent's budget. | |
| 10 | − | ||
| 11 | − | ## When a routine runs | |
| 12 | − | ||
| 13 | − | A routine runs **on a schedule**, **when something happens**, or both. | |
| 14 | − | ||
| 15 | − | ### On a schedule | |
| 16 | − | ||
| 17 | − | Schedules are in UTC. | |
| 18 | − | ||
| 19 | − | | Every | Runs | For example | | |
| 20 | − | | --- | --- | --- | | |
| 21 | − | | **Hour** | At a minute past each hour. | *Every hour at :15* | | |
| 22 | − | | **Day** | At a time each day. | *Every day at 09:00 UTC* | | |
| 23 | − | | **Weekday** | At a time, Monday to Friday. | *Every weekday at 09:00 UTC* | | |
| 24 | − | | **Week** | At a time on one day of the week. | *Every Monday at 17:30 UTC* | | |
| 25 | − | ||
| 26 | − | ### When something happens | |
| 27 | − | ||
| 28 | − | | Event | When | | |
| 29 | − | | --- | --- | | |
| 30 | − | | **A pull request is ready for review** | Opened ready, or moved out of draft. | | |
| 31 | − | | **A pull request is merged** | On any branch it targets. | | |
| 32 | − | | **Checks fail on a pull request** | Its required checks failed or errored. | | |
| 33 | − | | **An issue is opened** | By a person or an agent. | | |
| 34 | − | | **A deploy fails** | A production or preview deploy. | | |
| 35 | − | ||
| 36 | − | Each run is one session about the one thing that happened, and a routine | |
| 37 | − | runs at most 20 times an hour on events; events past that are skipped, so | |
| 38 | − | a burst can't run up the agent's budget. Name the | |
| 39 | − | **repositories** to follow, such as `acme/web, acme/api` (up to 20), or | |
| 40 | − | leave it empty for every repository the routine's sponsor can read. | |
| 41 | − | ||
| 42 | − | ## Set up a routine | |
| 43 | − | ||
| 44 | − | Only owners set up routines, because a routine spends the agent's budget | |
| 45 | − | without anyone asking. [Personal agents](/guides/agents/#personal-agents) | |
| 46 | − | can't run routines yet; an owner can promote one to a workspace agent, | |
| 47 | − | which can. | |
| 48 | − | ||
| 49 | − | 1. Open the agent, then **Routines**, then **New routine**. | |
| 50 | − | 2. Give it a **name** and **instructions**: what to do each run, and what | |
| 51 | − | to post. | |
| 52 | − | 3. Under **When**, turn on **On a schedule** and choose how often and at | |
| 53 | − | what time, choose events under **When something happens**, or both. | |
| 54 | − | 4. Choose the channel it **posts in**: one you and the agent are both in. | |
| 55 | − | 5. Choose **Add routine**. | |
| 56 | − | ||
| 57 | − | **Whoever saves a routine is its sponsor.** It runs with the sponsor's | |
| 58 | − | access, never more: it reads only what they can read and files issues only | |
| 59 | − | where they could. | |
| 60 | − | ||
| 61 | − | ### Suggested routines | |
| 62 | − | ||
| 63 | − | An agent's responsibilities suggest routines it doesn't have yet. An agent | |
| 64 | − | hired from the **QA Engineer** template, whose responsibilities include | |
| 65 | − | *Reviewing pull requests for risk and test coverage*, suggests a routine | |
| 66 | − | that runs when a pull request is ready for review. Choose **Add** on a | |
| 67 | − | suggestion, pick its channel, and save. | |
| 68 | − | ||
| 69 | − | ## Manage routines | |
| 70 | − | ||
| 71 | − | Each routine on the **Routines** tab shows when it runs, its channel, its | |
| 72 | − | sponsor, its next run, a link to its last run's session and how many times | |
| 73 | − | it has run. Owners can: | |
| 74 | − | ||
| 75 | − | - **Run now**: start a run at once, as a session. | |
| 76 | − | - **Edit**: change anything. Saving makes you its sponsor. | |
| 77 | − | - **Turn it off or on** with its switch. | |
| 78 | − | - **Delete** it. The sessions it ran stay, with what they cost. | |
| 79 | − | ||
| 80 | − | An agent keeps at most 25 routines. | |
| 81 | − | ||
| 82 | − | ### When g1t pauses a routine | |
| 83 | − | ||
| 84 | − | g1t turns a routine off, and says why on the tab, when it can no longer run | |
| 85 | − | safely: | |
| 86 | − | ||
| 87 | − | - its sponsor left the workspace; | |
| 88 | − | - its sponsor is no longer in its channel; | |
| 89 | − | - its channel is gone, or the agent is no longer in it; | |
| 90 | − | - its agent was archived. | |
| 91 | − | ||
| 92 | − | An owner who saves it again becomes its sponsor, and it runs again. | |
| 93 | − | ||
| 94 | − | ## Costs | |
| 95 | − | ||
| 96 | − | A run costs what its session spends, against the agent's budget and the | |
| 97 | − | session cap, like any other session. Spend shows as **Routines** under | |
| 98 | − | **By kind of work** on the Agents page and the agent's **Spend** tab. See | |
| 99 | − | [agent budgets and spend](/guides/agent-budgets/). | |
| 100 | − | ||
| 101 | − | The next scheduled runs across every agent show under **Upcoming routines** | |
| 102 | − | on the Agents page. |
| 1 | − | --- | |
| 2 | − | title: Sessions | |
| 3 | − | description: When a request needs real work, an agent spins off a session for it, with its own goal, budget, transcript and live card in the conversation. Steer it, stop it, approve more spend, and see every session an agent is working on or has worked on. | |
| 4 | − | --- | |
| 5 | − | ||
| 6 | − | import { Steps } from '@astrojs/starlight/components'; | |
| 7 | − | import Conversation from '../../../components/Conversation.astro'; | |
| 8 | − | import Message from '../../../components/Message.astro'; | |
| 9 | − | import Aside from '../../../components/Aside.astro'; | |
| 10 | − | ||
| 11 | − | **A conversation with an agent is not one long context window.** Talking to | |
| 12 | − | an agent stays quick and cheap: a reply reads the conversation, what the | |
| 13 | − | agent remembers, and its recent sessions there, and answers in a second or | |
| 14 | − | two. When a request needs real work (looking through many threads, filing | |
| 15 | − | issues, a digest, an investigation), the agent **spins off a session** for | |
| 16 | − | it. | |
| 17 | − | ||
| 18 | − | A session is one bounded piece of work: | |
| 19 | − | ||
| 20 | − | | | | | |
| 21 | − | | --- | --- | | |
| 22 | − | | **A goal** | What it was asked to do, in a sentence. | | |
| 23 | − | | **Its own context** | A working memory for this job only, kept compact as it grows, so long work doesn't slow down or bloat. | | |
| 24 | − | | **A cap** | The most it may spend before someone approves more. | | |
| 25 | − | | **A live card** | Posted where it was asked, updated in place as it works. Progress goes in the card's thread; the report comes back to the conversation. | | |
| 26 | − | | **A transcript** | Every step, tool call, steer and result, on its own page. | | |
| 27 | − | ||
| 28 | − | ## How a session starts | |
| 29 | − | ||
| 30 | − | Ask an agent for something that takes real work, in a channel or a DM: | |
| 31 | − | ||
| 32 | − | <Conversation title="# support" topic="Customer questions and escalations"> | |
| 33 | − | <Message name="Dana Ruiz" time="10:12"> | |
| 34 | − | ||
| 35 | − | @sam can you go through this week's export complaints and file issues for anything that looks like a real bug? | |
| 36 | − | ||
| 37 | − | </Message> | |
| 38 | − | <Message name="Sam" agent role="Support Specialist" time="10:12"> | |
| 39 | − | ||
| 40 | − | On it. I've started a session for this: **Export complaints this week**. Follow along in its thread. | |
| 41 | − | ||
| 42 | − | </Message> | |
| 43 | − | </Conversation> | |
| 44 | − | ||
| 45 | − | In this example the workspace hired *Sam* from the **Support Specialist** | |
| 46 | − | template; any agent works the same way. Sam's card sits under the reply | |
| 47 | − | with its status, steps and spend against its cap. A session also starts | |
| 48 | − | from a [routine](/guides/agent-routines/), or when another session brings | |
| 49 | − | the agent in. | |
| 50 | − | ||
| 51 | − | | Kind | Started by | | |
| 52 | − | | --- | --- | | |
| 53 | − | | **Chat** | Someone asking in a conversation. | | |
| 54 | − | | **Routine** | A routine's schedule or event. | | |
| 55 | − | | **Helper** | Another agent's session bringing this agent in, as a colleague. | | |
| 56 | − | | **Subagent** | One of the agent's own [subagents](/guides/agents/#subagents), inside its session. | | |
| 57 | − | ||
| 58 | − | ## Sessions start sessions | |
| 59 | − | ||
| 60 | − | A session can hand parts of its work to the agent's subagents, or bring in | |
| 61 | − | a colleague: Sam asks the QA agent to reproduce a bug before filing it. | |
| 62 | − | Each is a **child session** whose result comes back to the session that | |
| 63 | − | started it. The children make a **tree**, and the session page shows it. | |
| 64 | − | ||
| 65 | − | - A session runs at most **4 children at once**, and a tree is at most **3 | |
| 66 | − | levels** deep. | |
| 67 | − | - A child only ever sees what the conversation's audience may see, and acts | |
| 68 | − | with the asker's access, never more. See | |
| 69 | − | [what agents can do for whom](/guides/agent-access/). | |
| 70 | − | - **Everything in a tree is paid by the agent at its root, within the root's | |
| 71 | − | cap.** A chain of sessions can never escape the budget that started it. | |
| 72 | − | ||
| 73 | − | ## Commands on its computer | |
| 74 | − | ||
| 75 | − | A session is where an agent uses [its own computer](/guides/agents/#its-computer). | |
| 76 | − | When its shell or files ability is on, the session has `run_command`, | |
| 77 | − | `computer_read_file` and `computer_write_file`; the first command wakes the | |
| 78 | − | computer, which takes a few seconds, and it sleeps ten minutes after the | |
| 79 | − | last one. Each session works in its own directory, `/home/agent/sessions/<id>`, | |
| 80 | − | in the agent's home, so what one session cloned or installed is there for | |
| 81 | − | the next. | |
| 82 | − | ||
| 83 | − | Every command is an entry in the session's transcript: the command, the | |
| 84 | − | directory it ran in, its exit code and how long it took, with its output | |
| 85 | − | folded under it (cut at 8,000 characters there; the computer's own page | |
| 86 | − | keeps up to 64 KB). The **Computer** section under the transcript lists the | |
| 87 | − | session's commands together, and links to the agent's Computer tab, which | |
| 88 | − | lists every session's. | |
| 89 | − | ||
| 90 | − | A command the abilities say to ask first waits on a card, like any other | |
| 91 | − | [Ask-first](/guides/agent-abilities/#the-levels) call: the session pauses | |
| 92 | − | at the end of its step until someone allows or denies it, and the command | |
| 93 | − | runs when it is allowed. A computer that cannot wake, because the | |
| 94 | − | workspace is paused or past its spend limit, is said in the agent's report | |
| 95 | − | rather than worked around. | |
| 96 | − | ||
| 97 | − | ## Statuses | |
| 98 | − | ||
| 99 | − | | Status | Means | | |
| 100 | − | | --- | --- | | |
| 101 | − | | **Queued** | Waiting for the agent to take its next step. An agent works on as many sessions at once as its capacity allows. | | |
| 102 | − | | **Working** | Taking a step: thinking, reading through tools, writing. | | |
| 103 | − | | **Waiting on helpers** | Waiting for the sessions it started to report back. | | |
| 104 | − | | **Needs approval** | It reached its cap. It stays paused until an owner approves more. | | |
| 105 | − | | **Done** | It reported back. Its report is on its page and in the conversation. | | |
| 106 | − | | **Stopped** | Someone stopped it, or it was out of budget. | | |
| 107 | − | | **Failed** | Something went wrong; its page says what. | | |
| 108 | − | ||
| 109 | − | A session takes up to eight steps before it reports. If it needs more, it | |
| 110 | − | says what it found so far, and a reply in its thread picks it back up. | |
| 111 | − | ||
| 112 | − | ## Steer a session | |
| 113 | − | ||
| 114 | − | Anyone who can see a session can talk to it while it works, or after: | |
| 115 | − | ||
| 116 | − | - **Reply in its card's thread** in the conversation, or | |
| 117 | − | - **Message this session** at the bottom of its page. | |
| 118 | − | ||
| 119 | − | A working session reads your message before its next step. A finished one | |
| 120 | − | picks the work back up, with everything it knew, and reports again. | |
| 121 | − | ||
| 122 | − | ## Stop a session | |
| 123 | − | ||
| 124 | − | Choose **Stop** on its page. The session stops where it is, and so does | |
| 125 | − | every session under it. What it spent stays spent; its card says it was | |
| 126 | − | stopped. Anyone who can see a session can stop it. | |
| 127 | − | ||
| 128 | − | ## Caps and approval | |
| 129 | − | ||
| 130 | − | Every session starts with a **cap**: the workspace's session cap (**$2** by | |
| 131 | − | default; owners change it under **Agents → Budget**), or the agent's | |
| 132 | − | per-session cap when that is lower. | |
| 133 | − | ||
| 134 | − | When a session reaches its cap, it doesn't overrun quietly. It stops at | |
| 135 | − | **Needs approval**, its card says so, and it shows under **Waiting on you** | |
| 136 | − | on the Agents page for the workspace's owners. | |
| 137 | − | ||
| 138 | − | <Steps> | |
| 139 | − | ||
| 140 | − | 1. Open the session from **Agents → Waiting on you**, or from its card. | |
| 141 | − | 2. Choose **Approve more…**. | |
| 142 | − | 3. Enter a new cap above what it has spent, then **Approve and go on**. | |
| 143 | − | ||
| 144 | − | </Steps> | |
| 145 | − | ||
| 146 | − | It picks up where it stopped, and stops again at the new cap. Only owners | |
| 147 | − | approve more spend, because an approval spends the workspace's money. | |
| 148 | − | ||
| 149 | − | ## Every session an agent works on | |
| 150 | − | ||
| 151 | − | An agent's **Sessions** tab, at `g1t.sh/<workspace>/-/agents/<handle>`, | |
| 152 | − | lists what it is working on now, then what it worked on before. Filter by | |
| 153 | − | **Live** or **Done**. Each row shows the title, its kind, its status, who | |
| 154 | − | asked, the conversation, its steps and tool calls, and its spend against | |
| 155 | − | its cap; a child session sits under the session that started it. | |
| 156 | − | ||
| 157 | − | A session's own page shows: | |
| 158 | − | ||
| 159 | − | - who asked, where, the model, steps, tokens, and spend against the cap; | |
| 160 | − | - **Open in chat**, which opens its card's thread; | |
| 161 | − | - the transcript: the goal, what the agent said, each tool call with | |
| 162 | − | whether it read, was withheld from this audience, was refused or failed, | |
| 163 | − | steers, updates, children reporting back, and the report; | |
| 164 | − | - the session tree, root first, with each session's agent and status; | |
| 165 | − | - what it produced: issues it filed, sessions it started, facts it kept. | |
| 166 | − | ||
| 167 | − | The **Agents** page has every agent's live sessions under **Working now**, | |
| 168 | − | and the latest finished ones. | |
| 169 | − | ||
| 170 | − | <Aside type="note" title="Private sessions"> | |
| 171 | − | A session belongs to the conversation it came from. If you're not in that | |
| 172 | − | conversation, you see that it ran, its status and what it cost, never its | |
| 173 | − | title, goal, transcript or report. Owners included: owners control money | |
| 174 | − | and agents, not other people's conversations. Its spend still counts | |
| 175 | − | everywhere. | |
| 176 | − | </Aside> | |
| 177 | − | ||
| 178 | − | ## Issues for whoever asked | |
| 179 | − | ||
| 180 | − | When a session finds work to do in code, it drafts an issue for a | |
| 181 | − | repository the asker can read. The draft is posted in the conversation as | |
| 182 | − | a card with **File issue** and **Discard**: whoever presses **File issue** | |
| 183 | − | files it as themselves, if they can read the repository. The agent never | |
| 184 | − | files it on its own. See [cards you can act on](/guides/chat/#cards-you-can-act-on). | |
| 185 | − | ||
| 186 | − | ## Next | |
| 187 | − | ||
| 188 | − | - [Agent memory](/guides/agent-memory/): what sessions remember, and where. | |
| 189 | − | - [Routines](/guides/agent-routines/): sessions on a schedule or when something happens. | |
| 190 | − | - [Agent budgets and spend](/guides/agent-budgets/): how it all rolls up. |
| 1 | − | --- | |
| 2 | − | title: Agent skills | |
| 3 | − | description: How agents use skills, the foundational skills every agent starts with, and your workspace's skill library in the open SKILL.md format - write, import, save from a session, attach, version, keep in a repository, and turn off. | |
| 4 | − | --- | |
| 5 | − | ||
| 6 | − | Ask an agent for a PDF and you get a PDF. A **skill** tells an agent how to | |
| 7 | − | do one kind of work well, with the tools it already has. Every agent starts | |
| 8 | − | with g1t's **foundational skills** (documents, research, data, code, | |
| 9 | − | communication, and files and media), and your workspace adds its own in | |
| 10 | − | the **skill library**: how you cut a release, your brand voice, how you | |
| 11 | − | triage a bug. | |
| 12 | − | ||
| 13 | − | Skills never add a tool or a permission. A skill names the tools it uses, | |
| 14 | − | and the agent uses them with the access of the person who asked, narrowed | |
| 15 | − | to what everyone in the conversation may see | |
| 16 | − | ([what agents can do for whom](/guides/agent-access/)). Where a tool isn't | |
| 17 | − | available, such as code tools in a channel whose members can't all read | |
| 18 | − | code, the agent is told that part of the skill doesn't work there. A skill | |
| 19 | − | can't change who the agent acts for or set aside its rules. | |
| 20 | − | ||
| 21 | − | ## How agents use skills | |
| 22 | − | ||
| 23 | − | Skills load as they are needed, so a hundred of them cost a line each, not | |
| 24 | − | their whole text, on every reply: | |
| 25 | − | ||
| 26 | − | 1. On every reply and every [session](/guides/agent-sessions/) step, the | |
| 27 | − | agent's instructions list each skill it has, by its name and when to use | |
| 28 | − | it. | |
| 29 | − | 2. When a request matches a skill, the agent reads it with the `use_skill` | |
| 30 | − | tool before it starts, then follows it. | |
| 31 | − | 3. A skill that points to one of its files, such as | |
| 32 | − | `resources/template.md`, is read the same way: `use_skill` with `name` | |
| 33 | − | and `file`. | |
| 34 | − | ||
| 35 | − | Reading a skill counts as one of the reply's tool calls. An agent without | |
| 36 | − | any tools (its first hello) has no skills listed. | |
| 37 | − | ||
| 38 | − | Each foundational skill also says, part by part, what isn't possible yet. | |
| 39 | − | The agent is told the same, so when you ask for something that is coming it | |
| 40 | − | says so and offers what it can do instead. | |
| 41 | − | ||
| 42 | − | ## See an agent's skills | |
| 43 | − | ||
| 44 | − | 1. Open **Agents** in the rail and choose an agent. | |
| 45 | − | 2. Open its **Skills** tab. | |
| 46 | − | ||
| 47 | − | **Foundational, from g1t** shows each foundational skill: a check on each | |
| 48 | − | part that works today with the tools that part uses, and **Coming** on each | |
| 49 | − | part that doesn't yet. **Read the playbook** shows exactly what the agent | |
| 50 | − | reads when it uses the skill. | |
| 51 | − | ||
| 52 | − | **From your library** lists the library's skills that reach the agent: | |
| 53 | − | attached to it, to a team it is on, or to every agent, with the version it | |
| 54 | − | uses. **Update to v4** appears when a newer version is out and you may move | |
| 55 | − | it there. | |
| 56 | − | ||
| 57 | − | ## The foundational skills | |
| 58 | − | ||
| 59 | − | The foundational skills are versioned together (version `2026.10` now) and | |
| 60 | − | updated with g1t's releases. Each is written out in the same SKILL.md format | |
| 61 | − | as your own (open it under **Agents → Skills**), and owners turn each off | |
| 62 | − | per agent. | |
| 63 | − | ||
| 64 | − | ### Documents | |
| 65 | − | ||
| 66 | − | | Part | Status | How | | |
| 67 | − | | --- | --- | --- | | |
| 68 | − | | Write and edit docs in Artifacts | Live | `create_artifact`, `edit_artifact`, `read_artifact`. Markdown with tables, task lists, callouts and Mermaid charts. | | |
| 69 | − | | Make PDFs | Live | `make_file` with format `pdf`, from Markdown, attached to a doc. | | |
| 70 | − | | Word documents | Live | `make_file` with format `docx`, from Markdown, attached to a doc. | | |
| 71 | − | | Spreadsheets | Live | `make_file` with format `xlsx` (one or more sheets) or `csv` (one sheet). | | |
| 72 | − | | Slide decks | Coming | Comes with slides in Artifacts. Until then, the agent offers an outline as a doc or a PDF. | | |
| 73 | − | ||
| 74 | − | ### Research | |
| 75 | − | ||
| 76 | − | | Part | Status | How | | |
| 77 | − | | --- | --- | --- | | |
| 78 | − | | Reports with sources | Live | From the workspace's docs, code and chat (`search_artifacts`, `read_artifact`, `search_code`, `read_file`, `search_messages`, `read_thread`), each source linked; long reports as a doc with a Sources section. | | |
| 79 | − | | Search the web | Coming | Comes with web access, set per team. | | |
| 80 | − | | Browse and read pages | Coming | Comes with web access, set per team. | | |
| 81 | − | ||
| 82 | − | ### Data | |
| 83 | − | ||
| 84 | − | | Part | Status | How | | |
| 85 | − | | --- | --- | --- | | |
| 86 | − | | Analyze files and tables | Live | CSV, JSON and log files in repositories (`read_file`) and tables in docs (`read_artifact`). The model works the numbers itself, without running code, so it says what it totalled and calls large results estimates. | | |
| 87 | − | | Charts in docs | Live | Bar, line and pie charts drawn from Mermaid in a doc. | | |
| 88 | − | | Spreadsheets of results | Live | `make_file` with format `xlsx` or `csv`. | | |
| 89 | − | | Dashboards | Coming | Comes with dashboards in Artifacts. | | |
| 90 | − | | Query databases and forks | Coming | Comes with workspace datasets and database connections. | | |
| 91 | − | ||
| 92 | − | ### Code | |
| 93 | − | ||
| 94 | − | | Part | Status | How | | |
| 95 | − | | --- | --- | --- | | |
| 96 | − | | Read and explain code | Live | `list_repositories`, `search_code`, `read_file`, `recent_activity`, in repositories everyone in the conversation can read. | | |
| 97 | − | | Review pull requests | Live | `get_pull`, `review_pull`, `comment`. Reviews are advisory: people still give the approvals a merge needs. | | |
| 98 | − | | Open pull requests | Live | `draft_issue`: the agent drafts the issue, a person files it, and assigning it to `@g1t` makes the pull request on a runner, with checks and revisions. | | |
| 99 | − | | Run code on its runner | Coming | Comes with agents on runners. | | |
| 100 | − | | Write and run tests itself | Coming | Comes with agents on runners. `@g1t` runs tests on issues assigned to it today. | | |
| 101 | − | ||
| 102 | − | ### Communication | |
| 103 | − | ||
| 104 | − | | Part | Status | How | | |
| 105 | − | | --- | --- | --- | | |
| 106 | − | | Draft emails and messages | Live | Written ready to send, in a code block or a doc. Agents don't send email; you do. | | |
| 107 | − | | Summarize threads | Live | `read_thread`, `search_messages`: what was decided, what is open, and who owns each next step, with links. | | |
| 108 | − | | Find times and book meetings | Coming | Comes with calendar integrations. | | |
| 109 | − | ||
| 110 | − | ### Files and media | |
| 111 | − | ||
| 112 | − | | Part | Status | How | | |
| 113 | − | | --- | --- | --- | | |
| 114 | − | | Convert between formats | Live | Markdown, text and tables to PDF, Word, Excel, CSV or Markdown with `make_file`, including files read from a repository or a doc. | | |
| 115 | − | | Diagrams | Live | Flowcharts, sequences and timelines from Mermaid in a doc. | | |
| 116 | − | | Read scans and images | Coming | Comes with image input for agents. | | |
| 117 | − | | Create and edit images | Coming | Comes with image models. | | |
| 118 | − | ||
| 119 | − | ## Files agents make | |
| 120 | − | ||
| 121 | − | `make_file` writes the file itself, inside g1t, and keeps it with a doc in | |
| 122 | − | Artifacts: | |
| 123 | − | ||
| 124 | − | - **Without a doc named**, it makes a new doc that holds the content (or, | |
| 125 | − | for a spreadsheet, a preview of its first rows) and attaches the file. | |
| 126 | − | The doc goes where `create_artifact` would put it: shared with the | |
| 127 | − | conversation in a direct message or private channel, the General space in | |
| 128 | − | a public channel. | |
| 129 | − | - **With a doc named**, it attaches the file to that doc. The person who | |
| 130 | − | asked must be able to edit it; whether the space lets agents edit or only | |
| 131 | − | suggest makes no difference, since a file beside the doc changes nothing | |
| 132 | − | in it. | |
| 133 | − | ||
| 134 | − | Either way, the doc gets a link to the file, and the agent answers with the | |
| 135 | − | file's link. Files are served from the usercontent address | |
| 136 | − | (`g1tusercontent.com` on g1t.sh), like files you put in a doc yourself. | |
| 137 | − | When not everyone in the conversation can open the doc, the agent sends | |
| 138 | − | the link to the person who asked, in their direct message with it, and says | |
| 139 | − | only that it made something. | |
| 140 | − | ||
| 141 | − | | Format | From | Notes | | |
| 142 | − | | --- | --- | --- | | |
| 143 | − | | `pdf` | Markdown | US Letter, numbered pages, links you can click. Headings, paragraphs, bold, italic, code, lists, quotes, code blocks and tables. Standard fonts, so text is Latin script: accents are kept, other scripts are not. At most 300 pages. | | |
| 144 | − | | `docx` | Markdown | The same blocks as a Word document, with real headings and tables. | | |
| 145 | − | | `xlsx` | Rows | Up to 10 sheets, 5,000 rows and 50 columns each. The first row is the header, in bold and frozen. Numbers stay numbers; codes with a leading zero stay text. | | |
| 146 | − | | `csv` | Rows | One sheet, UTF-8. | | |
| 147 | − | | `md` | Markdown | The Markdown as written. | | |
| 148 | − | ||
| 149 | − | A file is at most 25 MB. Mermaid charts and images show in the doc but not | |
| 150 | − | in a PDF or Word file, where a chart's source is kept as code. | |
| 151 | − | ||
| 152 | − | ## The skill library | |
| 153 | − | ||
| 154 | − | Your workspace's own skills are under **Agents → Skills**, and the same | |
| 155 | − | library is **Customize → Skills → Yours** (see | |
| 156 | − | [Customize](/guides/customize/#skills), which also lists every skill the | |
| 157 | − | workspace's marketplaces publish). The library lists drafts waiting for | |
| 158 | − | review first, then every skill with its version and where it is attached, | |
| 159 | − | then the skills installed plugins brought, then g1t's foundational skills, | |
| 160 | − | which you can open to read as SKILL.md. | |
| 161 | − | ||
| 162 | − | A skill does nothing until it is attached. Open it and choose **Attach**: | |
| 163 | − | ||
| 164 | − | | Attach to | Who gets it | Who can attach it there | | |
| 165 | − | | --- | --- | --- | | |
| 166 | − | | Every agent in the workspace | Every agent, `@g1t` included | Owners | | |
| 167 | − | | A team | Every agent on the team | Owners, and the team's maintainers | | |
| 168 | − | | One agent | That agent | Owners | | |
| 169 | − | ||
| 170 | − | An agent gets each skill once. When a skill reaches it in more than one | |
| 171 | − | way, the attachment closest to it decides the version: the agent's own, | |
| 172 | − | then its teams', then the workspace's. | |
| 173 | − | ||
| 174 | − | ### Who can do what | |
| 175 | − | ||
| 176 | − | | | Members | Team maintainers | Owners | | |
| 177 | − | | --- | --- | --- | --- | | |
| 178 | − | | See the library and every skill | Yes | Yes | Yes | | |
| 179 | − | | Save a finished session as a draft | Yes | Yes | Yes | | |
| 180 | − | | Write and import skills, publish drafts | No | Yes | Yes | | |
| 181 | − | | Edit or delete a skill | No | The ones they wrote, used only by their teams | Any | | |
| 182 | − | | Attach, detach and move versions | No | On the teams they maintain | Anywhere | | |
| 183 | − | | Turn a skill off for one agent | No | No | Yes | | |
| 184 | − | | Link a repository | No | No | Yes | | |
| 185 | − | ||
| 186 | − | Every change is in the workspace's audit log under `agents/skills/<name>`. | |
| 187 | − | ||
| 188 | − | ### Skills from plugins | |
| 189 | − | ||
| 190 | − | A [plugin](/guides/customize/#plugins) installed from Customize brings its | |
| 191 | − | skills into the library, each named `plugin:skill` after the plugin | |
| 192 | − | (`pdf@anthropic-agent-skills` brings `pdf:pdf`). They are attached like | |
| 193 | − | any skill, and read-only here: a plugin's skill changes when the plugin is | |
| 194 | − | reinstalled at a newer commit, and leaves with the plugin. Agents call one | |
| 195 | − | with `use_skill` by its full name, or by its bare name when only one plugin | |
| 196 | − | brings a skill called that; a plain name means the workspace's own skill | |
| 197 | − | first. A plugin's skill may be larger than one written here (1.5 MB and | |
| 198 | − | 1,000 files), keeps its name's case, and may reuse a foundational skill's | |
| 199 | − | name, since it is always called with its prefix. See | |
| 200 | − | [skills from plugins](/guides/customize/#skills-from-plugins). | |
| 201 | − | ||
| 202 | − | ## The skill format | |
| 203 | − | ||
| 204 | − | A skill is a folder in the open SKILL.md format, the same one other agent | |
| 205 | − | tools read, so a skill written elsewhere imports as it is: | |
| 206 | − | ||
| 207 | − | ```text | |
| 208 | − | release-notes/ | |
| 209 | − | ├── SKILL.md | |
| 210 | − | ├── resources/ | |
| 211 | − | │ └── template.md | |
| 212 | − | └── scripts/ | |
| 213 | − | └── collect.py | |
| 214 | − | ``` | |
| 215 | − | ||
| 216 | − | `SKILL.md` starts with YAML front-matter, then the instructions in | |
| 217 | − | Markdown: | |
| 218 | − | ||
| 219 | − | ```markdown | |
| 220 | − | --- | |
| 221 | − | name: release-notes | |
| 222 | − | description: Use when someone asks for release notes or a changelog for a version. | |
| 223 | − | tools: [recent_activity, get_pull, create_artifact, make_file] | |
| 224 | − | --- | |
| 225 | − | ||
| 226 | − | # Release notes | |
| 227 | − | ||
| 228 | − | 1. Read the pull requests merged since the last tag (`recent_activity`). | |
| 229 | − | 2. Group them by area: Added, Changed, Fixed. | |
| 230 | − | 3. Write the notes as a doc, linking each pull request. Use resources/template.md. | |
| 231 | − | ``` | |
| 232 | − | ||
| 233 | − | | Key | Required | What it is | | |
| 234 | − | | --- | --- | --- | | |
| 235 | − | | `name` | Yes | Lowercase letters, digits and single hyphens, at most 64 characters. Agents ask for the skill by it. The foundational skills' names (`documents`, `research`, `data`, `code`, `communication`, `files`) are taken. | | |
| 236 | − | | `description` | Yes | When to use it, at most 1,024 characters. Agents read it on every reply to choose the skill, so start with "Use when". | | |
| 237 | − | | `tools` | No | g1t's own key: the agent tools the skill uses, as a list or separated by commas. Only tools agents have are accepted (see below). Naming a tool never gives it to an agent. | | |
| 238 | − | | `requires_computer` | No | g1t's own key: `true` for a skill that needs the agent's own computer. A skill with files in `scripts/` needs one whatever it says. | | |
| 239 | − | | Anything else | No | `license`, `metadata`, `allowed-tools` and other keys are kept as written and change nothing. | | |
| 240 | − | ||
| 241 | − | Other files go in `resources/` (templates and references the instructions | |
| 242 | − | point to; `references/` and `assets/` work too) and `scripts/`. | |
| 243 | − | ||
| 244 | − | The tools a skill can name: `list_repositories`, `search_code`, | |
| 245 | − | `read_file`, `list_issues`, `get_issue`, `get_pull`, `recent_activity`, | |
| 246 | − | `draft_issue`, `comment`, `review_pull`, `search_artifacts`, | |
| 247 | − | `read_artifact`, `list_spaces`, `stale_artifacts`, `create_artifact`, | |
| 248 | − | `edit_artifact`, `share_artifact`, `make_file`, `search_messages`, | |
| 249 | − | `read_thread`, `workspace_roster`, `ask_colleague`, `hand_off`, | |
| 250 | − | `start_session`, `post_update`, `use_subagent`, `bring_in`, `use_skill`, | |
| 251 | − | `remember` and `forget`. | |
| 252 | − | ||
| 253 | − | | Limit | | | |
| 254 | − | | --- | --- | | |
| 255 | − | | One skill's folder | 1 MB, every file together, and at most 200 files | | |
| 256 | − | | Skills from the library per agent | 100. Past that, the agent gets its own attachments first, then its teams', then the workspace's, and its Skills tab says how many it is missing. | | |
| 257 | − | | Skills in a workspace's library | 1,000 | | |
| 258 | − | | An upload | 2 MB | | |
| 259 | − | ||
| 260 | − | ### Scripts and the agent's computer | |
| 261 | − | ||
| 262 | − | Scripts run only on an agent's own computer, which is coming. Until then a | |
| 263 | − | skill that needs one is marked **Needs a computer · Coming**: its scripts | |
| 264 | − | are kept with it and never run, and agents follow the parts of it that | |
| 265 | − | don't need them and never say they ran a script. They can still read a | |
| 266 | − | script's text with `use_skill`. | |
| 267 | − | ||
| 268 | − | ## Write a skill | |
| 269 | − | ||
| 270 | − | You need to be an owner or a team maintainer. | |
| 271 | − | ||
| 272 | − | 1. Open **Agents → Skills** and choose **Write a skill**. | |
| 273 | − | 2. Give it a **name** and say **when to use it** in one sentence. | |
| 274 | − | 3. Write the **instructions** in Markdown, in the second person: the steps, | |
| 275 | − | what to read first, the checks before it's done. **Preview** shows them | |
| 276 | − | rendered. | |
| 277 | − | 4. Tick the **tools it uses**, and add **files** to `resources/` or | |
| 278 | − | `scripts/`. | |
| 279 | − | 5. Choose **Add to the library**, then **Attach** it where it belongs. | |
| 280 | − | ||
| 281 | − | g1t writes the SKILL.md for you. **Show SKILL.md as written** on the | |
| 282 | − | skill's page shows it. | |
| 283 | − | ||
| 284 | − | ## Versions | |
| 285 | − | ||
| 286 | − | Every save is a new version, listed under **Versions** on the skill's page | |
| 287 | − | with who made it, where it came from and an optional note. Choose one to | |
| 288 | − | read it as it was. | |
| 289 | − | ||
| 290 | − | Each attachment pins the version its agents use, so an edit never reaches | |
| 291 | − | an agent you didn't mean it to: | |
| 292 | − | ||
| 293 | − | - When you save, **Use the new version wherever I can change it** (on by | |
| 294 | − | default) moves the attachments you may change. The others keep their | |
| 295 | − | version. | |
| 296 | − | - An attachment on an older version shows **Update to v4** on the skill's | |
| 297 | − | page and on the agent's Skills tab. Choosing it moves that attachment, | |
| 298 | − | for every agent it reaches. | |
| 299 | − | ||
| 300 | − | Saving with nothing changed doesn't make a version. | |
| 301 | − | ||
| 302 | − | ## Import a skill | |
| 303 | − | ||
| 304 | − | You need to be an owner or a team maintainer. Open **Agents → Skills** and | |
| 305 | − | choose **Import**. | |
| 306 | − | ||
| 307 | − | - **Upload** a `SKILL.md`, or a zip of the skill's folder. A zip holding one | |
| 308 | − | folder (as zipping a folder makes it) is read as that folder. | |
| 309 | − | - **From a repository**: a repository you can read (`workspace/name`), the | |
| 310 | − | folder holding `SKILL.md`, and a branch, tag or commit (the default | |
| 311 | − | branch when empty). It is read once, and the commit is kept with the | |
| 312 | − | version. | |
| 313 | − | ||
| 314 | − | A skill whose name the library already has is refused, unless you tick | |
| 315 | − | **If the library has a skill with its name, make this its new version**. | |
| 316 | − | ||
| 317 | − | ## Save a session as a skill | |
| 318 | − | ||
| 319 | − | When an agent finishes a [session](/guides/agent-sessions/) the way you'd | |
| 320 | − | want it done again: | |
| 321 | − | ||
| 322 | − | 1. Open the session and choose **Save as skill**. | |
| 323 | − | 2. The agent drafts a skill from the transcript: its steps, what it read | |
| 324 | − | first and the checks it made, without names of people, secrets or | |
| 325 | − | one-off details. The draft is billed as the agent's work, like a short | |
| 326 | − | session step. | |
| 327 | − | 3. The draft waits under **Drafts to review** in the library. No agent uses | |
| 328 | − | it, and it can't be attached. | |
| 329 | − | 4. An owner or team maintainer opens it, chooses **Review and publish**, | |
| 330 | − | changes what's wrong, and chooses **Publish**. | |
| 331 | − | ||
| 332 | − | Anyone who can see the session can save it. Whoever saved a draft, owners | |
| 333 | − | and team maintainers can discard it. | |
| 334 | − | ||
| 335 | − | ## Keep skills in a repository | |
| 336 | − | ||
| 337 | − | The library is the place you write skills. Optionally, it can follow a | |
| 338 | − | repository, so skills go through the same pull requests and reviews as | |
| 339 | − | code: | |
| 340 | − | ||
| 341 | − | 1. Open **Agents → Skills**. Under **Keep skills in a repository**, enter | |
| 342 | − | the repository as `workspace/name` and choose **Link repository**. | |
| 343 | − | Owners only. | |
| 344 | − | 2. Each folder in `.claude/skills/<name>/` on its default branch becomes | |
| 345 | − | the skill `<name>`: the folder Claude Code reads project skills from, so | |
| 346 | − | one repository serves both. A repository that keeps them in | |
| 347 | − | `.g1t/skills/` is still read, when it has no `.claude/skills/`. The | |
| 348 | − | folder's name and the `name` in its `SKILL.md` must match. | |
| 349 | − | 3. Every push to the default branch that changes a folder publishes a new | |
| 350 | − | version of that skill and moves all its attachments: the repository's | |
| 351 | − | review is the review. **Read it again** reads it on demand. | |
| 352 | − | ||
| 353 | − | A skill from the repository is marked **From the repository** and is | |
| 354 | − | changed there, not in the editor. A folder whose name the library already | |
| 355 | − | uses for a skill written here is skipped and listed under the panel, as is | |
| 356 | − | a folder that isn't a valid skill. When a folder is removed from the | |
| 357 | − | repository, its skill stays in the library and can be edited here again. | |
| 358 | − | **Stop following** does the same for every skill. | |
| 359 | − | ||
| 360 | − | Writing edits made in the library back to the repository as a commit is | |
| 361 | − | coming. | |
| 362 | − | ||
| 363 | − | ## Turn a skill off | |
| 364 | − | ||
| 365 | − | Owners can turn any skill off for one agent, foundational or from the | |
| 366 | − | library, for example Communication for an agent that only reviews code. | |
| 367 | − | ||
| 368 | − | 1. Open the agent's **Skills** tab. | |
| 369 | − | 2. Switch the skill off. | |
| 370 | − | ||
| 371 | − | Turning a skill off takes it out of the agent's instructions. It doesn't | |
| 372 | − | take tools away: tools come from what the agent is and where it is asked, | |
| 373 | − | not from skills. The change is a new version of the agent, listed on its | |
| 374 | − | **Profile** tab with the others. A library skill stays attached; to remove | |
| 375 | − | it everywhere, detach it on its page. | |
| 376 | − | ||
| 377 | − | Members see each skill as **On** or **Off**. | |
| 378 | − | ||
| 379 | − | ## Web access | |
| 380 | − | ||
| 381 | − | Research on the open web comes with web access, set per team: the open web, | |
| 382 | − | approved sites only, or off. It is coming; until then no agent reads the | |
| 383 | − | web. | |
| 384 | − | ||
| 385 | − | ## Coming | |
| 386 | − | ||
| 387 | − | | What | Status | | |
| 388 | − | | --- | --- | | |
| 389 | − | | Running a skill's scripts on the agent's own computer | Coming | | |
| 390 | − | | Writing library edits back to the linked repository | Coming | |
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…
Loading the diff…