Actspan Try Actspan with one real workflow
Which actions may your agent take, which need a person, and which must stop?
This trial connects the workflow definition, supported execution controls, evaluation results, and recorded actions so your team can review that question with concrete evidence. Start with one operational problem and a bounded slice of an agent you already operate.
Before you begin
Choose one action your team needs to account for and identify the engineer who owns its execution. Expected first result: an agreed allowed/reviewed/denied outcome and a supported path to check for integration fit.
This trial is for AI platform and engineering teams with an agent in or near production, a consequential tool action, and a real investigation or review process. Bring the engineer who owns the workflow; include a security reviewer when access or approval requirements are part of the problem.
Examples include reviewing a refund before it is issued, approving an infrastructure change, or investigating why an agent called a particular tool. A successful sample run alone does not establish value for your team.
First try the public refund walkthrough after the installation check. It is the self-service starting point; the working session below is assisted. Before sharing a sample, agree on data handling and use synthetic records.
What you can bring
Bring an existing workflow and select a meaningful slice that can be expressed in Actspan's native YAML execution path. Existing Python functions or HTTP tools can be reused where their contracts fit the supported tool interface. See workspace tools and workflow authoring.
The native path is an adaptation exercise: record the effort needed to represent the slice and connect its tools. A supported Python LangChain agent can instead keep its implementation and use the optional external-agent adapter. That path requires a declaration and callback integration and governs only the calls it mediates. It does not automatically intercept arbitrary LangGraph nodes, CrewAI agents or custom agent loops. Agree on controlled calls and uncovered paths before running either trial.
Use a test environment, representative inputs, and a safe substitute for any consequential external action. Keep credentials and sensitive records out of shared material. A live provider run requires your provider access and incurs its normal usage charges.
The working session
Allow a 15-minute fit check, then a working session of about two hours. In the fit check, choose the action to account for, the supported boundary, and the result that would make a second session worthwhile. If the slice cannot fit within the session, record that as an integration obstacle.
The session tests integration fit on one synthetic workflow slice. Bring working provider access, representative non-sensitive inputs, the tool contract and the person who owns it. You receive observed outcomes, a walkthrough of the evidence, setup effort and remaining gaps. It does not promise a completed production integration; a longer pilot or production rollout has its own agreed scope and commercial terms.
Before the first Actspan run, capture these six fields:
| Baseline field | What to record |
|---|---|
| Workflow and action | Owner, production status, action being investigated, and a representative input |
| Current evidence | Where configuration, tool activity, permissions, approvals, and outputs are found |
| Current process | Steps and people needed to establish what ran and who approved it |
| Observed effort | Time spent on those steps; label estimates separately if direct observation is unavailable |
| Required controls | Allowed and denied tools, approval requirements, and the boundary where each must hold |
| Success measure | The specific improvement you would need to use the workflow again |
Then work through the slice:
- Express its definition and tools in YAML; record adaptation and setup time.
- Attempt an action that should be denied and confirm the callable does not run.
- Run the permitted path. If approval is required, check the missing-approval path and the authorized path separately.
- Evaluate representative outputs against agreed criteria and inspect the execution records, control coverage, and any missing evidence.
- Repeat the original investigation or review task using the resulting records.
You leave with a written before-and-after comparison: setup effort, investigation or review effort, observed outcomes, supported controls, and remaining gaps. Report measured time savings only when there is an observed baseline. End by deciding whether another workflow is worth testing and what budget, if any, would justify continued use.
Optional assisted authorization proof
The free CLI and native examples are public downloads.
For an additional deterministic authorization proof, request the matching proof bundle
from your Actspan contact
for the matching proof bundle and follow its included INSTALL.md. The starter
bundle does not imply access to the product source or its internal test scripts.
Check the proof bundle's supplied checksum before extraction and verify its
SHA256SUMS manifest. Its installation notes identify the required runtime,
extra files and exact command for that proof. It uses temporary fixture tools,
deterministic model responses and synthetic approval state; the proof itself
needs no provider key or live model, portal or infrastructure call. Installing
its dependencies is a separate step.
Expected proof outcomes:
| Case | Expected execution outcome |
|---|---|
| Allowed read | Read callable executes; mutation callable does not |
| Forged denied mutation | TOOL_NOT_ALLOWED; mutation callable does not execute |
| Registered but unadvertised mutation | TOOL_NOT_ALLOWED; mutation callable does not execute |
| Missing approval | TOOL_APPROVAL_REQUIRED; no model or tool call executes |
| Synthetic approval present | Permitted mutation callable executes |
Inspect the supplied report's expected and actual results and artifact identity. A failed case means that proof has not established its expected control. A source-proof result alone does not qualify a different installed release or customer environment.
What this proof establishes
The proof exercises named Python function authorization on the native execution path: a denied or unadvertised call cannot reach dispatch, and an approval requirement is checked before execution. It uses deterministic model responses and synthetic approval state; it does not authenticate a human reviewer. Authenticated portal decisions require their own test.
Python tools are trusted code. These checks do not sandbox their internals or prove coverage of provider-hosted tools, MCP servers, external frameworks, or calls made outside Actspan's integrations. Installed-runtime qualification is separate from the proof; use the matching supplied 0.2.0 artifacts and record the versions actually checked.
To discuss a trial, bring the workflow owner, the action you need to account for, and how your team answers that question today. Start with that problem; choose the integration scope and acceptance measure together.