Skip to main content
A workflow is a triggered, contract-defined automation. Workflows with interfaces (a patient intake form that routes to a clinician dashboard) and workflows without interfaces (sync a new HubSpot contact to Stripe and post to Slack) are the same primitive — authored the same way, executed on the same runtime. Workflow type is implicit, not chosen. You do not pick “interactive” vs “automated” at creation. State intent; the system compiles a contract; the contract’s trigger and step composition determine whether a UI surface is part of the workflow.

​
Trigger taxonomy

The trigger is the anchor of every workflow. The system surfaces the trigger question early when intent is ambiguous: “What starts this workflow?”
TriggerShapeExamples
User interactionUI-backedForm submission, button click, page load
External eventHeadlessHubSpot contact created, Stripe payment received, EHR record updated
ScheduleHeadless”Every Monday at 9am…”, “On the 1st of each month…”
WebhookHeadlessInbound HTTP from a configured external source
ManualEitherHuman-initiated run via the test/run console
Agent invocationEitherAgentCaller per the A2A protocol on a delegated authority chain
Data-change eventEitherEntity record or field changes in the project
Trigger determines center-pane mode: UI-backed workflows show the live app; headless workflows show the test/run console.

​
Multi-trigger workflows

A single workflow can have more than one trigger when the trigger shapes are compatible.
ClassSupportedDescription
Class A — Same shape, same schema✅ V1Multiple triggers of the same type producing the same payload. E.g., two webhooks for different referral partners both feeding the same intake logic.
Class B — Same shape, different schema✅ V1Multiple triggers of the same type with different payloads. Each trigger maps its payload into a normalized first-step input via per-trigger entry steps.
Class C — Mixed shape🔄 Counter-proposedMixed trigger types implying different workflow shapes. The system proposes two sibling workflows that share steps.

​
Data-change triggers

Data-change events fire when an entity record or field changes inside the project. They are the substrate for cross-workflow communication. Every data-change event carries:
FieldDescription
entityEntity type (e.g., patient)
fieldSpecific field, or * for record-level changes
actorIdentifier of the actor that caused the change
actor_typeuser / agent / workflow / integration
beforePrior value (null for created records)
afterNew value (null for deleted records)
atTimestamp
Workflows filter on any combination. The actor metadata is load-bearing for cycle prevention: a workflow that writes to an entity and listens to changes on the same entity filters its own writes out with actor != self. The system proactively detects potential loops whenever a workflow is compiled or modified. If your workflow’s writes could trigger another workflow that writes back to the same entity, the advisor surfaces the loop and proposes a guard.

​
Authoring a headless workflow

For workflows without a UI, the center pane is the test/run console. Use it to:
  1. Compose a trigger payload — The system generates a sample payload matching the trigger schema. Edit values to match your test case.
  2. Run — Fires the workflow against sandbox data. Integration calls are edge-sandboxed (never real in sandbox mode).
  3. Inspect the trace — The trace view shows every step, input, output, decision, and side effect. See Trace & Replay.
  4. Iterate — Refine in chat. Run again.

​
Authoring a UI-backed workflow

For workflows with a UI surface, the center pane is the live app. The rendered form or dashboard runs against sandbox data. You interact with it exactly as your users will, submit forms, and watch the trace update in real time.

​
Deterministic vs. agentic steps

Workflows can mix deterministic steps (conditional branches, data transformations, integration calls with fixed schemas) and agentic steps (AI inference calls that produce variable output based on context). Agentic steps run through the AI Gateway — every inference call is PHI-guarded, audited, and governed by your org’s model policy. You do not specify model or provider directly; the system selects per your org’s configuration and tier. When authoring an agentic step, describe the intent:
“If the intake summary indicates urgency, classify the risk level as low, medium, or high.”
The system compiles a step with: model call, prompt anchored to the intake entity fields, output schema (risk_level: enum[low, medium, high]), and an explicit confidence threshold you can tune.

​
Agent-invoked workflows

Workflows with audience Agent-callable can be invoked by an AgentCaller under delegated authority — no human in the loop. The delegating user’s authority bounds what the agent can do; the audit chain records every invocation, every tool call, and the full delegation chain. See A2A Protocol.

​
Step graph inspection

After the system compiles or updates the contract, the contract view (right-side panel) shows:
  • Each step with its type, inputs, outputs, and conditions
  • Entity references and field dependencies
  • Integration calls with payload schema
  • Branching conditions
  • The trigger definition
The contract is human-readable and stable across sessions. It is the audit subject and the runtime’s input.

​
Common authoring patterns

Conditional routing:
“If risk is flagged high, page the on-call clinician. Otherwise, assign to the next available slot.”
Parallel steps:
“At the same time, notify the billing coordinator and update the scheduling system.”
Error handling:
“If the EHR call fails, retry twice, then flag the record for manual review.”
Schema changes:
“Add a field to track whether the patient has given consent for AI-assisted notes.”
Schema changes are surfaced as explicit confirmation gates because they have migration consequences.