Appearance
Welcome to Tenbi
Tenbi is an AI-driven, multi-agent ticket orchestrator that turns tickets into reviewable pull requests automatically. You configure where tickets come from and which repos the work lands in; the orchestrator runs the work; you keep the human-in-the-loop checkpoint at PR review.
Your account
Tenbi is multi-tenant: everything you create — credentials, connections, projects, runs — belongs to your account and is invisible to other accounts. You also bring your own Claude credential, so your runs bill to your own Anthropic plan. Sign in with the account you were invited with; there's no self-signup (you can join the waitlist if you don't have an invite). Details on invites, the terms-acceptance step, two-factor authentication, and notification preferences are in Account & Security.
Setup: from zero to first PR
The pieces stack in this order — each step is used by the one after it:
Claude credential → service credentials → a project → a lane → label a ticket.
Each step below is a summary; the linked Setup chapters carry the full detail.
Step 1 — Add your Claude credential
Open Settings → Credentials. Tenbi runs on Claude by default (you can switch the whole account to Codex later — see Choose your AI). Under Anthropic, paste an API key from the Anthropic Console — the recommended mode, and the path Anthropic's terms support for third-party products. (A subscription OAuth mode exists as an advanced, consent-gated option with real trade-offs — read Credentials before considering it.) The workspace base model — the biggest cost/quality lever — lives in Workspace → Settings → Models, beside the agent choice; projects and lanes can override it later.
This step is required: an account with no Claude credential can't run anything.
Step 2 — Add service credentials
In Workspace → Settings (the workspace's admin area — as the owner, that's you), add the secrets for the services your tickets and repos live in: a GitHub PAT (scopes matter — the most common setup failure), and/or Jira Cloud, Shortcut, Bitbucket Cloud, Azure DevOps, plus Discord/Slack/Microsoft Teams webhooks if you want channel notifications. Use each credential's Verify button as you go. Exact scope requirements per service are in Credentials.
Step 3 — Create a project
A project owns the work: where its tickets live and which repos runs land in. Go to Projects → New Project, name it, and pick its ticketing — an external tracker (GitHub Issues, Jira, or Shortcut, via a connection you can create right in the picker) or Tenbi Tickets, the built-in tracker that needs no external setup at all. Then open the project's Settings and register its repos, each with the Version Control connection that reaches it. Connections you create in place land in a shared registry, so your second project finds them already there. The full tour: Projects.
Step 4 — Add a lane
A lane is the project's pickup rule: when is a ticket handed to the agents, and how does that run behave. In the project's Lanes tab press New Lane for this project and set the trigger — a discovery label (label trackers, Tenbi Tickets included) or a Ready status (Jira / Shortcut). The repos and connections come from the project; the lane just picks up tickets. If matching tickets already exist, the cold-start check lets you choose what the first poll may pick up — by default, nothing pre-existing. The full form and tuning: Lanes.
Step 5 — Mark a ticket ready and watch
Mark a real ticket ready — apply your discovery label (GitHub) or move it to your Ready status (Jira / Shortcut). Within a poll cycle (about 30 seconds) it appears on the Dashboard as a record in Picked Up, then walks through Planning → Coding → Reviewing → Finalizing. Click the row to watch the agents work live. When it lands on Done, the PR is open and waiting for your review. A minute-by-minute walkthrough — including what runs cost and how quotas behave — is in Your First Run & Costs.
Tip for your first run: start with a small, well-described ticket — a clear title, the expected behavior, and any constraints. The PM agent turns the ticket text into requirements, so the better the ticket reads, the better the PR.
Write agent-ready tickets
The single biggest lever on run quality is the ticket itself. The planning agent builds the entire run from the ticket body: your context becomes the problem statement, each acceptance criterion becomes a test and a QA check, and Constraints & out of scope draws the line the agents won't cross — anything they think of beyond it arrives as PR-body suggestions, never as code.
Download the ticket templates and paste one into your tracker when filing work for Tenbi (GitHub, Jira, and Shortcut all render them):
Using them is optional — Tenbi works any labeled ticket — but structured tickets measurably improve agent accuracy: concrete acceptance criteria produce testable outcomes, and explicit boundaries keep the diff on-target.
A leading [type] prefix in the ticket title (e.g. [feature], [bug]) becomes a ticket-type chip on the Dashboard — map these to your own display names and colors in Settings → Ticket types.
Quick checklist
| # | Where | What | Required |
|---|---|---|---|
| 1 | Settings → Credentials | AI agent choice + its API key (Anthropic; or OpenAI for Codex Beta) + default model | Yes |
| 2 | Workspace → Settings | GitHub PAT (and/or Jira, Shortcut, Bitbucket, webhooks) — owner/admin | Yes |
| 3 | Projects | A project: ticketing destination + ≥ 1 repo with its Version Control connection | Yes |
| 4 | The project's Lanes tab | A lane: Ready trigger (label or status), enabled | Yes |
| 5 | Your ticket tracker | Mark a ticket ready — discovery label or Ready status | Yes |
Where to go next
Setup, in depth:
- Credentials — every credential type, exact PAT scopes, the OAuth trade-offs, verification and rotation.
- Account & Security — two-factor authentication, recovery codes, password reset, email notifications.
- Projects — the unit of work: destination, repos, settings, and the Compose board.
- Connections — the registry and every adapter in depth.
- Lanes — discovery, the lifecycle (labels or statuses), cold start, and tuning.
- Optimize — per-repo codebase maps and guides that make runs smarter and cheaper.
- Your First Run & Costs — the walkthrough, cost semantics, and quotas.
Day to day:
- Dashboard — reading run states, finding runs, triaging failures.
- Analytics — spend, throughput, and success rate across all your runs.
- Troubleshooting — symptom-by-symptom fixes: PAT scopes, repos that won't verify, tickets not picked up, failed runs.