Workflow Agent overview

Workflow Agent is a preview surface for turning a natural-language automation idea into an inspectable workflow draft. Use it when you want to identify apps, review ordered steps, see which execution routes might be possible, and test the proposal without contacting external systems. The current product stops before live activation: drafts, simulations, dry runs, route-readiness results, and approval-packet previews are available, while verified production execution is not.

What Workflow Agent does

A workflow begins as a description of an outcome, such as moving information from one business app to another after a specific event. Workflow Agent interprets that description, identifies relevant apps, and produces a deterministic definition that can be reviewed rather than executed blindly. The definition can include ordered steps, expected inputs, candidate routes, missing credentials, and approval requirements.

The important unit is a workflow draft. A draft records what Ethen believes the workflow should do and how each step might be reached. It is not an activated automation. A discovered app relationship can support drafting even when no configured connector exists. Likewise, a route can be suggested while remaining blocked for simulation or execution.

Workflow Agent belongs to the workflow product surface. It does not replace the broader agent runtime, and it is not the same as an agent run. The product focuses on discovery, composition, readiness analysis, and preview records. Model selection and model research remain separate concerns handled by other Ethen surfaces.

Current capabilities

The inspected implementation supports a preview sequence with clear checkpoints:

The app directory is data-driven. It prefers the production Zapier-derived source and can fall back to a smaller fixture source. Available apps, pairings, and suggestions therefore depend on what was loaded for the current environment. Counts shown by a seed or fallback should be treated as illustrative rather than as permanent catalog totals.

Generated connectors and bridge options may also appear before they are executable. The UI contract exposes states such as configured, needs-setup, expired, config-preview, dry-run, live-blocked, and disabled. Those labels describe different operational conditions and should not be collapsed into a single “supported” state.

Draft and simulation boundaries

Drafting answers, “What would this workflow look like?” Simulation answers, “What would happen if the draft were evaluated with the current inputs and readiness information?” Neither action authorizes an external write.

A simulation can validate the shape of the workflow, expose a missing connection, show an approval requirement, or produce a route-specific dry-run result. It does not prove that a provider is configured, that credentials are accepted, or that a remote action will succeed. Even when the builder reports that draft, simulation, approval, and route checks are satisfied, activation remains locked in the current milestone.

Use the canonical state distinctions when reading a result:

• canDraft means Ethen can construct a workflow definition.
• canSimulate means the current definition can produce a preview result.
• canExecute would indicate an executable path, but generated connector review cards currently keep this false.
• live-blocked means the interface deliberately prevents execution.
• disabled means the capability is present as a concept or surface but cannot be used.

No external app contact, live webhook ingress, MCP tool call, scheduled execution, or production run history should be inferred from a successful draft or simulation.

Core surfaces

The Workflow Agent home page provides the entry point for new descriptions and links to the main preview surfaces. Recent cards can display Draft, Simulation, or Needs credentials, but seeded entries are examples rather than durable history.

The builder shows the generated steps, route readiness, read-only JSON, workflow-definition preview, simulation controls, and activation gates. The apps directory supports discovery and readiness inspection. The integrations surface groups credentials, bridge providers, generated connectors, native connectors, MCP servers, and webhook or API-route concepts. A visible tab is not evidence that the underlying integration can execute.

Templates offer pre-shaped starting points derived from app-pair data, sample prompts, and capability information. The approvals page renders simulation-derived approval packets with disabled decisions. The runs page shows local-safe or fixture-backed preview records, including summaries, errors, and evidence. There is no verified dedicated schedule page.

Where to begin

Start with Create your first workflow when you have a concrete automation idea. Describe the outcome and the participating apps in plain language, then inspect what Workflow Agent detected. The procedure intentionally ends with a simulation.

Use Workflow builder when you need to understand individual steps, inputs, route readiness, or approval gates. Open Apps and integrations before relying on a particular app pair, because discovery and execution readiness are separate. If the draft reports missing credentials, continue to Connections and credentials rather than assuming that selecting an app created a connection.

Templates are useful when your goal resembles an existing preview pattern. Webhooks, MCP, schedules, approvals, and run history each have additional restrictions and should be read as bounded product guides. When a route or control is marked setup-required, preview-only, live-blocked, or disabled, keep the workflow in draft form and treat the stated limitation as the current product outcome.

Reading a readiness result

A readiness result is most useful when read from the workflow step outward. Begin with the action the step proposes, then identify the route status, execution-route candidate, connection state, approval requirement, and simulation outcome. The combination is more informative than any single badge. For example, a bridge can be known to the directory while its credential remains absent; the draft can still be valid, but the route is not ready. A native route can also remain unusable when policy or activation blocks it.

The loader’s fallback behavior matters during this review. When the production app-pair source is unavailable, suggestions can come from the fixture. The page should make that source visible so an operator does not interpret a small fixture result as the platform’s full capability. The same principle applies to recent cards, example accounts, and seeded connection rows.

Product boundary example

Suppose the description asks for a new record in one app to create a task in another. Workflow Agent may detect both apps, draft a trigger and destination step, and identify a bridge route. A simulation can then report that the bridge configuration is missing. The supported result is a reviewed workflow draft with a named setup requirement. No task was created, no provider accepted a request, and no production history exists. That example captures the product’s current value without promoting preview behavior to execution.

Preview outcomes by role

Operators use Workflow Agent to clarify process intent and surface missing setup before implementation work begins. Administrators use the same draft to identify credentials, provider configuration, and governance requirements. Reviewers can inspect simulation evidence and approval-packet previews without authorizing a live action. These roles share one definition but make different decisions from it.

A good overview therefore avoids promising that one person can complete the whole lifecycle. The present surface supports collaborative review of the proposed workflow while execution remains outside the verified boundary.