Product | Agent Orchestration

Give your GTM team one open-ended agent that can do the work and scale the work.

Agent Orchestration is psi*'s power surface for live GTM execution. Use apps directly, take runtime actions, submit data, run research, operate governed browser sessions for social-platform work, and hand approved app or flow changes into scoped subagents. When the motion works, turn it into a flow and put it on a cron.

Power comes first. Approvals, tool controls, prompt tuning, and audit history are what make that power safe to use across the team.

Power surface

The orchestrator is where builders and GTM teams turn one-off work into system behavior.

Start with a live thread, operate the app, widen into research or browser work when needed, then push the winning pattern into flows and schedules.

Use app directly
Runtime actions

Drive published apps by label instead of stitching together separate operator tools.

Spawn subagents
Delegated build work

Hand approved app and flow changes into scoped authoring assistants instead of rebuilding by hand.

Research + browser
Open-ended task range

Gather context and operate through governed browser sessions for social-platform and web work.

Flow + cron
Scale it up

Convert repeated operator work into flows and put it on a cron when the pattern is ready.

Power surfaces

This is not one chat box. It is the operating surface plus the tuning and inspection surfaces around it.

Orchestrator is the live execution surface. Prompts, Cron Jobs, Tools, and Debug let the team tune, scale, and inspect the same system instead of handing work off to side consoles.

Orchestrator

Operate the app, research accounts, and take live GTM actions from one thread.

Use App Directly binds the thread to the published runtime so the agent can navigate pages, set component values, trigger actions, submit data, and mix that with research or governed browser work on the open web and social platforms.

  • Publication-backed runtime actions
  • Research and browser sessions in the same thread
  • Runtime state stays attached to the conversation
Prompts

Tune how the orchestrator and delegated agents behave without editing hidden prompt blobs.

Agents > Prompts lets builders shape workspace documents plus app and page guidance, preview branch or published behavior, and adjust the effective operator posture as the motion changes.

  • Workspace, app, and page guidance
  • Branch preview and published version
  • Faster tuning without rebuilding the system
Cron Jobs

Turn a working operator loop into flow-owned automation and run it at scale.

Once the motion is real, Cron Jobs can create the schedule on an existing flow, show server-authored eligibility reasons, preview the next runs, and expose runs and worker status.

  • Schedule creation with next-run preview
  • Run and worker visibility
  • Bounded automation instead of brittle cron glue
Tools

Add or remove power at the right scope instead of hard-coding one agent profile.

Tools resolves descriptor-level overrides by workspace, app, app version, flow, and current user, while Config keeps the capability-family ceilings above it so high-power tools stay intentional.

  • Descriptor overrides at the right scope
  • Family ceilings remain in Config
  • Keep risky tools narrow without weakening the surface
Debug

Inspect lineage, memory, and runtime behavior when the agent needs to get better.

Debug gives operator-safe lineage and memory inspection across runs, sessions, and apps, so teams can improve the system from real execution traces instead of guessing from transcripts alone.

  • Session memory and app memory
  • Run lineage and runtime traceability
  • Logs, audits, and debug stay in the same module shell

Common workflow

A typical motion starts live in the thread, gets delegated into the system, then becomes automation.

The orchestrator is most powerful when it is not the end state. A successful runtime conversation can be refined into a real flow the team and the agent keep improving together.

GTM operator path

Delegate build work

scoped authoring handoff
Goal: turn the winning operator loop into system behavior

request approval for delegated authoring
spawn scoped subagent for app + flow changes
update the app surface and refine the flow
keep the work attached to the same operator thread

Save the flow

reusable operator motion
Goal: capture the repeated motion as durable automation

bind canonical queries, functions, and approvals
save the flow for team + agent reuse
keep the runtime behavior visible and replayable

Put it on a cron

bounded automation
Open Agents > Cron Jobs

validate the schedule on the server
preview the next runs
start bounded automation at scale

Power that stays governed

Keep the orchestrator open-ended without letting it drift

psi* gives teams broad agent power, but the same module also owns prompt tuning, tool ceilings, browser approvals, and traceability so the surface can scale without becoming a black box.

Control surfaces

Power and control stay in the same system

use the app, tune behavior, restrict tools, and inspect memory without moving work into ad hoc side tooling

SurfacePowerControl
Orchestratorruntime + research + browserthread history + approvals
Toolsdescriptor overridesscope ceilings
Configprovider readinesspolicy + verification

The product stays powerful because controls attach to the same execution record instead of sitting in a disconnected security layer.

GTM operator controls
Runtime actionspages, forms, actions, published data
Delegationjobs, child sessions, scoped authoring handoff
Prompt tuningworkspace, app, page, branch, published
Tool controlworkspace, app, version, flow, user
Browser postureapproval-gated bootstrap and mutations
Debug + memorylineage, session memory, app memory
Execution record

                      ┌───────────────────────────────┐
│ Thread Surface                │
│ orchestrator / prompts        │
│ context / runtime mode        │
└───────────────────────────────┘
               ↓
┌───────────────────────────────┐
│ Power Layer                   │
│ runtime / research / browser  │
│ live GTM actions              │
└───────────────────────────────┘
               ↓
┌───────────────────────────────┐
│ Delegation Layer              │
│ subagents / flows / cron jobs │
│ reusable system behavior      │
└───────────────────────────────┘
               ↓
┌───────────────────────────────┐
│ Proof Layer                   │
│ approvals / memory / replay   │
│ audit / traceability          │
└───────────────────────────────┘
                    

When the same system owns execution, delegation, and inspection, teams can push the orchestrator hard without losing the ability to explain what happened.

  • Risky browser and mutation-like steps can be approval-gated
  • Tool exposure narrows by capability family and scope
  • Memory, lineage, and replay keep behavior reconstructable
  • Direct runtime is publication-backed and label-first for ordinary app use
  • Prompts manages workspace documents plus app and page guidance on the active branch
  • Cron Jobs adds schedules with server-authored eligibility reasons and next-run preview
  • Tools resolves overrides below the Config ceiling instead of creating a second capability model

Enterprise

Give the GTM team a powerful operator surface without flattening the control boundary.

Browser sessions, approvals, policy ceilings, and audit history sit with psi* so teams can move fast without turning the environment into a generic unmanaged agent runtime.

Open-ended operator power

The GTM team can operate apps, research accounts, and drive browser work from one system.

Scoped control model

Prompts, tools, approvals, and provider posture narrow the surface before risky actions run.

Replayable operations

Thread history, memory, approvals, and run refs stay legible when the system needs inspection.

Power + control boundary

Customer systems

  • CRM, email, social, and source systems the GTM team already uses
  • Live browser work and account research that still touches the outside world
  • Published apps and outbound actions the team needs to operate day to day

Inside psi*

  • orchestrator, flows, prompts, tools, and config
  • approvals, memory, audit history, and replay
  • policy ceilings and provider posture before risky work runs

Related surfaces

Agent Orchestration compounds with the products it can delegate into and schedule.

Use these surfaces together when the goal is not just a good agent demo, but a better GTM operating system.

Product

Agentic App Builder

Hand approved app and flow changes into scoped authoring assistants, then publish the surface the team will use.

Open product

Product

Flows

Capture repeated operator motions as durable flows, then run them with checkpoints, retries, and schedules.

Open product

Product

Ontology

Keep customer, revenue, and company context stable as the agent, the team, and the flows act on the same system.

Open product

Platform

All products

See how orchestration, app surfaces, flows, and ontology compound when they run together.

Open platform

Get started

Start with Agent Orchestration when your GTM team needs an agent that can do live work now and become automation later.