[Workflow tool] argsPath: let a file-based / visually-authored spec be the canonical workflow input (SOLO FDE use case)

Summary

Add an argsPath: string parameter to the Workflow tool — a path to a file
on disk whose contents become the workflow's args global, as an alternative
to passing args inline. The motivating purpose here is different from the
one in #63102: this is about letting a file-based, often visually-authored
spec be the canonical, reproducible input a workflow runs from — not about
resume-cache hit rates. The two are complementary; same parameter, different
why.

Relationship to #63102

#63102 asks for the same parameter to fix a mechanism problem: an LLM
dispatcher can't transcribe inline args byte-exactly across turns, so the
resumeFromRunId cache silently misses. That's real and still stands. This
issue is upstream of that: it's about *where the input comes from in the first
place*. Even with no resume in play — a single clean run — the input to a
workflow is frequently a structured artifact that already lives on disk and is
owned/versioned outside the chat. Today there's no way to point the workflow
at it; the contents have to be inlined as JSON into the tool call. Closing
this also happens to close #63102, but the case for it doesn't depend on the
cache at all.

The use case: the SOLO FDE operator authoring workflows as shapes

A growing pattern (and the one driving this for me): a solo
forward-deployed-engineer-style operator — one person doing team-shaped
delivery, amplified by agents — for whom deterministic workflows are the core
unit of work. The relevant thesis is that *most of what gets called an "agent"
is really a deterministic workflow*; the non-deterministic, intelligence-
requiring step should be the small exception, and everything around it should
be structured, repeatable workflow. The Workflow tool is exactly the right
primitive for that worldview.

The way that operator authors these workflows is visually — in shapes: a
D2 diagram, a hand-drawn graph on a canvas, an ASCII DAG. The diagram is the
spec — fan-out here, a verify gate there, a synthesis node at the end. There's
already a natural path from a drawn graph to a runnable workflow: a generation
step turns the shapes into a workflow script plus a structured args object
(node config, per-branch parameters, the working state the script reads from
args). That structured object is the canonical, machine-produced
representation of the picture the operator drew — and it lands as a file on
disk.

Why the input wants to be a file, not inline JSON

The drawn-shape → args-object artifact is:

• machine-generated and structured — it's not prose a human typed into a

prompt; it's a serialized graph/config that should flow into the run
byte-for-byte as produced;

• the source of truth — the operator edits the shape, regenerates the

artifact, and expects "run the workflow" to mean "run exactly this artifact";

• something they want to version-control and diff — the spec for a piece

of delivery, checked in next to the code it operates on;

• portable — a SOLO FDE's whole model is "build the workflow, drop it

where it needs to run." The spec being a file means the same artifact can be
handed to another harness and run deterministically, instead of being
trapped as inline text in one chat turn.

Inline-only args breaks every one of those. The canonical artifact has to be
re-serialized into the tool call — and when the dispatcher is an LLM, "re-
serialized" means summarized / reformatted / re-quoted / key-reordered. The
direct line from the shape I drew to the run that executed is severed: the
run is no longer reproducible from the artifact, can't be cleanly version-
controlled, and can't be picked up and re-run elsewhere from the file alone.

argsPath restores that line. The file is the source of truth; the workflow
reads it by reference; the bytes that reach the run are exactly the bytes the
generation step produced. The operator can re-run "the diagram," version it,
diff it, and hand it off — none of which inline args supports.

The ask

A way to make a file on disk the canonical args input to a Workflow run —
the cheapest shape being an argsPath: string parameter that, when present,
loads args from that file (parsed as JSON, or surfaced as raw text — your
call) instead of from inline args. As in #63102, there may be a better shape
(content-addressed args, an args handle returned from the tool result,
something else); the requirement is just that a durable, externally-authored
artifact can be the workflow's input by reference, so visually-authored /
file-based workflow specs become reproducible, version-controllable, and
portable.

For my own work this is the difference between "deterministic workflows I draw
as shapes" being a real, repeatable delivery primitive versus a thing that
only works inside a single live chat turn.