Pre-read · Automations backlog review

Automations Open Decisions

Five questions that each currently cost the build something specific, and two things to confirm. Each comes with what we'd recommend, so the fast path is agreeing or overruling rather than starting from scratch.

For Joshua Moore From engineering 5 decisions, 2 confirmations Target: MVP, end of September

Where things stand

The work is now 32 issues in Linear, organised by how the system is layered rather than by feature area — each layer has to be settled before the next one can be built against it:

Every question below sits at layer 1, 2 or 3 — which is why they're worth ten minutes now rather than being discovered later. Answering them late doesn't just delay work, it means rebuilding things that were already finished.

Decisions

each one unblocks named work
01

Can one workflow have more than one trigger?

Why now

It's the open TBD in Configurable Workflow Steps — "if a request being created or edited triggers the same auto-assignment flow." A saved workflow currently has exactly one trigger. The builder and the diagram both render whatever a workflow can contain, so answering this after they exist means rebuilding both and migrating every workflow already saved.

TODAY — TWO WORKFLOWS When created When edited Routing tree module → type → assign Routing tree module → type → assign same tree, kept in sync by hand WITH SUB-WORKFLOWS When created When edited calls calls Triage routing module → type → assign one flow — change the carpenter once
The difference is the number of copies, not the number of triggers. Today, wanting the same routing on create and edit means maintaining two identical trees — and remembering both when a request type or an assignee changes.

Options

  • Composable sub-workflows. A workflow can reference another as a step, as drawn above. This is also the "nested workflows" idea from the design review.
  • Several triggers on one workflow. Closest to the literal ask, but it changes the stored shape of every workflow.
  • Neither for MVP. Guidance becomes "build two workflows"; revisit if customers hit it.

What composability buys

  • One place to change a shared rule — add a request type once, not once per trigger
  • Workflows small enough for a person to read; the routing tree stops being copied into every rule that needs it
  • A natural unit to test: dry-run the shared flow once, not per copy
  • Answers the trigger TBD without migrating stored workflows

What it costs

  • We must make loops impossible to author — A calls B calls A
  • Indirection has a comprehension cost. "What happens when a request is created?" now needs two things read instead of one
  • A versioning question: does a caller follow the shared flow's edits, or pin the version it was built against?

We'd recommend

Composable sub-workflows. No migration, and it turns a duplication problem into a reuse feature customers asked about independently.

The comprehension cost is real and worth designing against — the diagram in decision 04 is most of the answer, since a shared flow drawn inline reads as one picture again.

Blocks: branch authoring and the workflow diagram — together the largest remaining build.

02

Is custom JavaScript in the MVP?

Why now

It's a named topic for this session, and it points the opposite direction from how the engine is built. Today every action is a named block, the engine can describe exactly what a workflow would do before it does anything, and there is exactly one place in the code where a change to FMX happens. That's what makes "preview it safely against live data" true. Arbitrary JavaScript trades all of that for expressiveness.

Option What it can express Preview stays safe What it costs to build
Not in MVP Named blocks only — plus whatever the LLM-with-a-schema step covers Yes, unchanged Nothing. We learn what's actually missing from real workflows
Isolated runtime Anything a customer can code Yes — the boundary holds, since the block still takes structured input and returns structured output A new service, sandboxing, secrets, and its own failure modes
JavaScript inside the engine Anything No. We can no longer say what a workflow will do before it runs, and the single-write-site guarantee goes Least code, most risk

We'd recommend

Not in MVP, with the isolated runtime as the shape if and when we do it.

Worth testing something first: the criterion itself expects these blocks to be mostly LLM-written. If that's true, the LLM-with-a-schema approach we agreed on may already cover most of what anyone would reach for JavaScript to do — and we'd rather learn that from real workflows than guess now.

03

Is workflow load ordering still shelved?

Why now

It was shelved at the design review and that's probably still right — but if composable sub-workflows land (decision 01), workflow-calls-workflow becomes literally the "one or more workflows triggering one or more others" case the criterion describes. Worth re-confirming with that on the table.

What shelving actually means, precisely

We can prevent runaway loops — a workflow can't trigger itself indefinitely, and the engine recognises its own changes so it doesn't react to them. We cannot say which of two workflows wins when both fire on the same request and set the same field. Both run, the last change sticks, and the order is not something anyone chose.

We'd recommend

Stay shelved for MVP — and say it plainly to pilot customers rather than letting them discover it. "Don't build two workflows that set the same field on the same trigger" is a livable instruction for a small pilot and an unacceptable one at GA.

04

Is the workflow diagram September scope?

Why now

It arrived in Configurable Workflow Steps during the review pass — "easy to visualize and communicate the overall workflow from FMX" — and hasn't been sized or scheduled since. It's a real build, not a finishing touch.

AS A LIST OF STEPS If Module is Maintenance If Request type is Carpentry Assign to Carpenter Otherwise Assign to Supervisor every step at the same level — which action sits under which condition is nowhere on the screen AS A DIAGRAM Module is Maintenance Type is Carpentry Assign to Carpenter Assign to Supervisor else the same five steps — the nesting is the thing you can now see
Both sides are the same workflow. This is the PRD's own carpentry example at two levels deep; real ones go deeper. The diagram isn't decoration on top of branch authoring — past one level it's the only way an author can check they built what they meant.

And a second reason it may be more central than it reads

LLM-Built Workflows wants to accept a customer's diagram as input. Same visual vocabulary, opposite direction — worth designing once rather than twice.

We'd recommend

A read-only diagram in MVP, built alongside branch authoring rather than after it. Reading a customer's diagram to generate a workflow is a GA feature.

05

Does usage pricing need Iris counts at launch?

Why now

Run History notes that usage-based pricing is being explored around how often Iris is used successfully per run. Whether that's a launch requirement changes when we build the counting, and the difference in cost is large.

The shape of it

Recording each LLM step — which workflow, which run, succeeded or not — is nearly free at the moment we build the first LLM block, because that's when the code is open anyway. Adding it afterwards means going back through shipped code and backfilling history we never captured.

We'd recommend

We record it regardless, starting with the first LLM block — that part isn't worth debating at its price.

What we need from you is narrower: whether the reporting — counts visible to customers, or to us for billing — has to exist at launch or can be a fast-follow.

Confirmations

quick, but they cost us if left

06 · There's a blank acceptance criterion

An unnamed row with no details, marked deleted, still linked to the PRD. Debris from an accidental add, or something that was meant to be filled in and got lost? We've left it out of planning entirely, so if it was real, it's currently invisible.

07 · Linear is where engineering tracks this

The board's been shared. You'd mentioned possibly using the office site for formal tickets — just confirming so we don't end up maintaining two half-records. Notion stays the requirements source of truth either way; Linear is only the work.

The one thing to do after the meeting

Mark the reviewed criteria as Reviewed in Notion. That status is the signal we use to move an issue from "requirements not settled" to "ready to pick up" — seven Linear issues are currently held back by it:

And one thing worth knowing about how we read your edits: changes to a criterion's Details are as useful to us as status changes, sometimes more. The last pass added Status as a branch property, added the diagram requirement, and renamed Iris to "an LLM" — all three reshaped actual work, not just its readiness. So edit freely; we diff the details, not just the checkboxes.