Model the system / 05

Playbooks and schedules

Both are runtime data. An agent definition may supply defaults or lazy factories, but instances own the chosen playbooks and scheduled triggers—and agents can create, list, update, cancel, sleep, and wake through core tools.

Playbooks are serializable directives

A playbook matches a classified inbound transmission event, serializes it into the conversation, and tells the agent what outcome is expected. Complex authentication, normalization, delivery, and predicates remain on the transmission definition.

playbook-data.tstypescript

composePlaybook({
  name: "support-release-planning",
  transmission: supportTransmission,
  match: {
    event: messageReceived,
    routes: [supportInbound],
    predicate: {
      definition: messageIncludes,
      parameters: { text: "release" },
    },
  },
  directives: [{
    action: respond,
    instruction: "Resolve the request and preserve its external thread.",
    parameters: { tone: "concise" },
  }],
  outbound: [{
    route: supportOutbound,
    application: releaseNotes,
    account: supportAccount,
    event: messageReply,
  }],
  serialization: { payload: "json", envelope: "xml" },
})

The code above composes a valid playbook from imported primitives. The resulting value can be returned lazily by a definition, saved on an instance, created by a product UI, or attached by a subscription. Playbooks do not need dedicated static files.

Subscriptions can provision agents

An inbound event does not require a pre-existing instance. A subscription can request a singleton, per-thread, per-event, fixed fan-out, or custom provisioning policy. Foundry claims the delivery, provisions each target, creates or reuses conversations, reconstructs the agents, and enqueues one run per target.

Predefined schedules are supported

agents/release-planner/schedules/readiness.tstypescript

export default defineSchedule({
  name: "release-readiness",
  description: "Review release readiness every weekday morning.",
  timing: { kind: "cron", expression: "0 9 * * 1-5", timezone: "UTC" },
  message: "Review the plan, workspace tasks, and inbox. Resolve what is actionable.",
});

// agent.ts — loaded only for instances where it applies
schedules: (_agent, { agentInstance }) =>
  agentInstance.context.disableReadiness ? [] : [releaseReadiness],

The definition supplies a composable default. Foundry materializes it as an instance-bound schedule before execution, so it can still be listed, updated, paused, or cancelled like a schedule created at runtime.

Core scheduling tools

Operation	Use
`glove_foundry_schedule`	Wake an agent once or recurringly with a specific message and payload.
`glove_foundry_schedules`	List, update, or cancel scheduled triggers owned by the current agent instance.
`glove_foundry_sleep`	Suspend the logical run until a duration or instant, then resume the same instance and conversation.
`glove_foundry_background`	Start detached work and optionally reconvene its result through the shared inbox.

Sleep is not a detached reminder

A scheduled trigger starts a future run. Sleep preserves the continuation of the current run: the agent can wait for a cooldown, an external result, or a deadline and wake with the same instance and conversation correlation. Both use the schedule adapter underneath, but expose different agent semantics.