Skip to main content
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

1

Write down the outcome

One sentence. What is true after a successful run that wasn’t true before?
2

Write down the evidence

What would you look at to confirm it? That becomes the trust contract in the capability spec.
3

Draft it

Joyvis asks about boundaries, escalation, and failure. Your answers become policy.
4

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.

Build your first agent

The full path, end to end.

Capabilities

Why the capability, not the agent, is the asset.