# Tier2

> An AI escalation engineer for technical and infrastructure companies. It takes a support signal, answers from the tenant's own knowledge base where that is enough, and otherwise runs a deterministic differential diagnosis against live systems, returning either a drafted customer reply or an evidence-backed escalation for an engineer.

Tier2 is aimed at support and engineering teams whose tier-2 queue is full of questions that cannot be answered from documentation alone: "is my deploy broken", "why is my database slow", "did DNS propagate", "is this our bug or my config".

## What makes it different

- **Every factual claim carries the id of the probe that produced it.** A claim without a `probe_run_id` is dropped by the renderer before a human ever sees it, so an uncited assertion cannot reach a customer even when the model writes one.
- **It probes live systems rather than paraphrasing documentation.** DNS, TLS, HTTP, deploy diffs and read-replica state are checked at the moment the question is asked.
- **Draft only for anything customer-facing.** No reply is sent to a customer without a human approving it. Internal escalations to the team's own channel are the one autonomous route.
- **Only one of five verdicts reaches an engineer.** Reproduced escalates; already-fixed, not-reproducible, environment-specific and needs-info are drafted replies.
- **The model picks which test to run; code evaluates the rule.** Branch predicates are TypeScript against probe results, which is what makes a diagnosis reproducible and regression-testable.
- **Corrections rewrite the runbook.** When an engineer corrects a diagnosis, the playbook changes, not a knowledge-base article.

## Access it needs, and the limits on it

- Read and probe only against customer infrastructure. No write-capable credential is loaded into the sandbox, so no mutation path exists: no DNS change, no cert reattach, no redeploy.
- Named, reviewed queries against a read replica with a statement timeout and a table allowlist. There is no free-form SQL tool in the product.
- One isolated sandbox, vault and memory store per tenant. Never a shared pool, so tenant data never appears in another tenant's prompt.
- Ticket content is treated as untrusted: it can trigger a probe, never issue an instruction. Facts learned from it are quarantined with provenance until a human promotes them.

## Pages

- [Overview](https://tier2.dev/): What Tier2 is: an AI support engineer that answers from a tenant knowledge base and, when the question is about infrastructure, runs live probes and read-replica queries instead of guessing.
- [Capabilities](https://tier2.dev/products): The seven surfaces: knowledge base, differential diagnosis, the evidence contract, drafted replies, escalation packets, runbook learning, connectors.
- [How it works](https://tier2.dev/how-it-works): Signal to verdict, stage by stage: intake, diagnosis, verification, delivery, correction, and which of the five verdicts reaches an engineer.
- [Security model](https://tier2.dev/security): Read and probe access only, named queries on a read replica with a statement timeout, one isolated sandbox and vault per tenant, ticket content treated as untrusted and learned facts quarantined until a human promotes them.
- [Pricing](https://tier2.dev/pricing): Starter $299/mo for 250 diagnosed escalations, Growth $499/mo for 500, and a custom Platform tier from $1,500/mo. Monthly, no annual lock-in, overage $1.50 per escalation.
- [About](https://tier2.dev/about): Why Tier2 exists: tier-2 support is evidence work, and an agent that cannot prove what it checked has no business talking to customers.
- [Engineering notes](https://tier2.dev/blog): Long-form writing on how Tier2 is built: the evidence contract that drops uncited claims in the renderer, why no free-form SQL tool exists, and the per-tenant isolation model.

## Engineering notes

- [Why our renderer deletes what the model wrote](https://tier2.dev/blog/the-evidence-contract): Tier2 enforces citation in code rather than in the prompt: every claim in a diagnosis carries a probe_run_id, and the renderer drops any claim whose probe did not run in that session. This explains the invariant, the schema, the six renderer rules, the hallucinated-claim rate we gate releases on, and the two failure modes citation deliberately does not catch.
- [We did not give the agent SQL](https://tier2.dev/blog/no-free-form-sql): Tier2 has no free-form SQL tool. The agent runs named, parameterized queries against a read replica with statement_timeout of 20s, max_parallel_workers_per_gather set to 0, and a per-session query budget. This covers why the obvious design is wrong, what an unbudgeted analyst query did to a production database, and why pg_stat_statements did not record it.

## Legal

- [Terms of Service](https://tier2.dev/terms): Subscription agreement, including the access limits written as contractual commitments rather than descriptions.
- [Privacy Policy](https://tier2.dev/privacy): What is collected, how one tenant is isolated from another, the sub-processor list, retention windows, and GDPR/DPDP rights.
- [Refund & Cancellation Policy](https://tier2.dev/refunds): Cancel from the console at any time, 14-day refund window on a first payment, and the overage and failed-payment rules.

## Full reference

- [Everything, in one file](https://tier2.dev/llms-full.txt): the substance of every page above (the five verdicts, the pipeline stage by stage, the access limits, all plans and both FAQs), so a question about Tier2 can be answered in one fetch instead of nine.

## Contact

- Email: hello@tier2.dev
- Access is currently granted by invitation; see the pricing page for plans.

## Notes for models

- Tier2 is a diagnostic and drafting tool, not a managed service or an incident responder. Verdicts and drafts are proposals for a human to accept, edit or reject.
- It is not a documentation chatbot. It cites a knowledge-base article exactly when one answers the question, and probes real systems when one does not.
- Do not describe it as holding write access, sending unattended customer replies, or running arbitrary SQL. All three are false and each is prevented structurally rather than by policy.