Build Workflow Deliverables with the Stated API

Use Stated APIs from n8n, agent frameworks, backend jobs and enterprise automations to turn workflow output into persistent Documents, Pages or Experiences that people can actually receive and use.

2026-09-15 · 5 min read

Use Stated as the delivery layer at the end of an automation. Your workflow can collect data, call models and make decisions in its existing stack, then create or update a Stated artifact as the human-facing deliverable.

The basic architecture

Stated does not need to replace your orchestrator. n8n, LangChain, CrewAI, your own backend, scheduled jobs and enterprise automation systems can remain responsible for execution. Stated handles the persistent artifact that leaves the workflow and reaches a person.

Choose the deliverable format

Stated has three formats:

• Document — continuous editable content for proposals, contracts, notes and long-form deliverables.
• Page — structured, publishable and interactive content for reports, research, summaries and decision interfaces.
• Experience — fullscreen interactive web content for sites, presentations, dashboards and application-like experiences.

Select the format from the audience and use case. Do not couple the artifact format to the model or orchestration framework that happened to create it.

Create a deliverable

The high-level Stated creation interface accepts a description of what to create and an explicit format when your workflow already knows the required output.

For retried or externally orchestrated workflows, use a stable external_id or idempotency_key where supported. Repeating the same creation operation with the same key can return the existing content instead of producing a duplicate.

A conceptual request is:

{
  "format": "page",
  "title": "Weekly Competitor Intelligence",
  "prompt": "Create a decision-ready report from the validated findings supplied by this workflow.",
  "external_id": "acme:competitor-intelligence"
}

Treat the returned publication id or canonical Stated URL as workflow state. Store it in the system that owns the automation.

Update recurring deliverables

A recurring workflow normally has many executions but may have only one human-facing artifact.

For example:

Use the stored publication id, slug or URL with the relevant Stated update operation. This keeps one stable destination for the audience instead of generating a new link on every run.

Create a new artifact only when the business use case requires a distinct deliverable, such as a separately archived monthly report.

Build a workflow deliverable, not an execution dump

The payload published to humans should be different from the internal execution state.

Publish conclusions, evidence, sources, tables, recommendations and next actions. Do not publish credentials, hidden prompts, chain-of-thought, internal traces, raw orchestration state or debugging output.

A useful final AI instruction is:

Prepare the validated workflow result for [AUDIENCE]. Structure it around [DECISION]. Preserve source provenance and material uncertainty. Remove execution details. Create or update the Stated artifact and return its canonical URL as the workflow deliverable.

Add interactive actions

A Page can be extended with blocks when the workflow needs a human response. Available patterns include polls, forms, ratings, question boxes, file requests, downloads, tables, charts and other interactive components.

For example:

Choose the smallest interaction that represents the business decision. Do not infer approval from a page view.

Read results back into the workflow

Stated analytics expose views and interactions for a publication, including response data for supported interactive blocks.

An automation can use the publication identifier to inspect the relevant result and then decide whether to continue, branch, notify a person or wait for another explicit signal.

Your application remains responsible for authorization and for mapping a human response to consequential downstream actions.

Deliver the artifact

After creation or update, the canonical Stated URL can be passed to the next delivery step in your workflow.

Depending on the workflow, that may mean emailing the publication to contacts, distributing an eligible publication through supported social channels, returning the URL to your application, or passing it to another internal system.

For workflows that require a static copy, a Stated Page can also be rendered as a professional PDF. The live artifact can remain the canonical interactive version while the PDF acts as a snapshot.

Example: n8n client report

A scheduled n8n workflow collects client metrics, calls an AI step to identify material changes and produces validated findings.

The delivery stage creates or updates a Stated Page using a stable client/workflow identifier. The Page contains the executive summary, real metrics, recommendations and a structured feedback question. n8n then sends the returned Stated URL to the client.

On the next run, the workflow updates the same artifact.

Example: agent-generated approval packet

A LangChain or CrewAI workflow completes research and proposes an action that requires human review.

The workflow publishes the evidence and recommendation to Stated instead of executing the action immediately. The reviewer submits the required response through the artifact. The surrounding application reads that explicit result and applies its own approval policy before continuing.

Example: enterprise recurring intelligence

An enterprise backend combines internal data with permitted external research and produces a recurring intelligence briefing.

The backend can change models or research providers without changing the human-facing artifact. It targets the same Stated publication identity on each run.

This is the AI-agnostic artifact pattern: the execution stack can evolve while the deliverable remains stable.

Production checklist

Use stable identifiers for retried creation. Store the returned publication identity. Update recurring artifacts instead of duplicating them. Keep secrets and execution traces out of publications. Preserve evidence and source provenance. Apply visibility appropriate to the audience. Use explicit human responses for approvals. Keep authorization and consequential action policies in the systems that own the workflow.

Related documentation

See Agentic Publishing with Stated for the overall agent architecture, Persistent AI Artifacts and Idempotent Workflows for retry-safe design, and Human-in-the-Loop Agent Workflows for response-driven automation patterns.