Skip to content

Tier2Products

Seven surfaces, one invariant

Tier2 answers from what you give it — a knowledge base for the questions that are just questions, a real diagnosis pipeline for the ones that aren't — with a citation rule enforced in code either way, wrapped in the surfaces your team already works in.

Cited, not guessedDraft-only by defaultOne agent per tenant
Knowledge base

Most tickets are just questions. Answer them like it.

Every product — technical or not — gets asked the same handful of "how do I / where is / does this include X" questions on repeat. Your knowledge base answers those directly and cites the article, with the same citation discipline as a probe: no article, no answer.

  • Tenant-editable, reviewed by your team, searched before anything else runs
  • A hit ends the investigation right there — no probe, no guessing
  • A miss says so plainly instead of inventing an answer
memory/kb · billing/annual-discountanswered — no probe needed

“Do annual plans get a discount?” — Yes, annual plans get 15%, applied automatically at checkout. No proration on upgrades mid-cycle; email billing@ for exceptions.

kb.article · billing/annual-discount
Cited, not guessed — same citation rule as a probe
Differential diagnosis

When it is a real technical problem, prove it

Not every ticket is a knowledge base question — some are an actual bug or an actual outage. For those, the model runs a real differential test: the branch predicate is plain TypeScript evaluated against the probe result, which is what makes a diagnosis reproducible and regression-testable rather than a lucky paraphrase.

  • Only runs when the knowledge base doesn’t settle the question
  • Live checks against your systems: HTTP timing, TLS handshake, DNS resolution, deploy diffs
  • Named, parameterised queries against a read replica — never free-form SQL
  • Five verdicts: reproduced, already-fixed, not-reproducible, environment-specific, needs-info
  • Raw probe output stored verbatim; summaries are a rendering concern
Evidence contract

The renderer drops uncited claims

This is the invariant the whole product rests on. A factual sentence must carry the probe_run_id of the probe that produced it, or it never reaches a human. Enforcement is code in the renderer, not an instruction in a prompt.

  • Every claim links to the run that produced it, inspectable in one click
  • Control-plane fields marked dead are never quoted; stale fields are marked inline
  • A hallucinated-claim rate you can measure, because uncited output is countable
probe_runsraw output stored verbatim
pr_9f2ac1http.timing200 in 2.4s
pr_9f2ac2deploy.diffdb/pool.ts changed
pr_9f2ac3replica.querysaturation 94%
dns.resolvenot run · rule branch false
Drafted replies

Four of five tickets never reach an engineer

Already-fixed, not-reproducible, environment-specific and needs-info all resolve as a customer reply drafted for approval. That ratio is the economic argument, and the product is built to protect it.

  • Draft-only by default — auto-send is off and earned per category
  • Citations travel with the draft so approving means checking evidence, not tone
  • Acceptance rate is measured; auto-send is revocable the moment it slips
draft reply · T-48291awaiting approval

Thanks for flagging this — we reproduced it. The slowdown started at 14:02 UTC with our v419 deploy, which reduced the connection pool from 64 to 16. Saturation reached 94% within twenty minutes. A fix is rolling out; no action is needed on your side.

deploy.diff · pr_9f2ac2replica.query · pr_9f2ac3
Approve & send EditAuto-send off
Escalation packets

Only a reproduced defect wakes someone

When the verdict is reproduced, Tier2 assembles an escalation packet — severity, root cause, owner, and the full evidence trail — and posts it to your engineering channel without waiting for a human to relay it.

  • Deduped on tenant and dedup key at the database level, so no double ownership
  • Internal escalations are autonomous; the draft gate covers customer-facing sends only
  • Recurring known issues collapse into one thread instead of a new page each time
escalation packetdedup: pool_max/v419reproduced
Severity
P1 · customer-facing latency
Root cause
pool_max 64 → 16 in v419
Owner
#platform-oncall · @data-infra
Evidence
3 probes · 3 citations · 0 uncited claims
Posted without waiting for approval — internal route
Runbook learning

Your engineers’ corrections are the product

When an engineer corrects a diagnosis, that correction is proposed as a runbook diff and reviewed like code. The playbook your team fixes this week is the playbook that answers next month’s ticket.

  • Versioned YAML per tenant, reviewed as a diff before it takes effect
  • A replay harness scores every runbook change against the labelled eval set
  • Facts learned from ticket bodies are quarantined until a human promotes them
runbooks/acme/latency.yamlcorrection from @priyaneeds review
tests:
- when: p95_regression
  probe: http.timing
+ when: p95_regression
+  probe: deploy.diff
+  then: replica.query(pool_saturation)
  trust: control_plane.pool_max = stale

Connectors

It works where your team already works

Signals arrive from wherever your customers report them, and answers go back the same way. Nothing asks your engineers to open another tab to do their job.

Slack

The agent lives in a channel per tenant. Escalations post with the assignee or group mention; corrections typed in the thread become runbook input.

Linear

A reproduced defect becomes an issue with the evidence trail attached, deduped on the tenant and dedup key so two engineers never own the same P1.

Hosted support inbox

A shareable support page and inbox if you do not have a helpdesk yet. Signals land here and follow the same diagnosis path.

Embed & Ask AI

Drop the widget into your docs or dashboard. The same runbook answers, with the same citation rules and the same draft gate.

Ready when you are

See it run on your own ticket.

Bring a real ticket from last week. We show you what it would have answered from your knowledge base, or what it would have checked and found.

Draft-only by defaultRead + probe access only