FEATURE W1.1
Describe it; get a plan you can argue with
P0Effort LPhase 1Agent + compiler exist
Benefit. The distance from "I wish this happened every Monday" to a runnable automation is one sentence and one read-through. For the business: this is the feature that makes automation a chat product rather than a builder product — and the reason a non-technical user finishes what they start.
Depends agent step (W2.3) · CAPS catalogBlocks W1.5 test runInstrument
workflow_compiled · workflow_plan_edited · workflow_publishedProblem. A form-first builder asks the user to know the step vocabulary before they can express the intent. Most people can describe the outcome and cannot name the steps — so they either give up at the empty canvas or build something wrong and only find out at run time.
Starting point: the agent already plans multi-step work and the engine already compiles a step list to a runnable script. What's missing is showing the plan as a reviewable contract — with checkpoints already placed — before the first run.
The compile contract
Compilation is deterministic in one respect that matters: checkpoint placement is a separate pass, not a suggestion from the model. The compiler walks the generated steps, finds the first one flagged external, and inserts a checkpoint before it. The plan the user reads has already satisfied WINV-1; they are approving the shape of the work, not remembering to add a safety gate.
// compile(text) → plan, then a separate checkpoint pass
plan = {
steps: [ { id, capId, label, config, parentId, branchKey } ],
triggers: [ { capId, config } ],
vars: [ { name, producedBy, readBy[] } ], // drives W1.3's pills
inserted: [ "chk_auto_1" ] // what the compiler added, called out in the UI
}
// the floor, in code — this is WINV-1
insertCheckpoints(steps, policy):
if !policy.requireCheckpoint: return steps // "unless workspace policy allows"
before the first step where CAPS[capId].external and no checkpoint covers it,
splice an auto checkpoint. A manual approval step already satisfies the floor.
Whether the floor is one checkpoint per workflow (as written) or one per external step is WQ2 — a one-line change, deliberately not decided in code.
Stories
W1.1-S1Describe → compiled plan preview
- One free-text field with three worked examples; no required fields, no step picker, no connector picker
- Returns a numbered step list within 10s p95, each step showing its category tag (Workspace · Connector · Agent · App) and the connector it will use
- Auto-inserted checkpoints are visually distinct and labelled "added — nothing external runs before this"
- Anything the compiler couldn't resolve appears as a named gap ("which Jira project?"), not a guess
- Steps requiring a capability above the workspace's current phase render locked, with what unlocks them and when
W1.1-S2Argue with the plan
- Refine by replying in English ("skip clients with nothing shipped") — recompiles, and diffs against the previous plan rather than replacing it silently
- "Edit steps" opens the same plan on the canvas (W1.2) with no data loss in either direction
- Removing the auto checkpoint is refused with the reason and who can change it, not greyed out without explanation
- The plan is a draft — private, unpublished, not schedulable, and clearly marked so
W1.1-S3Author from a Room
- Describing a workflow to the agent in a Matrix Room produces the same compiled plan, posted in-room as a message
- The in-room plan carries a link to the canvas; per Surfaces the canvas itself is not rendered in-room
- Publishing from chat requires the same test-run prompt as the web path — the surface changes, the gate doesn't
W1.1-S4Full-agent mode
- A one-line goal can be saved without compiling to fixed steps — the agent decides the path at run time (the milestones' authoring Mode 1)
- Even undecided, the external boundary is fixed at authoring time: the user names which connectors are in scope and the checkpoint still precedes any external act
- The run view shows the path the agent actually took, so an agent-mode run is auditable after the fact even though it wasn't planned before
Mockup — the compiled plan
New Workflow draft — not yet published
Schedule Mondays 8:00
Asked in chat "run the client report"
+ add trigger
Every Monday, pull last week's Jira activity per client, draft an update email for each, and send after I approve.
mika
Here's the plan — 5 steps, one checkpoint:
1 · Pull last week's activity — 6 projects · Jira
2 · Summarize per client · Agent step
3 · Draft 6 updates · Gmail
4 · Send to each contact · checkpoint — added, needs you
5 · File replies, close the run
One thing I guessed: "last week" means the previous Mon–Sun. Say so if you meant rolling 7 days.Before it runs
Test run first? External sends are stubbed — you'll see exactly what would go out.
Two triggers on one workflow (W4.2) — Slack would need two workflows kept in sync by hand. Step 4 says added: the compiler placed it, and the plan says so rather than pretending the user asked for it.