App Orchestration: Durable Workflow Rules

An App is a control plane, not a pile of workflow cards

An App can own discovery, outreach, reply handling, approval, and delivery workflows, but cards placed next to each other are not automation. The App's orchestration surface persists explicit rules: a typed source event, target workflow, optional filter, input mapping, coalescing policy, and activation condition. It also identifies the operator-facing entrypoint. A Run pipeline action starts that entrypoint only; it must never silently start every workflow that happens to have no dependency.

Completion is not permission to progress

A settled run proves only that its graph reached a terminal state. Business progression normally listens for run.accomplished — a verified-success verdict — rather than run.completed. A genuine inbound reply, a human approval, a provider receipt, or a verified datastore change can be the event that advances the next stage. This is how an App waits for real external input without treating a completed task, an agent self-report, or a display order as success.

Rules are executable, inspectable, and durable

Agents author these rules with agentis.workflow.rule; operators can inspect and edit the same rules in the App's Orchestration panel. Each candidate activation is journaled with a stable event/delivery identity and a payload snapshot before it enters the normal run queue. Leases, compare-and-set claiming, idempotency keys, bounded retries, and stale-lease recovery mean an event is not lost merely because a worker restarts or a provider call is temporarily unavailable. Delivery evidence is visible to the operator instead of being inferred from a workflow card's position.

Static prerequisites still have a narrow job

dependsOn remains useful for simple, static prerequisites inside an App. It does not model human replies, consent, provider callbacks, verified outcomes, payload transformation, or resilient retries; use an orchestration rule for those. The App Doctor checks that an App's visible controls, entrypoints, trigger nodes, success contracts, rules, and surfaces agree. agentis.app.doctor.repair can apply only deterministic, intent-preserving fixes; anything that would choose a workflow, credential, channel, or business policy remains an explicit review item.

Build order and runtime activation are different contracts

An App plan can say that the reply workflow is built after outreach without claiming that outreach completion should execute it. Each workflow now carries an explicit runtime activation shape: verified after_success, an external event, or an operator entrypoint. Event-, channel-, webhook-, listener-, and schedule-driven roots remain enabled for their real persisted sense while operatorEntrypoint:false keeps Run Pipeline from starting them manually. App Doctor reports an error if an event-only root has no subscription, conversation stage, schedule, or trigger that can actually reach it.

Doctor checks consistency; App Compile proves executability

A clean App Doctor report is necessary but no longer treated as proof that an App can complete its job. agentis.app.compile is the read-only pre-execution compiler: it joins topology, activation, definitions of done, current-graph dry-run and test-suite evidence, runtime credentials and capabilities, channel resolution, conversation enrollment and reachability, and surface operability into one report. The report deliberately separates structuralReady from executableReady, then returns ordered zero-cost remediation calls.

Compile has three proof targets. debug must pass before the first paid or world-touching test, production additionally requires a current-graph accomplished debug proof, and unattended additionally requires hardened workflows and durable activation. App-associated workflow runs and Run Pipeline consult this compiler as an admission gate; a model cannot spend its way through a predictable configuration failure.

Closed-loop reachability includes runtime identity

A stage label in a CRM row is not conversation enrollment. App Compile follows each conversation script from its initial state to a reachable terminal state, verifies that its contact collection can persist address, connectionId, and stage, and detects business records that copy script states without becoming resumable runtime contacts. It also rejects a workflow that is both conversation-event-owned and chained through dependsOn. This proves there is one executable wake path from a real inbound event to the next workflow, not merely a diagram that resembles one.

Run Pipeline continues; Fresh Run is explicit

The normal Run Pipeline command resumes at the first unresolved business frontier. A workflow whose current graph already has an accomplished run is reused, while the first failed or deficient stage is started; successful roots are not paid for again. An already-active frontier is reported and left alone rather than duplicated, even when that workflow normally permits parallel starts. A root replay is still available, but only as the explicit fresh mode or when changed inputs make reuse unsafe. Before any App-wide start, the production App Compile report is the release gate; an operator may still supply an explicit audited override reason when deliberately accepting its blockers.

The interface cannot overrule the control plane

The Orchestration Panel already owns Run Pipeline and per-workflow Run controls. Surface generation is instructed not to manufacture a second custom pipeline button, and App Doctor flags duplicate orchestration actions when both are present. The same truth rule applies to agent prose: when an agent declares the App done or ready from an App viewport, Agentis reconciles that claim against the live Doctor report before persisting the answer. Remaining blockers are appended visibly, so a confident model response cannot turn a broken App green.

Continue