Skip to main content
A Capability is a durable organizational ability that a team owns, operates, and continuously improves. Examples: employee onboarding, lead qualification, customer escalation, month-end close, security review, product launch coordination, contract review, incident investigation, renewal management. A Capability is not a single prompt. It is not a single conversation. It is not a workflow. It is not an agent process running on one employee’s laptop. It is a living organizational asset.

Where a capability comes from

People seek progress. A Job describes the progress a person or stakeholder wants to make in a particular situation. A Job is demand-side. A Capability is supply-side: the durable organizational ability created to deliver that progress repeatedly. You don’t have to learn a methodology to use JoyStream. Joyvis uses the Job lens in conversation to clarify who needs progress, what situation creates the need, what outcome is desired, why it matters, what prevents it today, what must be true for the Job to be complete, and what evidence would prove success. Those answers become part of the capability spec. The Job explains why the capability should exist. The capability is the ability created to fulfill it.

What a capability holds

A capability has identity, purpose, owners, stakeholders, versions, executable realizations, operational history, evidence, memory, and measurable outcomes.

The capability is not the agent

One capability may initially be realized by one primary agent. Over time the same capability may involve several AI agents, human operators, human reviewers, specialized recipes, multiple deployments, and different execution environments. The capability persists across different agent versions, different recipes, different models, different skills and tools, different deployments, different employees, and different organizational structures.
The agent is not the enduring organizational asset. The capability is.
The division of labor:
  • The capability spec defines it.
  • The agent realizes it.
  • The runtime recipe structures it.
  • Runs execute it.
  • Epics and stories organize its work.
  • Tickets make the work visible.
  • Evidence establishes trust.
  • Memory helps it improve.
  • The team owns it.

What this buys you

Because the capability is the durable object, a team can always answer:
  • What did we intend?
  • What agent did we build?
  • What plan did it execute?
  • What was deployed?
  • What version ran?
  • What evidence was produced?
  • What changed afterward?
Capabilities compound. Every review makes them more trustworthy. Every execution makes them more capable. Every shared capability makes the next one faster to engineer and safer to deploy.

Next

Capability spec

The declarative definition and trust contract.

Agents and recipes

How a spec becomes something that runs.