Back to use cases
Engineering & SRE

Who owns this service and what should I know?

Owner, on-call rotation, last three incidents, recent design decisions: all in one card.

Best for
New-engineer onboarding
Primitives
Value ObjectsActorsDecisions
Token savings
45%

The prompt

You are briefing a new engineer about to touch {{service_name}}. Using Sentra: 1. Resolve {{service_name}} as a Value Object — map across GitHub repo, CODEOWNERS, PagerDuty service, observability dashboards, and any Slack ownership posts. 2. Identify the current owner(s) and the on-call rotation. 3. Pull the three most recent incidents and a one-line root cause for each. 4. Pull the five most recent Decisions about this service with their Rationale. 5. List the five most-mentioned open issues / TODOs Sentra has seen in the last 30 days. Output a single onboarding card, no longer than one page, that an engineer can read before opening their first PR.

See it work

Run it from

ClaudeCursorChatGPTAny agent · MCP

How it runs

  1. 01Copy the prompt into any agent connected to Sentra over MCP.
  2. 02The agent reads the company memory, scoped to what you are allowed to see.
  3. 03One grounded answer comes back, with every line traceable to its source.

Or automate it with Actions

The same prompt runs as a Sentra Action: on a schedule, or on a semantic trigger. Output lands in Slack or email, and every send waits for your approval.

Trigger idea: new-engineer onboarding

Sentraover MCPOwner, incidents, live decisions, one gotcha

billing-service · what to know

Ownership

runbook + rota

Devon owns it; on-call rotates with Jonas. Escalation goes through #payments-oncall, not the general rotation.

Last 90 days

design review · Aug 8

Three incidents, all clustered around invoice retry. The August design review agreed to split the retry queue; unshipped.

The gotcha

#incidents · Jul 30

Staging shares the production rate limiter. Load tests in staging have paged on-call twice.

The prompt above becomes this. Fictional data, real mechanics: every line cites the meeting, thread, or record it came from.

Without Sentra

  1. 01Search GitHub CODEOWNERS for the service path. Cross-reference with the active PR reviewers.
  2. 02Pull PagerDuty service mapping for the current on-call rotation.
  3. 03Search Slack for ownership posts ('I own X', 'I'm taking over Y') over the last 6 months.
  4. 04Pull the three most recent incidents from PagerDuty. Read post-mortems for root cause summaries.
  5. 05Search for design docs and ADRs touching the service. Read each to extract decisions.
  6. 06Compose the onboarding card.

~60,000 tokens

With Sentra

  1. 01Resolve the service as a `Value Object` — joined across repo, CODEOWNERS, PagerDuty, observability, and Slack ownership posts.
  2. 02Current `Actor` owner(s) and on-call rotation are typed.
  3. 03Pull the three most recent linked `Incidents` with extracted root cause.
  4. 04Pull the five most recent `Decisions` about the service with `Rationale`.
  5. 05Open issues / TODOs Sentra has seen in the last 30 days are surfaced.
  6. 06Compose the card.

~33,000 tokens

Book a DemoStart Free