> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflow Authoring

> Workflows are the runtime primitive in AI Studio — triggered, contract-defined automations authored through chat. UI is optional.

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?"*

| Trigger               | Shape     | Examples                                                                                  |
| --------------------- | --------- | ----------------------------------------------------------------------------------------- |
| **User interaction**  | UI-backed | Form submission, button click, page load                                                  |
| **External event**    | Headless  | HubSpot contact created, Stripe payment received, EHR record updated                      |
| **Schedule**          | Headless  | *"Every Monday at 9am…"*, *"On the 1st of each month…"*                                   |
| **Webhook**           | Headless  | Inbound HTTP from a configured external source                                            |
| **Manual**            | Either    | Human-initiated run via the test/run console                                              |
| **Agent invocation**  | Either    | `AgentCaller` per the [A2A protocol](/studio/a2a-protocol) on a delegated authority chain |
| **Data-change event** | Either    | Entity 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.

| Class                                      | Supported           | Description                                                                                                                                               |
| ------------------------------------------ | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Class A — Same shape, same schema**      | ✅ V1                | Multiple 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** | ✅ V1                | Multiple 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-proposed | Mixed 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:

| Field        | Description                                     |
| ------------ | ----------------------------------------------- |
| `entity`     | Entity type (e.g., `patient`)                   |
| `field`      | Specific field, or `*` for record-level changes |
| `actor`      | Identifier of the actor that caused the change  |
| `actor_type` | `user` / `agent` / `workflow` / `integration`   |
| `before`     | Prior value (`null` for created records)        |
| `after`      | New value (`null` for deleted records)          |
| `at`         | Timestamp                                       |

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](/studio/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](/platform/overview) — 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.

## Step types

You do not choose a step type directly — the system compiles one from your intent — but the contract view names it, and the trace shows it per step. The runtime supports:

| Step type           | Description                                               |
| ------------------- | --------------------------------------------------------- |
| `inference`         | Model call through the AI Gateway.                        |
| `tool_call`         | Invoke a HASP-supplied tool or a bound integration.       |
| `agent`             | Hand the step to an agent.                                |
| `agent_delegate`    | Delegate to another agent under the same authority chain. |
| `wait`              | Pause until a condition or timer resolves.                |
| `branch`            | Route down one of several paths.                          |
| `parallel`          | Run several steps concurrently.                           |
| `escalation`        | Escalate to a human for an approval decision.             |
| `action`            | Deterministic action step.                                |
| `condition`         | Evaluate a condition.                                     |
| `sub_workflow`      | Invoke another workflow as a step.                        |
| `workflow_schedule` | Create a scheduled future run.                            |
| `solve`             | Deterministic constraint solve over a declarative spec.   |

Two are worth calling out because they are not obvious from a chat description:

* **`escalation`** puts a human in the loop. The run pauses on an approval decision, with a timeout disposition deciding what happens if nobody answers in time. Use it for anything a clinician or compliance reviewer must sign off on.
* **`solve`** hands a declarative assignment or scheduling spec to the deterministic constraint solver rather than to a model. Same input always yields the same answer, and an infeasible spec comes back with the conflicting constraints named instead of a plausible-looking guess. Reach for it on rostering, slot allocation, and routing problems where "close enough" is wrong. It is also exposed directly as [`POST /v1/solve`](/ai-api/reference/solve).

## 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](/studio/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.