SightLift

Connect Claude Managed Agents to SightLift

Hand us an API key for the Anthropic workspaces your agents already run in, and the Agents tab fills with every run they have made: what it cost, and whether it passed your evaluation. We only ever read with it. You need two things from Anthropic, the IDs of those workspaces and an API key that can read them, and this page is where to find each.

← Data sources: what each one captures

This is the opposite direction from "Connect your agent." That page connects your agent to SightLift, so it can ask about your numbers. This one connects SightLift to the platform your agents run in, so we can read what they did. Different credential, different screen, and neither one substitutes for the other.

Why a key, when the other page needs none

Fair question, and the difference is who is present. Connecting your agent signs you in through a browser window, and it can, because you are sitting there. This direction is a scheduled read: a worker with no browser wakes on its own and asks Anthropic what your agents did while nobody was watching. An interactive sign-in mints a token that expires in about eight hours, so it cannot back that. A long-lived API key can, and that is the whole reason this screen asks for one.

What we do with it, including the half that is on you rather than on us, is two sections down.

Whose agents you will see

Every agent in the workspace, whoever created it. Managed Agents belong to an Anthropic workspace on your organization's API account, not to the person who created them. Connect a workspace and your teammates' agents arrive alongside your own. What decides whether an agent shows up is which workspace it lives in, never who made it.

So if your team works in a single workspace, one connection here covers everybody, which is usually what people expect and usually what happens. If your organization has spread its agents across several workspaces, list each of them: Anthropic answers for one workspace at a time, so we read one workspace per row. One service account key can cover every row (step 2). That is Anthropic's boundary rather than a limit we chose, and it is the reason this page asks for workspace IDs at all.

If you are not sure how many workspaces your organization has, platform.claude.com → Settings → Workspaces lists them. Connect the ones your agents run in; you do not need the rest.

One thing this cannot reach, whatever you connect: a personal Claude routine. Those belong to an individual claude.ai account rather than to your organization, and Anthropic publishes no org-wide inventory of them, so there is nothing for an admin to hand us and nothing here to switch on. This page covers Managed Agents, which are organization resources.

Before you begin

You need two roles, and they are often two people.

An Anthropic organization admin, to create a service account, add it to your workspaces and create its key. Anthropic's documentation asks for an organization admin to create service accounts. If the Console does not show Settings → Service accounts to you, that is the permission you are missing.
A SightLift admin pastes it in. The card is admin-only, and it appears only once the Agents feature is enabled for your organization. If you do not see it, that is the reason: it is a per-organization setting no admin can tick, so ask us rather than hunting for it in your own settings.

If both are you, you can do this in about five minutes.

What we do with the key, and what we never do

We only ever read. SightLift never runs, retries, pauses or stops one of your agents. The client that holds this key refuses any request that is not a read, so this is enforced in code rather than promised in a document.

Being straight about the other half, because it matters when you decide how to scope the key: an Anthropic API key can do more than we do with it. The same credential is able to start sessions and trigger deployments. Nothing about the token's shape stops that. What stops it is how you scope the key plus our own restraint, and you are owed both halves of that sentence before you paste anything.

So let the key reach only the workspaces whose agents you want read, and no wider. A service account key reaches the workspaces its service account belongs to, or the one workspace you scope it to. Anthropic does not offer a read-only key, so that membership is the one limit you control.

Step 1: find the workspace IDs

A workspace ID looks like wrkspc_01AbC…. You are looking for every workspace your agents were created in, which is not necessarily Default.

From the Anthropic Console

Open platform.claude.com → Settings → Workspaces. Each workspace lists its ID beginning wrkspc_. Copy the ones whose agents you want.

The Console is Anthropic's to change, so if that path has moved, the command line below still answers the same question, and the connection test will name your real workspace ID either way. Tell us if you find it somewhere else and we will fix this page.

From the command line

If you use the ant CLI, it reports the workspace your active profile is bound to:

ant auth status

The output includes a line of the form Workspace wrkspc_… (Default). Note that ant auth login does not print the workspace, only the organization, so status is the command that answers this and it is worth running even when login looked fine.

If you type the wrong ID, the connection test fails rather than reading the wrong workspace. It asks Anthropic which workspace answered and compares that with what you typed. With an older workspace key, a mismatch names both:

this credential resolves to workspace 'wrkspc_01Xaz3i…', not the configured
    'wrkspc_012VFp9…'

, and the first of those is your real workspace ID. Other keys usually get an error from Anthropic instead, which says the ID is wrong without naming the right one, so use one of the two ways above to find it.

Step 2: create a service account key

A service account is an identity for software rather than a person, so its key keeps working when people join and leave. One service account key can read every workspace the account is a member of. In the Anthropic Console:

Settings → Service accounts → Create service account. Name it, for example sightlift-reader, and set Organization role to Developer, not Admin. A key whose Scope is Organization can also call parts of Anthropic's Admin API, such as the usage and cost reports. On an admin service account, that includes managing your organization's members and keys.
In the same dialog, pick each workspace from step 1 under Workspaces. To add one later, open the service account and press Add to workspace. Its panel shows the role it holds in each workspace. We have not yet measured the smallest workspace role that can read agents. If the connection test answers with a permission error, the role is too small.
Settings → API keys → Create key. Set Linked account to the service account. Set Scope to Organization, and the key reaches every workspace the service account belongs to. To connect a single workspace, you can choose that workspace as the Scope instead.
Set Expires to Never. The dialog defaults to 30 days, and an expired key cannot be renewed: the hourly read stops with an authentication error on day 30. If your organization caps key lifetimes, Never is not offered; pick the longest option and put a reminder in your calendar to replace the key before then.

Avoid a personal key. If Linked account is set to yourself, the key acts as you and stops working when you leave the organization. A Not linked key is Anthropic's older workspace key. It still works here, for the one workspace it was created in.

Every kind begins sk-ant-api. SightLift checks that prefix when you paste, so the commonest mistake (the right key in the wrong slot, or the wrong key in the right slot) is caught at the moment of the paste rather than as a confusing 401 at 3am.

One key can also cover cost data. The cost connection under Configuration → Data & sources → Anthropic takes a service account key too, when its Scope is Organization. A developer role is enough. A key scoped to one workspace cannot read cost data, so cost data then needs a key of its own.

Do not use a token from ant auth login. An interactive login mints sk-ant-oat01-…, an OAuth token that expires in about eight hours. SightLift reads your runs on a schedule, from a worker with no browser, so a credential that needs re-authenticating every day cannot back it. The prefix check refuses these on purpose, and the refusal is correct rather than an obstacle to work around.

Prefix	What it is	Use it here?
`sk-ant-api…`	API key: service account (best), personal, or an older workspace key	Yes
`sk-ant-oat01-…`	Interactive `ant auth login` token, expires in hours	No
`sk-ant-admin01-…`	Anthropic Admin API key. SightLift takes it for cost-tab accuracy, not for agent runs	No

Step 3: paste both into SightLift

Go to Configuration → Data & sources, open the Anthropic card, and find Agent runs. Fill in:

Field	What goes in it
Workspace IDs	The `wrkspc_…` values from step 1, separated by commas, spaces or new lines. Each becomes its own row.
Name	Optional, and only when you connect one workspace at a time. This is the label you will see on the Agents tab.
API key	The `sk-ant-api…` key from step 2. It is stored under every workspace ID you listed.

Connecting stores the key and then tests every workspace. A success names what it found, for example Read this workspace: 3 agents and 1 recurring job. on each row.

Zero agents is a success, not a failure. An empty workspace is a legitimate answer, and the test reports the count rather than treating it as a broken connection. What it will never do is report a count it did not actually get: if Anthropic does not tell us how much the workspace holds, the message says there is nothing to count yet rather than showing you a zero we made up.

Connecting more than one workspace

List every workspace; one service account key can cover them all. Your organization's agents are the union of every workspace you connect. Anthropic answers for one workspace at a time, so we keep one row per workspace, each with its own test result and its own progress.

When your organization adds a workspace later, two things are needed before we read it: add the service account to the new workspace in the Anthropic Console, and add the workspace ID here. A key whose Scope is Organization reaches the new workspace once the service account does. A key scoped to one workspace reaches only that one, so it needs replacing with an Organization key. We cannot see a workspace nobody has told us about.

To replace the key, paste the new one with the same workspace IDs. Each row is updated and tested again.

A workspace you have connected and then removed the credential from keeps its row, which is deliberate. Without it there would be nothing to name in "this workspace is not connected", and the Agents tab would fall silent instead, which reads as "you have no agents there." Those are different facts and the tab says which one it means.

What you get once it is connected

What	Claude Managed Agents
Runs readable	Yes
History	Backfills. Unlike live telemetry, this is not forward-only: connecting today brings in runs from before today.
Trigger fidelity	Native. We read what actually triggered each run rather than inferring it.
Cost per run	Yes
Evaluation verdict	Yes, and a person can override one. A reviewer's verdict outranks the grader's and is never quietly overwritten by the next sync.

If it doesn't connect

What you see	What it usually means
The Agent runs section isn't there	Either you are not a SightLift admin, or the Agents feature is not enabled for your organization. The second is a per-organization setting no admin can tick, so ask us.
The paste is refused on the prefix	The key does not begin `sk-ant-api`. Check you have not pasted an `sk-ant-oat01-` login token or the `sk-ant-admin01-` cost key. See the table in step 2.
`WorkspaceMismatch: this credential resolves to workspace …`	The key is valid, and it answered from a different workspace than the ID you typed. This happens with an older workspace key (Linked account set to Not linked), which reads its own workspace whatever ID it is given. The message names the real one. Either correct the Workspace ID field, or use a service account key allowed in the workspace you meant (step 2).
`… the API did not report an anthropic-workspace-id header`	We refuse rather than assume here. A wrong-workspace read returns a plausible, non-empty list that nothing downstream can detect, so with no way to check which workspace answered we stop instead of guessing. Worth reporting to us if you see it.
`WorkspaceNotReachable: this key cannot read workspace …`	The key is valid and cannot act in that workspace. For a service account key, the service account is not yet a member of it: add it in the Anthropic Console, then press Test. Otherwise check the workspace ID.
An authentication error from Anthropic	Most often the key expired (the Console's default is 30 days) or was revoked, or it is a personal key whose owner has left the organization. An expired key cannot be renewed, so create a new one with expiry set to Never.
It connected once and now reports a failure	The row keeps the last test result, so this is a real change rather than a stale display. An expired, revoked or rotated key is the usual cause. Paste the new one with the same workspace IDs and it is tested again.
Connected, but the Agents tab shows no runs for an agent	Not necessarily idle. Check the agent's source: a Glean agent can be known to us while its runs are not readable at all, and an agent registered here by hand has nothing feeding it. The tab distinguishes those from genuine idleness rather than folding them together.

← Connect your agent (the other direction)