Agent Dispatch is Live: One Script, Hundreds of Subagents, All Governed

A code-capable agent reads your records, decides what work each one needs, and places hundreds of trigger-bound subagents in a single script run. Some fire now. Some fire when conditions are met. All governed, all observable, all on the same per-minute rate. Here is what we shipped, the use cases we are exploring with early users, and what you already get.

What we shipped

Last week we turned on Agent Dispatch for every org on the platform. The capability is the combination of three primitives that have been quietly accumulating in the API: standing orders, trigger-bound subagents, and sweep-and-dispatch. Together they let one agent place a fleet.

The setup: a code-capable agent (Claude Code, Codex, or any agent with the Personize SDK in its tool belt) queries your data. It reasons about which records need work. It writes a script that loops over the records and creates the right kind of subagent for each one: a one-shot fire-now for the urgent ones, a trigger-bound subagent for the ones waiting on a condition, a standing order for the ones that need recurring attention. The script runs once. The platform takes it from there.

The result is that a single dispatch call commits the org to dozens, hundreds, or thousands of governed, observable, audit-trailed agentic outcomes, spread across the next hour, day, or quarter. Every fire goes through the same prompt pipeline as a direct API call: governed-memory recall, MCPs, outputs that bind to record properties, auto-memorize, BYOK vault, evaluation, destination dispatch on completion. No glue code. No queue infrastructure. No central workflow engine.

This article walks through what Agent Dispatch is, the use cases we are exploring with early users, the emergent capabilities the pattern unlocks, what we already support today, and what we are still figuring out.

What we mean by "agent"

Before going further, the word matters. The autonomous-agent wave of the last year (Claude Code, Codex, and a growing family of "give the model tools and a goal" products) has shown what fully agentic systems can do. They are remarkable. One human prompt, an agent that decides which files to read, which tests to run, which APIs to call, and how to assemble the answer. For open-ended coding and knowledge work, they are the right shape.

A Personize agent is not that.

A Personize agent is a top-down, structured execution of an instruction chain. It receives a predefined sequence of instructions, has access to deep native memory and your MCP tools, runs with an output schema the caller defined, and returns. There is no open-ended autonomy. There is no "decide what to do next." The agent runs the chain it was dispatched to run, emits the outputs the platform validates, and stops.

This is a deliberate constraint, and the rest of the system depends on it. Three things autonomous agents trade away that production batch work cannot give up:

Predictable cost. An autonomous agent decides how many tool calls it needs per run. A structured agent runs the instruction chain it was given, with the model tier the caller picked, returning in a known token envelope. The bill for running ten thousand structured agents is forecastable. The bill for running ten thousand autonomous agents is not.

Predictable quality. A structured agent against a tuned instruction chain produces output a downstream system can rely on. An autonomous agent against an open goal produces output the downstream system has to second-guess every time.

Predictable accuracy. When the instruction chain has been tuned on fifty records (the tune-on-fifty pattern), the accuracy on the next fifty thousand is a known quantity. Autonomous accuracy varies per run, because the agent itself varies the work per run.

We gave up autonomy on purpose to buy back predictability. The customer who wants an autonomous agent for an open-ended task picks Claude Code or Codex, which are excellent at that job. The customer who wants ten thousand records processed correctly, cheaply, and consistently by tomorrow picks structured subagents on a dispatch loop.

The way we made this concrete is not complicated. We added scheduling on top of the prompt pipeline, then let users (and dispatcher agents) place structured instruction chains at scale, each with predefined outputs the platform validates. That is the entire mechanic. The interesting part is what happens downstream of that mechanic, which is the rest of the article.

The three primitives, named

The pattern only works because each piece carries its own weight. Naming them separately makes the architecture legible.

Standing orders are scheduled prompts on cadence. "Every weekday at 9 a.m., draft a follow-up email for Jane based on her latest activity." You set it once and it fires forever until you cancel it. Budget pre-authorized at create time. Governed by org policy. Audit-trailed per fire. The mental model is the same as a standing order with your bank: a recurring contract, executed without re-authorization.

Trigger-bound subagents are scheduled prompts on condition. "When this lead reaches stage = qualified, dispatch a research subagent on the account. When that subagent completes, dispatch a strategy subagent. When the strategy is ready, notify the rep." The subagent is created in advance with a trigger predicate; it lies dormant until the condition fires. The mental model is a limit order with your broker: pre-placed, conditional, no human action needed at the moment of execution.

Sweep-and-dispatch is the meta-pattern. A code-capable agent walks a database (your CRM filter, a SQL query, the Personize filter mode, a workflow queue), decides which records need what kind of work, and writes a script that creates the subagents in bulk. Some are standing orders. Some are trigger-bound. Some are one-shot fires that run immediately. The dispatcher is the orchestrator; the subagents are the workers.

Here is what a small dispatch looks like in code:

import { Personize } from '@personize/sdk';
const client = new Personize({ secretKey: process.env.PERSONIZE_SECRET_KEY! });
 
// 1. Sweep: read the records that need attention
const leads = await client.retrieve({
  mode: 'filter',
  filters: {
    groups: [{
      logic: 'AND',
      conditions: [
        { property: 'segment', operator: 'EQ', value: 'enterprise' },
        { property: 'last_activity_at', operator: 'GT', value: '2026-05-04' },
        { property: 'qualification_status', operator: 'IS_NULL' }
      ]
    }]
  }
});
 
// 2. Dispatch: place a trigger-bound subagent on each
for (const lead of leads.records) {
  await client.schedules.create({
    name: `qualify-${lead.record_id}`,
    taskType: 'run_prompt',
    taskPayload: {
      instructions: [
        'Pull the latest signals on this lead from memory and from web search.',
        'Score qualification on fit, intent, and budget. If you cannot verify one of them, emit <abort reason="insufficient_signal"/>.',
        'Compose a short qualification summary and emit the output markers.'
      ],
      memorize: { recordId: lead.record_id, type: 'Contact' },
      governedMemory: true,
      webSearch: true,
      outputs: [
        { name: 'qualification_score', collectionId: 'col_leads', propertyId: 'prop_score', required: true },
        { name: 'qualification_notes' }
      ],
      evaluate: { criteria: 'sales', serverSide: true }
    },
    recurring: false,
    runAt: new Date(Date.now() + 1000 * 60 * Math.random() * 60).toISOString()
  });
}

What just happened in that script: we filtered our CRM for all enterprise leads with recent activity and no qualification yet. We placed a one-shot subagent on each one, jittered across the next hour to avoid a thundering herd. Each subagent will run a three-instruction chain with web search, write its score directly into the lead's prop_score property, and self-evaluate. The dispatcher is done in milliseconds. The fleet runs for the next hour. The results land in your CRM.

That is the headline pattern. Everything below is what you can do with it.

Use cases we are exploring with early users

These are real scenarios from the past two weeks of conversations. None are fully solved. We are sharing them because the pattern is general and customers keep finding angles we did not anticipate.

1. The Monday-morning fleet. A sales VP wants every account owner to walk into their seat on Monday morning with a fresh brief on their top ten accounts. A weekly standing-order dispatcher fires at 4 a.m. Sunday: it filters for accounts with status = active, sorts by ARR, takes the top ten per owner, dispatches a brief-generation subagent for each. By 8 a.m. Monday, every owner's CRM has ten fresh property-bound briefs waiting.

2. The new-lead cascade. A RevOps lead wants every new inbound lead to trigger a small cascade: research subagent, qualification subagent, account-strategy subagent, persona-specific draft subagent. The dispatcher fires when the lead lands. Four trigger-bound subagents get placed in advance, each with a predicate watching for the previous one's completion. The cascade unfolds without anyone touching it. The notification subagent at the end queues the salesperson a Slack DM with the strategy and the draft.

3. The backlog catch-up. A CS leader has six months of customer call transcripts that were never extracted into memory. A dispatcher script reads the transcripts table, batches them by account, places bulk-mode (executionMode: 'bulk') memorize subagents on the batch path for overnight processing at 65% off. By Monday the memory is current, and the daily standing-order briefs that depend on it start producing useful output.

4. The churn-watch fleet. A CS director places a recurring standing-order dispatcher: every Tuesday at 7 a.m. it queries for accounts whose usage dropped more than 30% week-over-week. For each match, it dispatches a one-shot risk-assessment subagent that pulls the recent memory, looks for cause signals, and writes a structured risk_assessment property. If the assessment flags red, a trigger-bound notification subagent fires the next morning, looped through the CS manager's queue.

5. The competitive monitor. A marketing leader wants the team to know whenever a customer mentions a specific competitor in a transcript. A standing-order dispatcher fires hourly: it scans new atomic memories for mentions of competitor names from a watchlist. Each hit dispatches an analysis subagent that summarizes the mention, scores the threat, and writes a memory + property update. The MRR-at-risk dashboard updates itself.

6. The reverse: the dispatch-the-dispatcher pattern. Two early users have started doing something we did not plan for: their dispatcher's job is to read yesterday's dispatched-fleet results, decide what worked, and dispatch tomorrow's fleet differently. The dispatcher becomes a learning loop. We are still figuring out whether this needs first-class platform support or if the existing primitives are enough.

There are at least a dozen more we have heard pitched in early calls. If you have a use case you want a thinking partner on, the team is actively in the room.

What this unlocks

The pattern is genuinely new in a way that is worth naming. Three things stop being constraints.

The unit of agentic work is no longer a single prompt. Production AI work has been one-prompt-at-a-time for two years. With Agent Dispatch, the unit is a fleet. A dispatcher's decision becomes a hundred subagent outcomes. The cost-per-decision falls; the leverage rises.

The orchestrator is no longer central. There is no flowchart somewhere that has to be kept in sync with the agents. Each subagent is autonomously defined with its own trigger predicate. The shape of the workflow emerges from the predicates, not from a declarative DAG. Adding a new step is creating a new subagent. Anthropic's Opus 4.8 Dynamic Workflows announcement named the same insight from the dev-tools side: "Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive." Agent Dispatch is that pattern for governed business records.

The dispatcher is itself an agent. The customer asks the dispatcher in plain language. The dispatcher figures out the database query, the filter conditions, the right kind of subagent per record, the right schedule shape. Code-capable agents (Claude Code, Codex, or anything with the Personize SDK in its tool belt) get a second job beyond writing code: they get to orchestrate fleets of business agents against your data.

The dividend: emergent collective intelligence

The reason the constraint is worth it shows up at the system level, not the agent level.

When ten thousand structured subagents produce typed, validated, schema-conforming outputs, downstream systems and other agents can act on those outputs programmatically. The reply-classification subagent's output is the input to the strategy subagent. The strategy subagent's output is the input to the draft subagent. The draft is a typed property the analytics layer aggregates. Each subagent does one structured job. The system as a whole exhibits behavior nobody specified.

Three shapes of emergence we are watching for in the next eight weeks of early customer use:

Cross-agent correlation. A churn-watch fleet placing typed risk_assessment properties starts revealing correlations between specific support-ticket categories and renewal-stage stalls, not because any single subagent was looking for them, but because the typed outputs line up across the cohort and a downstream aggregator catches the pattern.

Accidental collaboration via schema. A research fleet outputs competitive_mention properties; a competitive-intelligence dashboard built independently by another team consumes the same property name. The dashboard works because the schemas matched. The two teams did not know each other existed. Schemas are the API by which agents accidentally collaborate.

Closing-the-loop refinements. A reply-handler fleet's intent outputs feed a playbook-revision subagent that detects a category of objection no playbook section covers, and dispatches a content-team notification. The playbook acquires a new section. The next week's replies handle the objection better. No human told the system to learn this; the structured-output substrate enabled it.

This is the emergent property. Predictable outputs are composable. Composable outputs are programmable. Programmable agentic systems exhibit collective intelligence the original designers did not plan for, because the predictability of each piece lets the pieces wire themselves together.

Most autonomous-agent systems do not show this property because their outputs are too unstructured for other agents to consume programmatically. The downstream layer cannot trust the output enough to build on it. Structured outputs are the substrate on which collective intelligence runs.

The use cases in the section above are the ones we anticipated. The interesting cases will be the ones we did not. Those are the early signals we are watching for.

What we already support today

Production-readiness is a checklist, not a vibe. Here is what works today, with no caveats.

Dispatch creation surfaces.

• REST: POST /api/v1/schedules with full /api/v1/prompt parity in the taskPayload.
• SDK: client.schedules.create({...}) mirrors the REST body 1-to-1.
• MCP: schedule_create tool under the admin profile, callable from Claude Desktop, Cursor, Windsurf, ChatGPT.
• Executor tool: schedule_task with a friendlier flat-arg surface for in-agent dispatching.

Subagent capabilities.

• Single-prompt or multi-step instruction chains.
• Governed memory recall (SmartContext + SmartRecall, both default on).
• MCPs (all org MCPs or specific integrations).
• Web search (provider-native or Tavily).
• BYOK key resolution from the org vault (inline keys rejected for security).
• Tier selection (basic, pro, ultra).
• Property-bound outputs that write extraction results directly to record properties.
• Auto-memorize with optional tool-result capture.
• Server-side evaluation with preset or custom criteria.
• <abort reason="..."/> markers for the subagent to refuse work mid-chain.

Schedule shapes.

• One-time fires (runAt).
• Recurring on cron (cron(0 9 ? * MON-FRI *)) or rate (rate(1 day)) or shorthand (1D, 2H, 30M).
• Per-fire timezone control.
• Concurrency policies (allow for parallel fires, skip to drop if the previous fire is still running).
• Automatic 0-60s jitter on rate(...) schedules to prevent thundering herd.
• enabled: false to create paused, PATCH { enabled: true } to resume.
• endDate to stop on a specific date.

Guardrails.

• Per-org schedule cap (Free 5 / Starter 50 / Pro 500 / Enterprise 5000).
• Per-record schedule cap (Free 2 / Starter 5 / Pro 10 / Enterprise 50).
• Credit pre-authorization on recurring schedules (rejects creation if the projected 7-day spend exceeds balance).
• Auto-pause after three consecutive failures.
• Soft-delete with 90-day execution-history retention.
• Audit-trailed executions log per schedule, filterable by record, email, or website.

Result delivery.

• Property-bound outputs land directly on records, no destination wiring required.
• Webhook destinations subscribe to prompt.completed events.
• S3 destinations for archival.
• GET /api/v1/schedules/:id/executions for status polling.

Observability.

• Per-execution status (running / success / failed / timeout / skipped).
• Per-execution duration, credit burn, destinations dispatched.
• Schedule health surfacing (active, paused, error).
• Filterable execution history per record / email / website.

If you want the full schema, the canonical doc is the scheduling-prompts reference (open in your browser). The piece on the per-minute economics of instruction chains covers the cost model that flows through every dispatched subagent.

What we are still exploring

The capability is live, but the right shape for some pieces is genuinely still open. We are publishing this list because the feedback in the next eight weeks will decide which of these graduate to first-class features.

Dispatch idempotency. A dispatcher that runs every Monday will try to re-dispatch records it already dispatched last week. The cursor-on-query pattern (only dispatch records whose last_dispatched_at < today) works but is the customer's job today. We are looking at whether a dispatchKey field on the schedule would let the platform reject duplicates server-side.

Cascade observability. When a dispatch creates a cascade of trigger-bound subagents, today you see them as N separate schedules in the executions log. We are testing a dispatchRunId correlation ID that propagates through the whole fan-out tree so the fleet shows up as one unit.

Conditional firing without a separate subagent. Customers want to express "fire this subagent only if the record's last_activity_at changed since the last fire" without standing up a precondition subagent in front. A native fireIf predicate on the schedule is on the roadmap; the question is what predicate language is rich enough to be useful but bounded enough to be safe.

Dispatcher templates. The same dispatcher logic recurs across customers (Monday-morning briefs, new-lead cascades, churn watch). We are debating whether to ship a small library of dispatcher templates as personize-skill modules or to leave this to the open community.

Workspace-driven dispatch. When N agents share a workspace on the same record, the workspace updates can themselves be triggers. We have a prototype where a workspace mutation triggers a re-evaluation subagent. We are still validating whether this is a third dispatch mechanism or a special case of trigger-bound subagents.

Cost forecasting. The pre-auth estimate works (firesPerDay × 7 × 5 credits/fire), but customers running large fleets want a forward forecast across all their dispatched subagents combined, with alerts when the projected burn exceeds a threshold. The shape of this dashboard is open.

If any of these are blockers for you, tell us. The order we ship them will be the order customers raise them.

How to start

Three on-ramps depending on where you are starting from.

You already use the schedules API. You have Agent Dispatch already. Replace the single client.schedules.create(...) call with a loop over a client.retrieve({ mode: 'filter', ... }) result. The dispatcher pattern is the loop; the subagent is each body inside the loop.

You use Personize but have not touched schedules. Run npm install @personize/sdk (or update if you are on an older version), set PERSONIZE_SECRET_KEY, and use the snippet near the top of this article. The scheduling-prompts doc has six worked examples to copy from.

You are evaluating. Get on a call with the team. We are actively shaping the next eight weeks of the product around what early dispatch users tell us, and the customers who are loudest right now are the ones whose use cases will define which piece gets shipped first.

The capability is live, the docs are current, and the team is in the room. Tell us what you want to dispatch.

Companion pieces: Instructions, Not Prompts on the per-minute economics that flow through every dispatched subagent. 65% Off Memorization on the bulk path that dispatched memorize subagents can opt into. Retrieval Is a Conversation, One Call, Four Sources, and Think and Execute For Me on the retrieval surface that every dispatched subagent reads from.