Connect → Capture → Deliver — how people actually use ASB

Automation usually becomes expensive at the point where a useful demonstration must become something other people can run. A person can show an AI what to do, or record a browser and desktop sequence, but the result often remains tied to the authoring tool, an online model, or the machine on which it was created. Automation Skill Builder (ASB) is designed around that hand-off: use the most convenient way to teach the work, then turn it into a local artifact that can be inspected, moved and run again.

The distinction matters because designing an automation and running it are different jobs. AI may be valuable while the process is being understood. It need not remain in the execution path forever. ASB records or authors the operational steps, keeps the result as readable code, and can package that code for repeatable execution.

01The hand-off ASB is built to solve

Most automation products start by asking which recorder, agent or API you will use. ASB starts one step later: what must remain after that tool has finished helping? The answer should be more durable than a chat session. It may be an editable Python script, a scheduled application, or a skill that another agent can discover and invoke.

This is why the three bands in the figure are deliberately separate. Connect describes who can reach the builder. Capture / Author describes how knowledge becomes executable steps. Host & Deliver describes what survives the design session. They are not three stages that force everyone through the same interface; they are choices around one local control plane.

02Three ways the work begins

Let an AI agent perform the task once

An MCP-capable agent can operate ASB while you describe the outcome. ASB records the concrete calls made during that session and turns them into a replayable script. This suits work whose logic is easier to explain than to record manually: combining file operations, OCR, desktop actions and APIs in one flow. AI helps discover the procedure; the recorded procedure becomes the asset.

Demonstrate the work yourself

For browser and desktop work, a person can still be the best teacher. Playwright captures web interaction; ASB's built-in actions capture supported desktop operations; UIA/G4 remains an optional route when ordinary desktop capture is insufficient. The important point is not the recorder brand. ASB brings the captured steps back into the same script-and-package pipeline.

Author for a machine that is somewhere else

Sometimes the design machine cannot access the final application, or the production host must remain offline. In that case an agent can write from an approved skill set and a scenario without executing the target process locally. The script is reviewed, copied to the destination and run there. Authoring and execution are separated without turning the automation into an opaque cloud service.

03Choose the artifact, not the authoring interface

Once the procedure is stable, the right output depends on who will own it next:

• Recorded script when a developer or operator must inspect, edit, test or adapt the logic.
• Executable or app when the job should be launched or scheduled like ordinary local software, without requiring an AI call for each run.
• Skill package when the capability should remain discoverable and reusable by AI agents through MCP or FastSkills.

The same automation can move through more than one form. A readable script can be reviewed first, packaged as an executable for operations, and also published as a skill for agents. “Deliver” is therefore not an export button at the end of a recorder; it is the decision about how the capability will live.

04What “zero Cloud/AI calls at runtime” actually means

It does not mean that an automated task can never call a web service. A workflow may still use the business systems and APIs it genuinely needs. The claim is narrower and more useful: ASB does not require a model call merely to decide the next recorded step every time the automation runs. AI can help create or repair the procedure, while the normal execution path remains deterministic and local.

That separation controls cost, latency and data exposure. It also makes failure easier to diagnose: an operator can inspect the script and the execution log instead of reconstructing a decision hidden inside a past conversation.