Invocable Capabilities in AI & Software Systems

• Invocable capabilities are minimal, self-contained units of functionality with structured interfaces that enable secure and reliable AI agent execution.
• They distinguish between direct permission and indirect authority, supporting both software contracts and cryptographically secured, remote or hardware-mediated access.
• These capabilities underpin AI agent interfaces by promoting explicit contracts, composability, and modular design across distributed and embedded systems.

Invocable capabilities are authority-bearing units of invocation whose exact form depends on the surrounding research tradition. In AI-native software, an invocable capability is defined as “A minimal, self-contained unit of functionality that exposes a structured interface and can be reliably executed by an AI agent without human intervention” (Wang et al., 19 Mar 2026). In capability systems, the same expression refers more broadly to references, tokens, or hardware-supported handles that carry bounded authority over objects, memory, services, or effects, and whose possession enables invocation under explicit structural or cryptographic constraints (Huyghebaert et al., 2020). This suggests a shared core across the literature: invocation is mediated by a capability rather than by ambient authority alone, but the capability may be realized as a software contract, an object reference, a signed credential, a typed value, or a hardware-enforced pointer.

1. Invocation, permission, and authority

In the object-capability model, access rights are embedded directly in object references. If one object holds a reference to another, it can invoke that object’s behavior; if it does not hold such a reference, it cannot. The model distinguishes permission, understood as the right to directly access an object and invoke its behavior, from authority, understood as the ability to cause effects on an object, even without a direct reference to it. The formal treatment introduces notions such as current permission $CP(\sigma,o)$, eventual permission, current authority, and eventual authority, and uses reachable future worlds to separate direct invocation rights from indirect influence through call chains (Koepe, 2019).

This distinction is central to the meaning of invocable capabilities. A direct capability confers permission; indirect invocation paths may confer authority. The literature explicitly notes that a component may have permission but not authority, or authority but not permission, depending on whether it can directly reference a target or only cause another component to act on it (Koepe, 2019). A common misconception is therefore that capability possession and effective power are always identical. The surveyed formalizations reject that simplification.

A related operational view appears in remote invocation. The Remote monad exposes a remote wrapper Remote[T] with map, flatMap, and get, so that a remote reference itself becomes the capability to invoke methods on the encapsulated object. Possession of the handle is what authorizes remote method application; the underlying business object remains unchanged and need not implement java.rmi.Remote directly (Jolly, 2017). In this setting, an invocable capability is neither an ACL entry nor a mere identifier, but an invocation token that composes computation and authority.

2. Agent interfaces and AI-native architecture

In AI-native software design, invocable capabilities are presented as the primary abstraction of an agent interface. The proposed architectural progression has three stages: Human Interface Era, API-Centric Transition, and Agent Interface Era. The last stage exposes the system as a collection of capabilities, each with a clear contract, discoverable and composable by agents, and optimized for interpretability, reliability, and composability (Wang et al., 19 Mar 2026).

The literature is explicit that this shift is not just “GUI to API.” The deeper change is described as a move from perception-driven interaction to invocation-driven execution, from features/pages to capabilities/contracts, and from manual workflows to dynamic orchestration by agents (Wang et al., 19 Mar 2026). Traditional software is organized around visual navigation, manual workflows, and ambiguous interaction; agent interfaces instead require structured inputs, explicit semantics, validation, and capability selection and composition by an agent.

Several design principles recur. Machine interpretability requires explicit operation names, typed parameters, semantic descriptions, and clear state transitions. Composable capability design favors smaller building blocks over coarse “all-in-one” features. Explicit interface contracts require input schema, output schema, constraints, validation rules, side effects, and failure modes. Invocation reliability requires minimizing hidden dependencies, making error handling transparent, supporting safe retries, and ensuring sufficiently consistent repeated invocations. Context compatibility reflects the practical constraint that capability descriptions must be concise enough to fit agent context windows while remaining semantically precise (Wang et al., 19 Mar 2026).

This architectural view treats invocable capabilities as the software unit around which planning, discovery, and runtime orchestration are organized. A plausible implication is that the concept is simultaneously a modularization principle and an execution interface.

3. Cryptographic and distributed authorization forms

A second major lineage treats invocable capabilities as cryptographically protected authorization artifacts. In code capabilities, or codecaps, a capability is a pair

$c_n = \{h_n, k_n\},$

where $h_n$ is a heritage consisting of a chain of X.509 proxy certificates and $k_n$ is the private key of the last principal in the delegation chain. Each certificate carries a public key and a rights function, and a service executes a request only if the heritage is valid, the request signature verifies, and every rights function in the chain evaluates to true (Renesse et al., 2012). This makes invocation dependent on both possession and embedded executable policy.

In Web authorization, Verifiable Credentials are used as OAuth 2.0 access tokens that directly encode capabilities of the form

$C_{operation \rightarrow resource}.$

The authorization server issues a JWT/JWS containing a VC and a cnf claim binding the token to the client’s public key; the resource server accepts the request only if the token signature verifies, iss matches the authorization server, the cnf key matches the DPoP proof, and the requested action is allowed by the extracted capabilities (Fotiou et al., 2021). Here, invocation is not identity-based in the narrow sense; it is capability-based and proof-of-possession-bound.

The same literature extends capability invocation to ordered workflows. A master capability

$T_{AS} = (t, \mathcal{S}_{AS}(t))$

contains a finite permission sequence and a starting state. Each successful resource invocation advances the state and produces a new capability, while each resource server stores a local counter $rs_m$ to reject replay of older states. Context-aware constraints are enforced through Environmental Situational Oracles, and the paper proves a safety theorem showing that the distributed protocol simulates a centralized reference monitor (Li et al., 2022). In this variant, an invocable capability is not only “what may be done,” but also “what must be done next, and under which context.”

Commercial agent settings generalize the same idea further. In CPMM, a capability is formalized as

$C = \{ id, spec, proof, constraints \},$

or alternatively as $c = (\text{spec}, Q_c, cost)$. It is then discovered through the Agent Name Service, negotiated through ACNBP, bound to cryptographic commitments and payment conditions, invoked only after HTTP 402/X402/H402 payment steps, and finally audited (Huang et al., 4 Mar 2026). This makes the capability at once a security artifact, a service description, a pricing object, and a contractual authorization primitive.

4. Hardware-enforced and systems forms

Hardware capability systems interpret invocable capabilities as machine-level authority over memory or I/O. In uninitialized capabilities, a new permission U grants read authority only over $[cursor,end]$ and write authority over $c_n = \{h_n, k_n\},$0, with the capability tuple

$c_n = \{h_n, k_n\},$1

Writing immediately below the cursor decrements the cursor, thereby extending the readable region downward; loads are forbidden below the cursor, and ordinary cursor-changing instructions cannot move it lower. The intended use case is a secure calling convention in which a callee receives a stack frame it can write to but cannot inspect until it has initialized the memory itself (Huyghebaert et al., 2020).

For device access, CAPIO uses CHERI/Morello capabilities to create precise, sub-page “slices” of MMIO memory. Its architecture includes a pure-capability kernel, a kernel stub, a device manifest, an interface using sealed capabilities as identity tokens, and a slicer that intercepts mmap and returns bounded capabilities for approved registers only. On an Intel 82754L (e1000e) network card, the paper reports up to 46% reduction in 99th-percentile round-trip latency, corresponding to 235 µs → 162 µs, while enforcing byte-level access control of privileged resources (Doku et al., 18 Dec 2025). The key property is that the process can dereference only bytes covered by valid capabilities it has been given.

Capacity applies a similar capability logic inside a single ARM process. It uses Pointer Authentication and Memory Tagging Extension to turn file descriptors and memory pointers into cryptographically authenticated references, assigns each in-process domain its own PA key, and mediates reference usage through a syscall monitor and program instrumentation. The evaluation reports approximately 17% overhead for the single-threaded webserver and 13.54% for the multi-threaded webserver (Duy et al., 2023). In this literature, invocable capability means that the reference itself is a proof of authority, and that dereference or syscall use succeeds only in the right domain context.

These systems emphasize that invocation is not merely a software-level call. It can be a hardware-checked dereference, a register write, or a protected memory access whose legality is encoded in the capability representation itself.

5. Programming-language and type-system forms

Programming-language work often treats invocable capabilities as typed witnesses of resource state or effect authority. In revocable typestate, capabilities are decoupled from lexical scope and may be provided, revoked, and returned in a flow-sensitive manner. The notation ?=> denotes implicit capability parameters, =!> functions that kill a capability, ?<= functions that return a capability implicitly, and $c_n = \{h_n, k_n\},$6 expresses a state transition that receives an implicit capability, revokes it, and returns a successor capability (Jia et al., 10 Oct 2025). Path-dependent types preserve object identity, destructive effects track revocation order, and transitive disjointness handles aliasing.

A more abstract account appears in modal effect systems. There, a capability is a contextual permission to invoke an effectful operation, and capability-based systems are encoded not as effect rows on function arrows but as modalized values whose use is governed by effect contexts. The translation

$c_n = \{h_n, k_n\},$2

and

$c_n = \{h_n, k_n\},$3

makes the capability explicit as a modalized, invocable parameter (Tang et al., 14 Jul 2025). This identifies a precise difference between row-polymorphic effect tracking and capability-based tracking: rows classify computations by effects they may perform, whereas capabilities classify contextual resources that must be in scope to be invoked.

For AI agents, capture checking in Scala 3 turns tool use into statically mediated invocation. Capabilities are program variables reflected in capture sets such as $c_n = \{h_n, k_n\},$4. Local purity is then used to prevent information leakage: Classified[T] admits map[U](op: T -> U) only for pure functions, so a transformation over classified data cannot write to files, print, or invoke network actions unless the type system exposes the corresponding capability. In classified mode, the evaluation reports 100% security for both tested models, while task utility remains high, including 99.2% classified for Claude Sonnet 4.6 and 90.0% classified for MiniMax M2.5 on the reported trial set (Odersky et al., 1 Mar 2026). Here, an invocable capability is not just callable functionality; it is callable functionality whose authority cannot escape its typed lifetime.

6. Empirical applications and unresolved questions

Empirical work shows that invocable capabilities are difficult to use reliably even when interfaces are explicit. In NL2API evaluation derived from BIRD-SQL, the pipeline produces over 2500 APIs across SLOT-BIRD, SEL-BIRD, and REST-BIRD, with executable Python tools or FastAPI microservices. The main subtasks are intent detection, tool selection, sequencing with nested function calls, and slot filling. Reported completion rates are roughly 7–47% depending on the dataset, improving to about 50% for the best ReACT agents on REST-BIRD (Elder et al., 12 Jun 2025). The paper also finds that models often do better on SQL generation than on invoking equivalent APIs, suggesting that invocable capability use remains brittle under large tool inventories and strict argument structure.

Embodied AI extends the notion further by making perception itself invocable. VLA-Thinker treats visual perception as an explicit reasoning action, using a multimodal trajectory

$c_n = \{h_n, k_n\},$5

where ZOOM-IN can be called during inference to obtain task-relevant visual evidence. The reported results are 97.5% average SR on LIBERO, including 98.7% on Spatial and 96.9% on Long, with the paper noting that the current framework uses only one visual tool: ZOOM-IN (Wang et al., 15 Mar 2026). The invocable capability here is not an API endpoint but a callable perception operator inside a reasoning loop.

In manufacturing, MCP provides a lightweight operational substitute for explicit semantic modeling. A laboratory-scale evaluation exposes three capabilities—Spindle Speed Calculation, Drilling, and Mobile Robot Transport—as MCP tools, with Claude Desktop as the MCP client and Sonnet 4 as the LLM. Across four scenarios, the LLM successfully planned and executed multi-step tasks, handled invalid inputs, and recovered from lexical mismatch through tool use and dialogue (Silva et al., 12 Jun 2025). The authors nevertheless describe the study as a work-in-progress and note that reliability, robustness, and safety guarantees remain open.

Coding-agent work emphasizes the lifetime problem. PORTICO defines lingering authority as the condition in which a temporary resource/effect capability remains exposed after the episode that justified it has closed. It compiles a task contract into an initial envelope, grant rules, closure predicates, and global deny rules, and then manages a request–grant–invoke lifecycle using opaque, epoch-bound handles. In the closure experiment, PORTICO rejects 10/10 post-closure reuses, while the non-revoking comparator permits 10/10; in the stale-write audit, PORTICO records 0/6 executed forbidden effects versus 6/6 for the comparator (Santos-Grueiro, 21 Jun 2026). This makes revocation and planner-visible authority part of the definition of safe invocability.

Across these strands, several open problems recur. The AI-native software literature identifies capability granularity, standardization, security, misuse, and policy enforcement, and dual-audience systems as unresolved design issues (Wang et al., 19 Mar 2026). Other papers add narrower constraints: VC-based capabilities are not naturally sufficient for delegation and attenuation in the way dedicated capability systems are (Fotiou et al., 2021); codecaps make outstanding capabilities hard to enumerate globally (Renesse et al., 2012); hardware and monitor-based schemes depend on complete mediation and correct catalogs or manifests (Doku et al., 18 Dec 2025, Santos-Grueiro, 21 Jun 2026). The field therefore converges on a broad principle rather than a single formalism: invocable capabilities are mechanisms that make software authority callable, bounded, and composable, but the exact balance among expressiveness, safety, revocation, and reliability remains application-specific.