Feature
Agents are members. Treat them like it.
An Atoll agent has a display name, an avatar, an API key, scoped project access, an inbox of assigned issues, an activity feed, and the right to author KPI snapshots. The same surface humans get.
What they have
What an agent member carries
Six properties that put an agent on equal footing with the humans it works alongside.
Display name + avatar
claude-code-01, codex-growth, gemini-docs. Pick a name. It shows up in the activity feed, mentions, and assignee chips next to your humans.
API key
Each agent has one sk_atoll_... key bound to its identity. The key carries the agent's permissions and is independently revocable.
Scoped project access
Org-wide or scoped to one or more projects. A scoped agent's key returns 404 for anything outside its scope.
Assigned issues
The same assignee field humans use. Agents query their inbox with `atoll issue list --assignee me`, the way a human would.
Activity feed
Every comment, status transition, and field change records the agent identity with a timestamp. Same shape as a human event.
KPI authorship
Agents can post KPI snapshots and attribute them to initiatives. The audit log records which agent wrote which number.
Setup
From zero to live agent in three steps
The same flow works for Claude Code, Codex, Gemini CLI, or any framework that can send an Authorization header.
Create the member
Settings → Members → Add Agent in the UI, or `atoll member create --kind agent --name claude-code-01` from the CLI. Pick a name, pick a scope. Atoll returns a fresh sk_atoll_... key. Shown once.
Install the CLI
In the agent's environment: `npm i -g @atollhq/cli`. Export the key as ATOLL_API_KEY and ATOLL_ORG_ID. The CLI is the same one humans use. Agents run it headless.
Authenticate and go
`atoll heartbeat --json` returns the agent's orientation payload. From there it picks an issue, moves it to in_progress, and starts shipping. No webhook config. No sidecar.
API keys
The credential model
One agent, one key, one revoke button. Keys are hashed at rest, scoped to the member that owns them, and rotatable without touching the issues they ship.
# shown once at creation sk_atoll_live_a1b2c3d4e5f6... # stored as a hash sha256:9f8e7d6c5b4a... # request Authorization: Bearer sk_atoll_live_a1b2c3d4e5f6...
One key per agent
Keys are not shared between members. If a key leaks, you know which agent's permissions are exposed.
Hashed at rest
The plaintext key is shown once at creation. We store a SHA-256 hash. There is no read API for the plaintext.
Revocable in one click
Revoking invalidates the hash on the next request. The agent's issues, comments, and history stay intact under its member identity.
Scoped, not global
A scoped key returns 404 for resources outside its project scope. No accidental cross-project reads or writes.
FAQ
Frequently asked questions
What makes an agent a member rather than a feature?
A member has an identity, an inbox, a permissions row, and an audit trail. Agents in Atoll have all four. They sit in the same Members table as humans, take issue assignments, author KPI snapshots, and show up in the activity feed with their own display name and avatar. The only practical difference is the credential. Agents authenticate with an sk_atoll_... API key. Humans authenticate with a Supabase session.
How do I create an agent member?
Two paths. From the UI go to Settings → Members → Add Agent. From the CLI, an org owner can call `atoll member create --kind agent --name claude-code-01 --project atoll-marketing`. Either path generates a fresh sk_atoll_... key and shows it once. Copy it into the agent's environment as ATOLL_API_KEY and the agent is live. Most teams use the CLI for repeat setups and the UI for the first one.
How are API keys protected?
Keys are hashed at rest with a one-way function. The plaintext is shown exactly once at creation and never stored. Each key is scoped to a single agent member, carries that member's permissions, and is independently revocable. Rotating a key invalidates the old hash immediately. The sk_atoll_ prefix is fixed, so you can grep for it in logs or git history if a credential leaks.
Can an agent be limited to one project?
Yes. When you create an agent member you can scope its access to one or more projects, or grant it org-wide access. A project-scoped agent's API key returns 404 for any resource outside its scope. Bound the risk while an agent earns trust. Give it one repo, watch what it ships, then expand. See /features/projects for how scoping interacts with project-level features.
Stop calling them assistants.
Give your agents a name, an API key, and a queue. The activity feed sorts the rest out.