What Is a Capability in UMA?
The portable unit of behavior that UMA tries to keep coherent.
UMA becomes practical when its building blocks are explicit. This area defines the units that stay stable across runtimes and the rules that keep behavior, policy, and orchestration understandable.
These pages describe the vocabulary used to model capabilities, workflows, runtime responsibilities, and the active descriptors that let a system remain discoverable without turning the runtime into a black box.
The UMA core model has four main concepts: capability, workflow, runtime, and active descriptor. Understanding them in relation to each other matters more than learning them in isolation. A capability is the unit of portable behavior the runtime can reason about. A workflow is the approved sequence of capabilities the runtime assembles to satisfy a goal. The runtime is the governed authority that validates, approves, and records execution. The active descriptor is the machine-readable contract that makes a capability discoverable and composable.
None of these concepts require a specific language, framework, or platform. They describe a discipline for how services declare themselves, how runtimes make decisions, and how systems stay explainable as they grow.
This area also covers two boundaries that teams often leave implicit: the agent-versus-runtime boundary (where AI proposal stops and runtime authority begins) and late-bound policy enforcement (how runtime decisions stay governed without hardwiring policy into service logic). Both are practical concerns that surface quickly once a system tries to do anything non-trivial with portable services.
The portable unit of behavior that UMA tries to keep coherent.
How capability execution becomes an inspectable progression of steps.
The governed execution layer that decides where behavior can run.
The responsibilities that should remain runtime-owned.
How descriptors keep runtime capabilities visible and queryable.
How policy stays authoritative without freezing the model too early.
Why runtime decisions need to be explainable after the fact.
How discovery and runtime integration meet in a portable model.
Why agents and runtimes are related but not interchangeable.