Evaluate one business action under real operating constraints.

Choose a workflow that can teach you something

The best candidate is important enough to justify evaluation but narrow enough to inspect. A process owner understands its rules. The normal path is repeated. The input and result can be described. Exceptions are known or discoverable. There is a source-system fact that can prove whether the action succeeded.

Avoid starting with an entire department, application, or end-to-end transformation. Also avoid a showcase workflow chosen only because it is easy. The pilot should test the access, control, and evidence questions that would determine whether the capability can become operational.

Prepare the workflow brief

• Business outcome and current manual handoff.
• Application, version, delivery environment, role, and authentication constraints.
• Available APIs, exports, events, or existing automation and why they do not fully cover the action.
• Required inputs, record preconditions, permitted effects, and business validation rules.
• Approval conditions, sensitive data, and access boundaries.
• Normal exceptions, duplicate risk, rollback or reconciliation path, and operational owner.
• Authoritative evidence of a correct outcome.

Agree on acceptance criteria before implementation

Acceptance criteria should describe business correctness, not simply task completion. Define which representative cases must succeed, which invalid or unauthorized cases must be rejected, how duplicate requests behave, and what happens when the application or session is unavailable.

Include an evidence requirement for each successful effect. Define what counts as uncertain completion and how it is reconciled. If the pilot will not test production volume, security review, failover, or a particular application version, list those gaps instead of allowing a narrow result to imply broader readiness.

Build the action boundary

The workflow is represented as a tool with a clear schema, preconditions, policy, and result. The interface path sits behind that boundary. The calling agent requests the business operation rather than controlling the entire application.

During discovery, the team maps screens, state transitions, validation, confirmations, and exceptions. The resulting adapter should stop when its expected state cannot be established. Human approval and operator handoff can remain part of the design where risk or uncertainty requires them.

Exercise failure, denial, and drift cases

A happy path is necessary but not sufficient. Test missing and invalid input, stale record state, policy denial, rejected approval, duplicate submission, session expiry, interruption after submit, unexpected warnings, unavailable application, and a deliberately changed interface assumption.

The expected behavior is not always automatic recovery. For some conditions, the correct result is a structured stop, preserved context, and an operator queue. The pilot should make that boundary visible before anyone discusses unattended operation.

Review evidence and decide the next scope

The pilot review should identify the exact cases and environment evaluated, results against the acceptance criteria, remaining exceptions, control gaps, maintenance assumptions, and unresolved production requirements. A successful technical path may still be a poor operating fit if exceptions are too frequent or ownership is unclear.

Possible outcomes include proceeding to a controlled rollout, revising the workflow, keeping a human in the execution loop, using an existing API or automation instead, or deciding that the action is not suitable. A rigorous “not yet” is more useful than one happy-path run presented as deployment proof.

What a pilot does not establish by default

• Support for untested application versions, configurations, roles, locales, or delivery environments.
• Production capacity, availability, recovery, or concurrency characteristics that were not exercised.
• Compliance with a regulatory regime or completion of the buyer’s security review.
• Suitability for other workflows in the same application.
• Autonomous operation for actions that still require judgment, approval, or reconciliation.

Frequently asked questions

How many workflows should the first pilot include?

Usually one well-defined action creates the clearest evidence. Adjacent operations introduce separate effects, permissions, exceptions, and tests and should not be treated as free scope.

Does the pilot need a production account?

The environment must be chosen with the buyer’s security and operational owners. A non-production environment may be appropriate but can differ materially from production; those differences should be recorded.

Can the pilot include human approval?

Yes. Approval can be part of the target operating model and should be tested as a policy condition, including rejection and expiry behavior.

What counts as pilot success?

Success is agreement against predefined workflow criteria: correct effects, enforced controls, useful failure behavior, trustworthy evidence, and understood operating limitations.

Is there a fixed pilot timeline?

No timeline is claimed here. Scope depends on the application environment, access, authentication, workflow variability, controls, evidence, and stakeholder availability.