Context

Evaluating how to build the workflow layer (thought TTMS): a way to chain the agent fleet + scheduled jobs into automated multi-step workflows, e.g. the cold-lead pipeline (lead-finder → @sales-researcher → @salesperson → inbox monitoring).

This is not greenfield. The decisive frame is TWUX (decided) — the orchestration console — which already sets the umbrella model: everything is a RUN = a trigger (on-demand / scheduled / inactivity) + a target, and it explicitly names "an agent workflow (ordered multi-agent steps)" as its north-star target type, watched on the /jobs console across three lanes (Schedule / Now-running / History). So TTMS's real job is narrow: define the agent-workflow target type + how it's authored and executed, slotting into TWUX's run model — not a parallel orchestration system.

The primitives a workflow needs mostly already exist:

Steps = agent-routed tasks (TCZY: agent_route + execution, done_when), executed by the task pipeline (the engine).
Step transitions = agent-to-agent handoffs (TVOZ, durable, delivered on boot or nudged live).
Triggering = the scheduled-jobs registry (TUM2 done) + TACU's cron primitive + existing event hooks (webhook / IMAP inbound).
Human-in-the-loop = a manual step — agent_route NULL (TCZY), never auto-run — e.g. "approve emails before send".
Observability = the TWUX /jobs console (already decided).

The genuine gaps are: (a) a first-class workflow definition + run record, and (b) structured state/artifact passing between steps (today's handoff is free-text; a cold-lead run needs to carry the actual leads + enriched records).

Full evaluation — this settles the abstraction later work (TUDU, T5M0) builds on and is expensive to reverse.

Criteria

Reuse over rebuild (highest) — lean on TWUX / task pipeline / TVOZ / jobs / TCZY; avoid a second orchestration engine.
Time-to-first-working-workflow — get the cold-lead pipeline (TUDU) running end-to-end soon.
Agent-authorable — Baseops authors config from briefs (scaffold, agent-architect precedent); a workflow should be definable by an agent, not only by hand.
Right-sized for one operator — no durable-execution heavyweight; observability = the existing console.
Fit the eventual vision — Azeem asked for a designer / UI; the path must lead there, not away from it.

Options (authoring surface — the fork Azeem named)

Option	Fit against criteria	Verdict
A. Visual node/edge builder first (n8n / Flowise style)	Matches the stated "designer" vision, but highest build cost and — critically — bakes a graph-editor over an unproven execution model. Over-fits before we know how agent chains actually fail (retries, partial completion, long research steps, approvals).	Defer — it's the end-state UI (later phase), the wrong first step.
B. Config/DSL definition (declarative workflow spec parsed by a runner)	Version-controllable, agent-authorable, cheap. A good substrate: the definition format under an author. On its own it's a text file with no author + no run model.	Fold in as the definition format, not a standalone answer.
C. Scaffolding skill + first-class run record (compose existing primitives)	A `/workflow` skill turns a brief into a workflow definition (B) + wires agent-routed steps + a scheduled trigger + manual checkpoints, producing a first-class `workflow_run` that IS a TWUX run. Lowest new surface; reuses the whole stack; proves the model on TUDU.	Recommended first step.
D. New durable-execution engine (Temporal / Inngest style)	Real retries/signals/state — but a second engine parallel to the task pipeline; overkill for one operator.	Reject — the classic "built too early".
E. Do-nothing / defer	Compose by hand each time (thought + tasks + job). Baseline; the primitives exist but there's no reusable workflow object.	Reject — TUDU/T5M0 want the reusable layer.

The options aren't mutually exclusive: C authors B, producing runs in TWUX's model; A is the later UI over the same definition. They sequence rather than compete.

Recommendation

Compose, don't rebuild — and sequence the UI last. (confidence: medium-high)

Define the agent-workflow as a first-class definition + run — lightweight workflows (ordered steps: each step = an agent + a prompt/task + a done-condition; edges = handoffs) and workflow_runs (a run holds a shared JSON context/artifacts blob — the state-passing gap). A workflow_run is a TWUX run (trigger + target).
Author it via a /workflow scaffolding skill first, not a visual builder — brief → definition, wiring the right agents (@sales-researcher, @salesperson…), a scheduled_job trigger, and manual checkpoint steps. Prove it by running TUDU (cold-lead) end-to-end.
Execution reuses everything: agent-routed tasks (engine) + TVOZ handoffs (transitions carry a pointer, run record carries artifacts) + scheduled_jobs/TACU (trigger) + manual agent_route NULL steps (approvals) + TWUX /jobs (observe).
Then build the visual node/edge designer as a thin UI over the proven definition model — the "designer" Azeem pictured, cheap once the run model is stable.

State passing: prefer a checkpointed run record with typed step payloads over threading artifacts through free-text handoffs — the handoff signals the transition + a pointer, the workflow_run.context holds the data. This is the pattern LangGraph converged on at 1.0 (Oct 2025): explicit interrupt points, typed handoff payloads, checkpointed state — the research names "making state transitions explicit and typed" (not a visual layer) as the actual gap in a system like ours. (confidence: medium)

This matches Baseops precedent: TWAB shipped the build-queue mechanism before any UI; agent-architect is a skill not a form; TUM2 was deliberately kept light. Ship the run model, prove it on one workflow, then draw the designer over it.

Scheduled trigger→lead-finder→@sales-researcher→Approve emails · manual→@salesperson→inbox monitor

The first workflow to prove the model — the TUDU cold-lead chain, one manual gate before anything sends.

External evidence (2026 orchestration landscape)

A survey of the four paradigms (visual builders, config/DSL, durable-execution, agent-native) backs the sequencing:

A visual canvas is a rendering over a state machine, not the source of truth — Step Functions' Workflow Studio and n8n's canvas are both views over an underlying JSON/DAG spec. Building the canvas before the schema is stable means rebuilding engine and UI on every model shift.
What durable-execution vendors report teams regret building too early: (a) a visual canvas before retry/idempotency/HITL-suspend semantics are settled; (b) a full cluster-based orchestrator (Temporal-style) before workflow shapes are proven — the DBOS / Restate "library over Postgres" pattern (both GA'd 2024) is the closer analogue to a SQLite-first single-operator design; (c) generic conversational multi-agent loops before role/handoff boundaries are explicit — borne out by AutoGen moving to maintenance mode (late 2025) while narrower explicit-handoff models (CrewAI Flows, OpenAI Agents SDK, Mar 2025) gained ground.
Baseops' existing agent_handoffs + scheduled_jobs + done_when already map to the durable-execution primitives (signal, suspend/resume, explicit acceptance) on a relational model — so the compose-first path is the mainstream one, not a shortcut.
Watch for graph shape: LangGraph (1.0 GA Oct 2025) is the model to emulate if workflows need dynamic LLM-decided branching / cycles — its typed-state + conditional-edge design, not a drag-canvas, is the answer there.

Risks and tripwires

Shape mismatch. The motivating example is a linear chain (find→enrich→draft→monitor), which is exactly why compose-first works. Tripwire: if the first real workflows need branching / conditional routing / parallel fan-out from day one, a visual DAG builder + a real engine become justified earlier — re-weigh D and A.
State blob sprawl. If workflow_run.context becomes a dumping ground, formalise per-step typed inputs/outputs.
Trigger drift. Event triggers (new lead, inbound email) must ride existing hooks, not a new scheduler — stay inside TWUX/TACU.

Sources

Internal: TWUX (orchestration console, decided — the umbrella run model), TUM2 (jobs registry, processed), TWAB (build queue), TVOZ (agent handoffs), TCZY (agent_route + execution + manual = agent_route NULL), TACU (cron→task shim), TUDU + T5M0 (first workflows), T9XY / TS5B (the agents each step uses).
LangGraph 1.0 GA (Oct 2025) — typed state, conditional edges, interrupt() checkpointing.
OpenAI Agents SDK (Mar 2025, superseded the experimental Swarm) — explicit handoffs + tracing.
AutoGen → maintenance mode (late 2025); community fork AG2; CrewAI Flows — the shift to explicit-handoff over conversational loops.
DBOS / Restate (GA 2024) — "durable execution as a library over Postgres", the single-operator analogue vs cluster-based Temporal (2019) / Inngest (2022).
n8n / Zapier / Make / Step Functions (ASL + Workflow Studio) — visual canvas as a view over a JSON/DAG spec; approval nodes pause the whole run coarsely.