Product | Flows

Build and scale GTM operations automatically.

Flows is an agent-first execution system for GTM work. Chain complex queries, function calls, structured LLM outputs, deterministic writes, and review-gated actions across any number of steps in one durable run.

Trigger work from schedules, webhooks, app events, or manual launches, then let the system pause, retry, resume, and recover instead of silently breaking inside Zapier, cron jobs, spreadsheets, and RevOps glue.

Flows runs on the same runtime and query primitives as the apps, so it can manipulate app state and operator surfaces directly instead of handing work off to a separate automation stack.

Core features

One execution system for triggers, runs, reviews, and recovery.

Flows keeps GTM execution in one runtime so launches, stored run state, app actions, approvals, and recovery paths all stay legible.

Trigger modes
Start from schedules, webhooks, app events, or bounded manual launches.

Autonomous entry points stay explicit.

Durable runs
Manual, scheduled, retried, and resumed work share one run history.

One stored execution record.

Review checkpoints
Pause only where routing, contact, or send judgment actually matters.

Approval stays inside the run.

Agent-first execution
Chain queries, functions, structured outputs, and deterministic writes in one flow.

AI steps stay bounded and explicit.

Canonical bindings
Execute the same queries and functions the apps already use.

No sidecar automation layer.

App-native actions
Read and write app state directly instead of handing work off elsewhere.

One shared runtime contract.

Recovery controls
Retry, resume, replay, and recover from stored state.

Fix the run without rebuilding it.

Campaign research flow

One real flow, shown in the four steps it actually runs.

This example comes directly from the `campaign-research` flow in the Campaign Manager app. The system loads the active campaign, claims the run, performs grounded research, and persists the result back into workspace state.

Campaign research flow

Step 2

Claim campaign research
id: query-claim-campaign-research
kind: query
title: Claim Campaign Research
queryRef: query:claim-campaign-research
resultAlias: research_claim

Step 3

Research campaign
id: step-campaign-research
kind: instruction
title: Research Campaign
planningMode: template_only
requiredToolNames:
  - perplexity_research
You must call `perplexity_research` exactly once before returning.
resultAlias: campaign_research_payload

Step 4

Apply campaign research
id: query-apply-campaign-research
kind: query
title: Apply Campaign Research
queryRef: query:apply-campaign-research
parameterBindings:
  payload:
    source: block_result
    blockId: step-campaign-research

Control plane

Any flow can run on a cron, automate work through agents, and pause only when judgment matters.

Put any repeatable GTM task on a schedule, trigger it from the app, or hand it to workers and agents so the system keeps moving without losing control of the path.

Cron or event start

Run any flow on a cron, webhook, or app event so recurring GTM work starts automatically instead of waiting on ops glue.

Worker and agent execution

Let workers and agents automate the tasks inside the flow while reading and writing the same runtime state your apps already use.

Review and recovery

Pause for routing, contact, or send approval, then retry, resume, or replay from stored state when the run needs correction.

Operational trust

Tune the flow without losing the audit trail

Teams can adjust prompts, model posture, schedules, and recovery paths while psi* keeps approvals, run history, and debug context attached to the same durable execution record.

Operator surfaces

Control and proof stay together

prompts, cron jobs, and config all feed the same governed runtime instead of creating a second ops layer

SurfaceControlAudit
Promptsedit + previewcompiled snapshots
Cron Jobsschedule + workersnext-run proof
Configreadiness posturedebug surfaces

Tune provider/model posture, schedule flow work, and inspect failures without losing canonical approval or replay history.

Runtime controls
Prompt controlsedit, preview, publication-frozen version
Model postureshared defaults and allowed-model overrides
Cron operationsserver-authored eligibility and next-run preview
Run controlscancel, retry, replay
Approval postureinline when the approval path is unambiguous
Debug surfacesruns, workers, readiness, prompt preview
Runtime record

                      ┌───────────────────────────┐
│ CONTROL                   │
│ prompts | cron | config   │
│ edit | schedule | inspect │
└─────────────┬─────────────┘
              │
┌─────────────▼─────────────┐
│ POLICY                    │
│ approvals | tool_rules    │
│ model_allow | write_acl   │
└─────────────┬─────────────┘
              │
┌─────────────▼─────────────┐
│ RUNTIME                   │
│ plans | tools | writes    │
│ retries | replay | state  │
└─────────────┬─────────────┘
              │
┌─────────────▼─────────────┐
│ EVIDENCE                  │
│ snapshots | run_log       │
│ debug | readiness | audit │
└───────────────────────────┘
                    

Prompt edits, trigger state, approval refs, and recovery history all remain reconstructable inside one runtime record instead of leaking across side tools.

  • Schedules are server-validated before activation
  • Approval gates stay attached to the exact blocked step
  • Pause, retry, and replay stay attached to the same run record
  • Agents > Prompts exposes edit, preview, and published prompt versions
  • Agents > Cron Jobs exposes runs, workers, eligibility reasons, and next-run previews
  • Agents > Config exposes provider readiness and browser/research observability
  • Compiled prompt snapshots persist beside the run record

Example motion

A single flow can take revenue work from first signal to approved downstream action.

Move from first signal to reviewed downstream action without handing work off to brittle side systems.

01

Open on a webhook, app event, or schedule, then load the canonical company and campaign context through the same query/runtime substrate the apps use.

02

Run enrichment, scoring, and structured decision steps, then write the deterministic output back into app and workspace state.

03

Pause for routing, contact, or send approval only where required, then resume the run without losing lineage when the system needs correction.

Get started

Start with Flows when brittle GTM execution is the thing holding revenue back.