Runtime and identity

resolveRuntime runs per invocation, not once when actions are registered. That is necessary because the action description is static while the Model and principal are caller-specific.

When a contract declares authorize, the runtime must be bound with a principal provider of the matching type. This adapter intentionally does not infer application identity from arbitrary Agent Native context fields such as an email address. Mapping an authenticated host caller to your application principal belongs to the host/application boundary.

Availability is dynamic too. A capability can remain present in the static Agent Native registry while being unavailable in the current Model; the bound runtime refuses it at call time.

What run returns#

Application refusals are returned as application output, not thrown as adapter crashes:

{ ok: false, message: '…' }

That includes unavailable, unauthorized, cancelled, invalid-input, and failed completion outcomes.

A successful dispatch/completion returns ok: true. Agent Native may consider the framework-level action invocation itself complete, so consumers should read the returned ok value rather than assuming framework completion means the application accepted or completed the operation.

Only host/adapter defects are flattened to a generic failure message. Internal application errors are not exposed to the caller.

Why generate actions instead of writing them twice?#

The dependency direction stays one-way:

Foldkit Message + update
        |
foldkit-agent capability
        |
Agent Native action

Availability, authorization, input validation, and completion remain in the contract/runtime. The generated action adds no authority and no second implementation of the transition.

If the contract changes, the generated registry changes with it instead of leaving a hand-written action beside the application that can drift.

An application-local Agent Native action can still override an inherited/package action according to Agent Native's own registry rules.