> ## Documentation Index
> Fetch the complete documentation index at: https://docs.joystream.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Use cases

> Five organizational capabilities, and what building each one in JoyStream looks like.

A capability is recurring work an organization must do well. These five are common starting points. Each follows the same shape: a Job someone needs done, a capability that fulfills it, an agent that realizes it, and evidence that proves it worked.

Pick one that a team already owns and already does by hand. The best first capability is one where someone can tell you, precisely, what a good outcome looks like.

## Employee onboarding

**The Job.** *When a new employee is joining, I need them fully prepared before day one so they can become productive immediately.*

**What it does.** Validates the employee record, creates accounts across the systems they need, provisions approved applications by role, notifies their manager, and verifies completion.

**The hard parts.** Access varies by role and location. Contractors follow a different path. An account creation that half-succeeds is worse than one that fails outright.

**What proves it worked.** Not that the provisioning APIs returned success — that the right person has the right access, and their manager confirmed readiness before the start date.

**Where the boundaries go.** Standard access provisions automatically. Anything above a threshold escalates for manager approval rather than being granted.

## Lead qualification

**The Job.** *When an inbound lead arrives, I need to know quickly whether it's worth a salesperson's time.*

**What it does.** Enriches the lead from available sources, scores it against your criteria, routes qualified leads to the right owner, and records why each decision was made.

**The hard parts.** Enrichment sources disagree. Criteria change quarterly. A false negative is invisible unless you look for it.

**What proves it worked.** Qualification accuracy measured against what the sales team concluded afterward — not the number of leads processed.

**Where the boundaries go.** The agent scores and routes. It does not email a prospect.

## Customer escalation

**The Job.** *When a customer issue is escalating, I need the right people to have the full picture fast.*

**What it does.** Gathers account history, prior tickets, and recent activity; summarizes what happened; assembles the right responders; and opens a ticket that a person can act on immediately.

**The hard parts.** Context lives in several systems. Urgency judgments differ. Over-escalation trains people to ignore escalations.

**What proves it worked.** Time to a first informed human response, and whether responders had what they needed without going and looking.

**Where the boundaries go.** The agent assembles and notifies. It does not commit to a remedy or make a promise to a customer.

## Month-end close

**The Job.** *When the period ends, I need the books closed accurately and on time.*

**What it does.** Pulls the ledger export, reconciles statements, flags variances above a threshold, and opens a ticket for each one with the evidence attached.

**The hard parts.** A variance can be a timing difference or a real error, and the distinction requires judgment. Silent success is dangerous — a reconciliation that finds nothing may mean everything matched, or that it looked in the wrong place.

**What proves it worked.** The close completed on time, and every variance above the threshold was surfaced with enough evidence for someone to resolve it.

**Where the boundaries go.** The agent reconciles and reports. Adjusting entries stay with a person.

## Security review

**The Job.** *When a change touches something sensitive, I need it reviewed consistently, not when someone remembers.*

**What it does.** Triggers on the change, collects the relevant context, runs the review checklist, and produces findings with citations — or states plainly that it lacked the evidence to complete.

**The hard parts.** "No findings" and "couldn't check" look identical unless the capability distinguishes them.

**What proves it worked.** Reviews completed correctly, with a clear record of what was examined and what was not.

**Where the boundaries go.** The agent reviews and reports. It does not approve.

## What these have in common

Each is owned by a team, not a person. Each recurs. Each has an outcome you can state before you build anything, and check afterward.

That last property is what makes a capability a good candidate. If you can't say in one sentence what would prove it worked, the capability isn't ready to build yet — and the conversation with Joyvis is where you find that out cheaply.

## Getting started with yours

<Steps>
  <Step title="Write down the outcome">
    One sentence. What is true after a successful run that wasn't true before?
  </Step>

  <Step title="Write down the evidence">
    What would you look at to confirm it? That becomes the trust contract in the capability spec.
  </Step>

  <Step title="Draft it">
    ```bash theme={null}
    jstm agent plan --new
    ```

    Joyvis asks about boundaries, escalation, and failure. Your answers become policy.
  </Step>

  <Step title="Dry-run it and compare">
    Run it with side effects held back, then compare the result against the outcome you wrote down. That comparison — not the absence of errors — is the signal.
  </Step>
</Steps>

<Columns cols={2}>
  <Card title="Build your first agent" href="/guides/build-your-first-agent" icon="hammer">
    The full path, end to end.
  </Card>

  <Card title="Capabilities" href="/concepts/capabilities" icon="box">
    Why the capability, not the agent, is the asset.
  </Card>
</Columns>