Workflow Recorder captures a real, successful task and turns it into a reusable artifact: Ambient reviews the recording, extracts the parameters, and registers a callable workflow you can invoke again like a reviewed tool.
Document screenshots, review states, edit points, confirmation, and invocation examples.
A confirmed workflow should feel like a reviewed capability, not a buried chat memory.
Recorder To Callable Workflow diagram. A five-stage pipeline runs left to right: Record a real task, then Research (search and scrape), then Judge (LLM scores), then Generalize (parameters), then Call (reusable tool). A note beneath the pipeline says the recording documents screenshots, review states, edit points, confirmation, and invocation examples, and that a confirmed workflow should feel like a reviewed capability, not a buried chat memory.
When to record a workflow#
Workflow discovery turns repeated work into inspectable candidates before they become callable artifacts. Use the recorder when a task is likely to repeat and the successful path matters: research routines, release checks, connector setup, report generation, QA passes, or internal procedures with known review steps. Do not record one-off work just to save a transcript; a transcript already does that.
A good recording becomes a reviewed playbook with parameters, policy notes, validation expectations, and a callable shape. That is what makes a confirmed workflow different from a saved prompt: it records the successful process (parameters, permissions, validation, and the output contract), not just the words that kicked it off.
Example: NYC date night research#
This example teaches the full lifecycle: record a real research task, use search and scraping, ask an LLM to judge the options, rerank based on critical reviews, generalize the workflow, confirm it, then call it later as a reusable artifact. It is deliberately a non-code task.
Start a recording and give the first prompt#
Open Workflow Recordings and click New Workflow Recording. Name it NYC date night research and review ranking, and keep the task narrow enough that a future user could rerun it with a different city, date, budget, and vibe. Then give the task prompt:
Find date night activities in New York City for this Friday. Include price, neighborhood, reservation constraints, weather sensitivity, links, and why each option could be memorable.
While the recording runs, the UI makes it clear that a workflow is being recorded, and that tool calls, user decisions, validation results, and output shape are being captured for review.
Let Ambient research, then add judging and reranking#
Allow search and public web extraction, and Ambient researches with visible providers (you can see which search and extraction paths ran). If Scrapling or web research is not ready, finish Core Setup in the quickstart before continuing rather than assuming the workflow can proceed. Then add a judging step that scores each candidate on novelty, logistics, cost, conversation quality, weather risk, and reservation friction, and requires short rationales rather than bare numbers. Finish with a critical-review step that reranks candidates when public reviews contradict a venue's own description, keeping citations and explaining any ranking changes.
Produce the final artifact#
The run ends with a concrete output: a ranked shortlist with reservation links, a backup option, travel and logistics notes, and a short avoid list.
Review with Ambient, edit, and confirm#
End the recording and click Review with Ambient. The review summarizes the successful path, identifies parameters, lists preconditions, flags any secrets or private data, and drafts the reusable workflow. For this example, the generalized parameters are city, date, budget, party size, neighborhood preference, vibe, mobility constraints, and review-weighting. The review produces a draft playbook you can edit, not an opaque memory: you edit parameters, remove sensitive data, and confirm the contract. Confirm only after validation, failure modes, and expected outputs are clear.
Call the confirmed workflow#
Start a new chat and invoke the workflow with a different city or date. The confirmed artifact is discoverable and invokable like a reviewed tool, with inputs, expected outputs, and policy notes, and it is exposed through the callable workflow registry. You get a callable artifact card and the proof that the run reused the reviewed playbook.
Generalization rules#
Five rules govern how a recording becomes a safe, reusable artifact:
- Parameterize task-specific inputs, so hidden local paths, dates, locations, accounts, and personal preferences never get replayed from the artifact.
- Redact secrets and workspace-private data before confirmation.
- Record preconditions: required providers, web access, connectors, local runtimes, and model capabilities.
- Preserve the contract: expected outputs, validation commands, failure modes, retry policy, and stop conditions.
- Register only after review: the artifact reaches the callable workflow registry only once confirmed.
High-impact steps (web extraction, connector access, filesystem changes, and workflow invocation itself) stay approval-gated and visible when a workflow runs.
What not to record#
Never preserve raw secrets, private credentials, one-off personal data, or hidden local paths in a recording. Use Ambient-managed secret flows and parameterize sensitive inputs instead. Workflows that depend on providers (Scrapling or others) record those prerequisites and their fallback expectations, and run only where the provider is installed, permitted, and appropriate; see Provider routing.
Keep going#
- Symphony: running a confirmed workflow as a child unit in a larger orchestration
- Project Board: where repeated work meets planning and review
- Provider routing: the providers a workflow's research steps route through