Example: Accounts & Sessions
A deliberately narrow playbook for login, access and permission tickets — and an illustration of why narrow is good.
Someone cannot get in, keeps getting logged out, or cannot see something they should. High volume, low complexity, and the narrowest of the five examples — which is exactly the point. A tight allowlist makes these resolve in two or three tool calls.
Fields
Name
Accounts & SessionsDescription
Tickets about access to an account rather than what the account does: cannot log in,
password resets, being logged out repeatedly, two-factor problems, and users who
cannot see a feature or store they should have access to.Routing hints
login, "can't log in", "cannot sign in", password, reset, "forgot password", locked
out, 2FA, two-factor, MFA, "logged out", session expired, "keeps signing me out",
permission, "access denied", "can't see", invite, "not receiving email"Triage instructions
These are almost always account state or session state. Two tools usually settle it,
so do not go wider unless they genuinely do not explain it.
1. Postgres: the user record. Check — in this order — whether the account exists at
all, whether it is disabled or locked, whether the email is verified, and what
roles and store access it has. Most tickets end here.
2. Redis: active sessions for this user. Look at session count, TTLs, and whether
sessions are being created and immediately dropped. Repeated logouts are a session
TTL or session-store problem, not a password problem.
3. If neither explains it, check for recent changes to the user's roles or store
access — a permission removed by an admin looks identical to a bug from the user's
side.
Known causes, most to least common:
- account locked after failed login attempts — check the lockout counter and when it
clears
- email never verified, which blocks login on a freshly invited account
- a role or store-access change that removed something the user was relying on
- session TTL shorter than expected, or sessions evicted under memory pressure
- the user is signing in to the wrong environment or with the wrong email
Conclusions:
- Distinguish "cannot authenticate" (password, lockout, verification) from
"authenticated but cannot see something" (roles, store access). They are different
problems with different owners and the ticket text often blurs them.
- If the account is locked, say when the lockout clears rather than only that it is
locked.
- Never report or echo password values, reset tokens or session identifiers in the
investigation. State that a record exists and its status.Data sources
org-redis, org-postgresVisibility
Everyone in the organization.
Why narrow is the whole point
Two data sources. No logs, no metrics, no error tracking.
Account tickets are answered from account state, and the marginal value of letting the agent read logs here is close to zero while the marginal cost is real — more iterations, more tokens, slower answers, on the highest-volume ticket category you have.
If you want one demonstration of what data-source scoping is for, this is it: run the same login ticket under this playbook and under no playbook, and compare the tool chips.
A note on PII
Account tickets are the ones most likely to contain personal data. Emails, phone numbers and card numbers are redacted from ticket content before it reaches any model — see PII redaction — but the instruction above to never echo credentials or tokens back into the report is a second layer worth keeping, because the agent reads your database, and redaction covers the ticket rather than the query results.