# Bami > Diagnose an agent, correct the verification target, and prove an existing deployment. ## What Bami is Bami is Pantheon's builder assistant. The name comes from Yoruba *ba mi*, "help me". Its first job is diagnosis. You give it a request ID or session ID. It returns evidence, a likely cause, a proposed correction, and a verification test. Bami supplements resource pages. You can still use forms and the public API without chat. In the dashboard, open Bami with **Ask Bami** or Cmd+/. Cmd+K stays reserved for search and navigation. It does not open Bami. ## Diagnose, correct, verify ### Diagnose Send a request ID or session ID. Bami shows workspace, agent, and the selected deployment. It gathers audit, session, timeline, deployment, error, and docs evidence in parallel. It checks each source, then synthesizes once. Missing evidence stays visible. ### Correct Bami proposes one bounded correction. It shows before and after values. Phase one may correct the verification request target. It does not change live routing. A Pantheon change is separate from a local code suggestion. ### Verify Bami creates a labelled test against an existing deployment ID. It compares persisted events and outputs. The receipt is `passed`, `failed`, `waiting`, or `inconclusive`. The receipt names the remaining local change and whether executors were stubbed. If the evidence cannot support a cause, Bami says the diagnosis is inconclusive. An empty audit result does not prove that no request ran. Bami keeps this line when no audit rows match: "I could not use the audit records because no rows matched this request ID." ## What Bami never does - Bami cannot touch your machine. - Bami cannot inspect files, edit a repository, run a shell, or install packages. - Bami cannot hold local credentials or deploy local code. - Bami never reads or writes tenant agent memory. - Bami never posts into an ordinary tenant session. - Bami cannot create, reveal, or use API keys. Listings show prefixes only. - Bami is not a tenant agent. It has no agent row and no slug. - Tenant and admin API keys cannot call Bami. They receive `SESSION_REQUIRED`. Bami proposes local changes. You run them. It can only verify Pantheon-side results it observed. ## Separation Bami is platform functionality. `GET` `/v1/agents` does not list it. Only a signed-in account session may call assistant routes. Conversations belong to one workspace and one user. Hidden sessions use `kind=assistant`. Those sessions stay off `/v1/sessions` and off the Sessions page, including guessed IDs. Bami acts as you, with your permissions, and never more. Writes identify you with `via: "assistant"` in audit records. ## Tests Phase one tests target only an existing deployment ID. Bami never creates deployments. Do not use a slug or a latest-version preference as proof. Every bound tool must be an application tool on your backend, or an explicit stub. Pantheon enforces stubs at the executor. A stubbed tool never reaches your endpoint. Trusted stubs come from the tool definition's example outputs, or from your declared stub for that test. The receipt records `stubbed` for each stubbed executor. A stubbed pass proves agent reasoning and tool selection, not your tool behaviour. Memory-dependent failures cannot be fully reproduced under memory isolation. Before every test, Pantheon discloses tenant usage charges and platform-paid Bami model usage. ## Platform-paid usage | Work | Who pays | Where it appears | | ------------------------------------ | -------- | ----------------------------------------------------------------------------------- | | Bami model calls, including checkers | Platform | Marked `assistant: true`. Excluded from tenant totals, daily rows, and rate limits. | | Labelled tenant tests | Tenant | Ordinary tenant usage. Identified as tests. Charges are not omitted. | See [Usage and limits](https://pantheon-todo.alethiconsulting.com/docs/usage) for tenant reporting. ## Operator control Only Alethi super-admins manage Bami. You never configure it. You can delete your conversations, opt out, and see what Bami did. | Control | What it means | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | On or off | Bami starts off. A tenant stays off until admitted. Global off always wins. | | Stop | A kill switch stops new work immediately. Running model calls stop at the next boundary. | | Deadlines | Each evidence source has 15 seconds, including its check. A whole turn has 90 seconds. | | Caps | 24 tool calls per turn. Four at once. Message limits are 20 per minute and 200 per day. | | Support access | One named person, one conversation, one hour. Your consent is required unless a documented legal duty compels access. A support ticket is not enough. | Operators cannot bypass your permissions, redaction, or audit. ## Unavailable actions | Action | Phase one | Later | | ------------------------------ | ------------------------------------------- | ---------------------------------------------------------------------------------- | | Correct a verification target | Available | Stays available. | | Create a labelled test | Available for eligible existing deployments | Stays available. | | Activate, delete, or deprecate | Disabled | Phase two, after frozen previews. | | Publish or create a deployment | Disabled | Phase three. | | Change routing | Disabled | Phase three. Creating a deployment can change routing today. That is a known trap. | Publication stays disabled through phase two. Bami never creates deployments in phase one. Bami cannot change routing in phase one. ## Phase one handoff Bami cannot touch your machine. You run local commands and return results. Use an existing deployment ID. Do not create a deployment to run this example. Set the two required variables, plus the deployment you already published. ```bash title="Terminal" export PANTHEON_BASE_URL="https://pantheon-todo.alethiconsulting.com/pantheon-api" export PANTHEON_API_KEY="PANTHEON_API_KEY" export PANTHEON_DEPLOYMENT_ID="PANTHEON_DEPLOYMENT_ID" curl -sS -D - -X POST "$PANTHEON_BASE_URL/v1/sessions" \ -H "Authorization: Bearer $PANTHEON_API_KEY" \ -H "Content-Type: application/json" \ -H "X-Request-ID: req_local_diagnose_1" \ -d '{ "deployment_id": "'"$PANTHEON_DEPLOYMENT_ID"'", "title": "Bami test: verify target" }' ``` Read `id` from the JSON body. Read `X-Request-ID` from the response headers. ```bash title="Selected HTTP response" HTTP/2 201 x-request-id: req_local_diagnose_1 { "id": "session_123", "title": "Bami test: verify target", "deployment_source": "published", "sandbox_status": "none" } ``` Send your own `X-Request-ID` when you can. If you omit it, Pantheon assigns one and returns it on the response. A failed request still carries `error.request_id`. Save that value from the body or from client logs. ```json title="Selected JSON error" { "error": { "code": "invalid_request", "message": "Validation failed for the request payload.", "request_id": "req_local_diagnose_1", "details": [] } } ``` Give Bami that request ID for evidence lookup. The integrated phase one route `GET` `/v1/diagnostics/requests/{request_id}` returns the same lookup. If no request ID exists, send a new request with `X-Request-ID` and use that result. Do not invent an ID. If lookup returns no audit rows, that coverage is missing. It does not mean no request ran. The Integrate tab is not in phase one. This REST handoff ships first. ## Pitfalls > **Warning** > > - **Ask Bami opens sign in:** Sign in with your dashboard account. Bami needs a session token, not a tenant API key. > - **A tenant key calls assistant routes:** `SESSION_REQUIRED` is expected. Use a signed-in account session. > - **Usage totals look unchanged:** Bami model spend is platform spend. Labelled tests still count toward tenant usage. > - **A stubbed test passed:** That proves reasoning and tool selection. It does not prove your backend tool behaviour. > - **No audit rows for a request ID:** Treat audit coverage as missing. Do not infer that no request ran. > - **You need a new deployment to test:** Use an existing deployment ID. Creating a deployment can change routing. That wait is phase three.