Spec-Driven: the one throughline across AI, harnesses, RPA, and ASB

A fact easy to overlook

Over the past two years, almost every conversation about "AI agents" has circled the same question: is the model smart enough, can it understand intent, can it plan on its own. But once you actually put an AI-driven automation into production — whether it's Claude Computer Use operating an enterprise system, or an RPA platform running a reimbursement approval — what decides success or failure usually isn't "did the AI understand correctly." It's how detailed the spec in the middle actually is.

This isn't a new insight. "Spec-driven development" has been part of software engineering for decades. But in the AI era it becomes central again, in a new way — because what AI provides is the ability to understand intent, not the ability to execute deterministically, and the two must be bridged by a reliable middle layer. That middle layer is the spec.

Three harnesses, one shared layer

If you think of "AI agent frameworks," "RPA platforms," and "local-first automation tools like ASB" as three different harnesses, they're actually solving the same structural problem: how to turn a vague, natural-language intent into a sequence of operations a machine can execute reliably and repeatedly.

These three harnesses look like competitors, but zoomed out, they're different stations on the same production line — and what actually moves down that line is the spec, not any particular platform's script format.

When a spec is broken down to coordinate level

This is the easiest part to verify in practice. Take a concrete example: a "record → analyze parameters → package as executable" task. Described in a single sentence ("record this reimbursement flow and turn it into a reusable tool"), neither AI nor a human can guarantee two runs produce the same result.

But once that sentence is broken down to this granularity:

• Action: which coordinate to click, single or double click
• Timing: how long to wait between steps, and why (UI transition lag, content-load lag)
• Input method: typed directly, or written to clipboard then pasted — and why (avoiding a search box's autocorrect or trigger behavior)
• Parameterization: which values are fixed sample data, which are placeholders meant to be swapped at use time
• Verification: how completion is confirmed (waiting for load, checking an element appears)

— this spec is no longer a description of intent, it's an executable specification close to pseudocode. The part requiring on-the-fly AI judgment has already been compressed to a minimum; what's left is almost entirely deterministic coordinates, delays, and parameter substitution. Which is the key point: once a spec is this refined, the platform executing it stops mattering as much.

Portability: one spec, two destinations

A spec refined to coordinate- and parameter-level has, in principle, at least two paths to production:

Path one · consumed directly in ASB

ASB's two-pass recording model (AI-assisted exploration → deterministic script solidification) is naturally suited to consuming this kind of fine-grained spec — recording, parameter analysis, and packaging into an exe can all be chained by AI through MCP tools, with a human only confirming parameter points and acceptance criteria.

Path two · rebuilt in traditional RPA via export–import

Provided every action primitive the spec describes (click, type, wait, branch) has an equivalent activity component on the target RPA platform. If that "equivalent" exists — say, Click, Type, and Wait Stage in Blue Prism — the spec can be translated, manually or semi-automatically, into the target platform's process definition without redoing requirements analysis and process modeling from scratch.

This means the spec itself has cross-platform portability, on one condition: the execution layer's action primitives have to line up. It's also why "which platform is better" is often the wrong question in enterprise implementation — the asset that's actually valuable is the refined spec, not a script file locked into one platform's format.

Where the spec comes from: authoring vs. AI audit

A fine-grained spec doesn't appear on its own — two production paths look practical today:

Method one · manual decomposition

Someone familiar with the business process and the target platform's capability boundaries — say, an engineer with RPA implementation experience — breaks a natural-language requirement down into a "step — explanation — note" structured document. High quality, strong control, but it depends on expert time, so throughput is capped by human bandwidth.

Method two · AI-audited generation

Tools like Screenpipe or ToDesk that continuously record screen activity and context let AI "audit," after the fact, a real human operation session — observing what was actually clicked, how long each pause lasted, what was typed, which branches came up — and reverse-generate a structured spec from it. The value here: the operator doesn't need to know how to write a spec at all, they just do their job normally, and AI translates "what already happened" into "a spec that can be repeated."

Why this throughline deserves to be taken seriously

Strung together, these observations lead to a conclusion more actionable than "can AI automate this":

• Understanding intent and executing deterministically should be decoupled. AI's uncertainty should be contained to the spec-generation stage; once the spec is solidified, execution no longer needs AI judgment.
• The spec is a portable asset, not a platform's byproduct. Enterprises should ask "how good is my spec-production and retention capability," not get locked in by one platform's execution features.
• The spec's auditability incidentally solves compliance. A spec refined to coordinates, parameters, and wait times is itself an auditable operation trail — extra value for industries with retention and traceability requirements.

This throughline — vague intent, to fine-grained spec, to deterministic execution — is also a more accurate lens for understanding what tools like ASB actually solve: not a smarter agent, but the shortest path from spec to an executable, distributable unit, without ruling out that same spec being re-consumed elsewhere.

Addendum: how the interface carries the harness through

The first six sections stay at the level of a framework. What follows comes from checking ASB's packaging wizard and runtime-settings screens directly — grounding "a spec should be explicit and portable" in a handful of concrete interface decisions.

The threshold is frozen; the execution environment isn't

The failure threshold (say, the HTTP-error-count threshold) gets written into the exe's own config at packaging time, and doesn't drift just because a colleague's machine has different global settings — the main path is deterministic. What's allowed to vary by machine is the execution environment: the trusted-AI endpoint, the post-run local script, whether OCR is on. Both live in "Settings," but they're not the same kind of thing and shouldn't be treated as one.

Failure detection is three layers, not one

The word "threshold" makes it sound like a single judgment mechanism. In practice there are three separate detection paths, each responsible for a different kind of failure:

• Infrastructure layer — HTTP status-code count threshold, catches "a request that should have succeeded, didn't."
• UI / business layer — a separate detection flow dedicated to catching unexpected pop-ups mid-run, catches "something happened that shouldn't have."
• Outcome layer (optional) — after processing multiple document types, a separate verification exe checks whether the final result is actually correct. Not standard by default; configured only where the business has cumulative effects worth checking.

The first two layers can prove "the run didn't derail" — they can't prove "the output is actually correct." In scenarios with cumulative effects, like reconciling several document types, every step can complete cleanly while the final total is still wrong; only the outcome layer catches that.

Making "the environment must match" a step the flow owns

Coordinate drift mostly doesn't come from switching platforms — it comes from ordinary changes in resolution or window position on the very same machine. Rather than relying on an implicit assumption that the environment happens to match, the flow itself opens by repositioning the window (to 0,0) and fixing its size — turning "the environment must match" from an easily-overlooked precondition into a step the flow is responsible for. Parameterization draws a clear line in the interface between test values and production parameters, so a sample document number can't quietly get run as production config. Sensitive credentials are read through a dedicated key-vault API, so they never enter the packaged artifact or the handoff process.

Taken together, these interface decisions answer the same question: the spec explicitly declares what it needs; the execution environment decides, per machine, whether it can meet that; a readable document sits in between to keep the two aligned — the same argument the article opened with, now backed by concrete product evidence rather than theory alone.