Why Actspan

Keep control as your AI agents change.

A workflow name can stay the same while its prompt, model, tools or policy changes. Actspan connects the configuration being reviewed with its allowed actions, evaluations, approval decisions and execution evidence on supported paths. Start with one consequential action and test whether that connection closes a control or investigation gap for your team.

Start here

Expected result: identify one control gap and the supported workflow on which your team can test it.

Applies to Actspan CLI 0.2.0. Qualification depends on the exact build, provider and integration. The release verification matrix retains the test dates and version tuples; the release notes retain the public binary's known limitations. External research has a separate review date in evidence context.

Path	Available proof and boundary
Public native OpenAI refund	Public CLI and examples; automatic, local approval/continuation, rejection and service refusal. Local reviewer names are labels.
Bundled Claude / isolated Anthropic	Public bundled automatic case has narrower qualification; the separate isolated package has its own broader refund results.
LangChain	Matching adapter required; local approval-required refund is denied, rather than paused for native-style continuation.
Portal	Partner access; published browser proof is historical core 0.1.2. Deployed identity-provider and reviewer authorization need their own qualification.

Try the public governed refund, after the small installation and hello check.

A policy changes after evaluation

Baseline: evaluate the reviewed workflow with its declared tools and policy.
Change: remove or add a tool permission. The workflow name stays the same, but its supported configuration identity changes.
Old evidence: the previous result cannot satisfy the changed candidate's required evaluation gate on the supported release path.
Rerun: test the affected candidate and capture matching evaluation evidence.
Deployment: deployment-bound execution checks the local configuration against the promoted release before the workflow begins.

This depends on using the required release checks and deployment-bound execution; ordinary local calls do not automatically acquire a release gate. See the release identity boundary.

The governance contract

Carry the reviewed configuration and its evidence through development, delivery and operation. The contract connects requirements and revision identity; it does not govern every external dependency. Develop the declaration, test the supported controls, then inspect the resulting execution and missing evidence.

Where Actspan fits

A useful fit is a team that cannot reliably connect an agent change, its allowed actions, evaluation results, approval and resulting execution. Bring an agent owner and one tool action that matters: a refund, ticket write or other bounded operation. Your service keeps business authorization, ownership and persisted records; Actspan governs the configured execution path around it.

If your existing platform already connects those controls and records on the paths you need, measure whether Actspan adds enough value to justify integration. A single agent with a simple rule may need only checks in your application. YAML, dashboards and the control-plane category do not establish a unique benefit.

How existing solutions compare

Evaluation, observability, cloud policy and internal platforms already solve parts of this problem. Compare the missing connection on your actual stack, including the engineering work to integrate and maintain it. The comparison questions and primary references help scope that discussion; they do not imply automatic integrations or exclusive capabilities.

How we measure value

For the first session, agree on three outcomes:

Prohibited actions are blocked for the intended reason; legitimate cases are checked too, so a false block does not count as success.
Allowed actions complete, with review where the selected path requires it.
The team can trace the outcome to the reviewed configuration, decisions and independent service receipts, with missing evidence visible.

Record integration effort and remaining gaps alongside those outcomes. Choose additional trial measures only when they answer an agreed question. These are proposed acceptance criteria, not measured customer improvements or a universal model-accuracy guarantee.

Current capabilities and boundaries

The documented implementation includes declarative agent configuration, static dependency impact, supported native policy checks, evaluations, local run inspection and comparison, and recorded usage and cost. Configuration fingerprinting, release decisions, deployment binding, and revision evidence packages support connected delivery workflows. The evidence reference explains matching rules and missing records. Control verification describes which enforcement checks can be exercised today.

Boundary	What to account for
Agent identity and permissions	Declared names, ownership, and configuration identity identify the governed agent. They do not authenticate a customer or grant record-level access; the application and its authorization systems own those decisions.
Dependency and drift inspection	Static inventory covers declared workspace dependencies. Recorded-run comparison and lockfile checks help inspection; they do not discover every agent or continuously monitor every external change.
Execution outside Actspan	External calls do not automatically inherit Actspan controls. Mandatory routing may require credential, identity, network, or runtime integration. Coverage must be demonstrated.
Remote or dynamic dependencies	The configuration fingerprint does not identify remote MCP data, resolved environment values, or arbitrary external code. A provider's implementation can change without a local configuration change.
Verification scope	Supported native checks are scoped. Full workflow graphs, live MCP behavior, and unsupported adapters must not be reported as verified.
Evidence integrity	Hashes detect changes to recorded packages. They are not signatures or independent proof that the publishing runtime reported truthfully.
Cost visibility and controls	Recorded token usage and latency plus pricing-based cost estimates are not exact invoices or measurements of CPU/GPU consumption. Supported policy estimates and checks are distinct from a universal cumulative spending cap. The agent `runtime.budget_usd` field is not enforced today.
Release availability	Confirm supported commands and behavior in the release you install; a roadmap item or passing test is not a production-readiness certification.

See agent runtime limits and policy enforcement before relying on budget or runtime declarations.

What comes next

Deepen the control and evidence on the selected workflow before expanding its scope. Broader integration, signed attestations, traffic controls and hard cumulative financial limits need additional implementation and qualification; see the proposed directions. No roadmap item is implied by an existing schema field.

Start with one consequential workflow

We are inviting design partners to validate this workflow in their environments. Bring a specific control or investigation gap. Together we agree on scope, evidence, success measures and commercial terms before a trial. A first session produces a small synthetic proof, observed results and a list of integration gaps; production rollout is a separately agreed step.

See the working-session agenda, review product data handling, or contact info@actspan.com.