Use cases

Internal support deflection

What it is. Route repetitive customer questions to a grounded agent that drafts a response and keeps a human in the loop for anything sensitive. The business value is measurable deflection: a drafted answer is cheaper than a support headcount, and the reviewer keeps control of the final word.

1. 1

   Create the knowledge base

   One subject, one authority: returns, policies, FAQs. Pin an embedding model and wait for every document to be Indexed.
2. 2

   Create the drafting sub-agent

   Role Sub-agent, provider and model chosen in Environment. Write the job: ground every answer in the attached knowledge, cite sources, and set requires_human=true for account, payment, legal, or low-confidence cases.
3. 3

   Attach knowledge and memory

   Add the knowledge base in the Knowledge tab. Enable Memory so repeated questions resolve faster on later tickets.
4. 4

   Test in Playground

   Ask a normal question, an ambiguous one, a sensitive one, and one that must refuse. Confirm citations appear and the draft is grounded, not invented.
5. 5

   Deploy and integrate

   Enable deployment in Settings, then create a scoped snl_agt_ key in Integrate.
6. 6

   Import tickets

   POST customer tickets to the public support-case endpoint. Sentinel returns a draft and its sources; a reviewer approves, edits, or escalates in Support cases.

• The agent drafts; nothing is ever auto-sent.
• Reviewers check cited evidence before approving.
• Escalations keep the draft visible for follow-up.
• Metrics: first-response time, deflection rate, cost per resolved ticket.

Grounded research desk

What it is. Let any employee ask a question and get an answer that cites the exact documents it came from. Built for consulting, legal, HR, and engineering teams drowning in runbooks, policies, and manuals — answers are traceable back to source, so they can be audited.

1. 1

   Create one knowledge base per domain

   Compliance, HR policy, and runbooks stay separate so retrieval stays clean. Use per-knowledge-base embedding models and test each base's retrieval directly.
2. 2

   Create a research agent

   Role Fleet agent so it can hold an end-to-end conversation. Instruct it to cite sources and refuse when evidence is missing or conflicting.
3. 3

   Attach only the needed bases

   Grant access per job. A policy-desk agent does not need runbooks.
4. 4

   Wrap it in a fleet for harder questions

   Knowledge retrieve → Verify (citation coverage, minimum evidence) → on no_evidence, fall back to Web search or a clarification step.
5. 5

   Deploy and share

   Enable deployment and expose it to teammates through the public API or the support-case flow.

• Every answer carries sources you can open in the run trace.
• Out-of-scope questions are refused, not guessed.
• Quality is bounded by your documents — GIGO applies, so curate sources.

Governed back-office fleets

What it is. Multi-step operations work — claims, order triage, review pipelines — where intake, verification, decision, and execution are separate, approval gates sit at the boundaries, and cost is capped. This is Sentinel's most differentiated capability.

1. 1

   Build the intake specialist

   Role Tactical node with a small structured response: category, severity, requires_human, confidence.
2. 2

   Create the fleet

   Mission Start → intake agent → If / Else on requires_human.
3. 3

   Wire the low-risk path

   A verification agent calls an External API or MCP tool to check the order or claim, then a deterministic Response node declares the final output.
4. 4

   Wire the high-risk path

   Assemble an escalation package, pause on a Human approval node, then continue after the decision.
5. 5

   Add guards

   Set a token budget, per-node retries, a fallback agent branch for provider outages, and a Verify node for schema and evidence checks.
6. 6

   Test, evaluate, publish

   Run the normal, sensitive, missing-evidence, and rejected-output paths in Playground. Run the evaluation suite, then publish and integrate with a snl_flt_ key.

Embeddable AI for your product

What it is. Ship an AI capability — policy Q&A, an assistant, a guided form — inside your own product without building orchestration, RAG, observability, or deployment from scratch. Your customers call Sentinel's public API; you never expose your orchestration.

1. 1

   Build and test the agent

   Knowledge, tools, structured output, and a thorough Playground pass, plus an evaluation suite.
2. 2

   Enable deployment

   Undeployed agents reject public calls.
3. 3

   Issue a scoped key

   Create an snl_agt_ key in Integrate and call the public chat endpoint from your application.
4. 4

   Release safely

   When you change the prompt or model, re-run evals, promote, or roll back to a known-good version from version history.
5. 5

   Watch production

   Open runs to see latency, tokens, and cost; keep run IDs for support.

Live operations through connectors

What it is. Give agents real access to the tools the business runs on — Slack, Notion, Salesforce, an internal API — so they complete actions, not just text. Connectors use real OAuth 2.1 and API-key authentication over MCP.

1. 1

   Add the connector

   In Tools, add the server URL and authenticate with OAuth or an API key header.
2. 2

   Discover and review

   Sentinel performs the MCP handshake and lists the server's tools and contracts. Read each before assigning.
3. 3

   Assign narrowly

   Attach only the tools one agent needs. Least privilege, not full-server access.
4. 4

   Guard sensitive calls

   Put a Human approval node before any irreversible or account-changing tool call, inside a fleet or as a policy on the agent.
5. 5

   Test and observe

   Run a harmless test call, monitor tool analytics and latency, and watch invocations in run traces.

Guardrailed agent releases

What it is. The trust layer. Every prompt, model, or tool change is validated against a test suite before it can ship, and any regression can be rolled back to the last known-good configuration.

1. 1

   Write an evaluation suite

   Inputs with expected success or failure, optional output-contains text, expected JSON, and a minimum-evidence requirement.
2. 2

   Deploy through the gate

   Deployment is blocked until the suite passes against the current definition (fingerprint-gated), so a change cannot silently ship.
3. 3

   Re-run after every edit

   A prompt or model tweak that regresses quality is caught before release.
4. 4

   Compare traces

   Use trace comparison on a run from the previous version and the next version of the same input to confirm the change did what you intended.
5. 5

   Roll back when needed

   Restore a known-good version from version history and re-test the failing inputs in Playground.

• Include at least one out-of-scope or prohibited input per agent.
• Treat version history and evaluation summaries as part of the audit trail.
• Your evals are only as good as the cases you invest in writing.

AI spend observability

What it is. Know what every run costs — tokens, latency, provider, and whether it fell back to a secondary model — and catch runaway agents before the bill surprises you.

1. 1

   Read the run ledger

   Every agent and fleet execution records outcome, tokens, estimated cost, and trace steps.
2. 2

   Watch the dashboard

   Agent performance, event success rate, and provider usage give the operating summary.
3. 3

   Bound fleets

   Set token budgets, retry limits, and approval gates so a misbehaving run cannot spend without limit.
4. 4

   Use infrastructure surfaces

   The backend exposes usage, budget, health, and recommendation endpoints — wire them into your own monitoring and cost tooling.