Work

Work is the main place to ask the agent to inspect, change, and verify a connected repository. Each request runs in an isolated checkout, keeps its own conversation history, and records the resulting branch, commits, checks, and review link.

A workspace needs a connected repository before you can start Work. See Version Control if the workspace is not connected yet.

Start work

Open the Work tab and describe the outcome you want. You can ask the agent to answer a question, review the repository, plan a change, modify code, or investigate a compliance result.

Use @ to include an enabled connector or a file from workspace Context. You can also upload Context while composing a new request. The agent only receives sources you can access, and connector actions still follow enterprise permissions and approval rules.

Start work from your own systems

Work isn't limited to the Work tab. Anything that can call an API can start and follow a run, so you can orchestrate Work from a ticketing system, a pipeline, an internal portal, or a script. Runs started this way go through the same isolated checkout, policy fabric, and compliance verification as runs started in the app.

The Work endpoints live under /api/v1/enterprises/{eid}/workspaces/{wid}/work/conversations.

1. Create a conversation with POST /work/conversations, passing a title and a client_id you generate. Sending the same client_id again returns the original conversation, so retries are safe.
2. Describe the outcome you want with POST /work/conversations/{tid}/messages, with its own client_id. This queues an agent run. You can set effort per message.
3. Follow progress with GET /work/conversations/{tid}/runs and read the conversation with GET /work/conversations/{tid}/messages.
4. Cancel or retry a run with POST /work/conversations/{tid}/runs/{rid}/cancel or /retry.

Authenticate with a personal access token, or with an enterprise access token for automated systems. Runs started with an enterprise token are recorded as a service account rather than a person. See Access Tokens to create one, the API Reference for conversation sharing and effort, and the API portal for every request and response schema.

What happens during a run

The agent checks out the connected repository in an isolated environment and works on a dedicated remote branch. Activity appears in the conversation as it reads files, runs commands, uses connectors, and checks its changes.

Useful checkpoints are committed to the Work branch. Later messages continue from the latest checkpoint instead of rebuilding the change from the original branch. If someone moves the remote branch unexpectedly, Work stops instead of overwriting their commits.

A run can ask you a question when it needs a decision. You can also stop an active run and resume the conversation later. Runs remain visible in the enterprise agent pool, including while they wait for a delegated check.

Review the result

The result area brings together the information needed to review the change.

• The changed files and line counts show the current branch diff.
• Verification shows the compliance result for the exact saved commit.
• Ruleset recommendations identify relevant standards that are not currently enabled when your enterprise uses manual coverage.
• The change request action opens or links the provider's draft review from the same branch and commit history.

Work can create and update review requests for supported version control providers. See Publishing for the review flow.

Compliance in Work

When Work changes infrastructure code, it can assess which rulesets apply and verify the saved commit. Automatic coverage includes relevant and uncertain rulesets in the evaluation. Manual coverage keeps the workspace selection and shows recommendations for any potential gaps.

Targeted checks can help the agent investigate one rule or ruleset while it works. A targeted result is marked partial and cannot satisfy the final publication check. Work runs a full check before presenting a verified code change.

Open the linked evaluation to see every finding, its evidence, and comparisons with earlier results. See Compliance for the full evaluation model.

Conversations

Each Work conversation has its own messages, plan, branch, and results. The conversation tray lets you search all conversations, bookmark useful ones, and find archived work.

New conversations are private. The owner can share one with individual workspace members or teams. Viewers can read it. Contributors can send follow-up requests when they also have permission to edit the workspace. Sharing a conversation does not grant access to the workspace or repository.

Archiving removes a conversation from the active list without deleting it. Deleting removes its messages, plans, command output, and private code changes. Retained operational records and review requests remain available for audit and billing purposes.

Reasoning effort

Use the level beside Send to choose how much reasoning the next message should use. Medium balances speed and depth and is the default. Higher levels can take longer and use more tokens.

The available levels follow the enterprise's Coding model. Your browser remembers the choice for your account in that workspace. Changing it affects the next message. Active runs and retries keep the level they started with.

Availability and access

Work appears when it is enabled for your enterprise. Starting or contributing to work requires workspace editing access. Reading a shared conversation requires both workspace access and a conversation grant.

The legacy code editor can still appear for enterprises where it is enabled, but Work is the primary repository execution surface.