Skip to main content

Interface: ProcessOptions

Defined in: core/dist/types/types.d.ts:739

Properties​

activeTools?​

optional activeTools?: readonly string[]

Defined in: core/dist/types/types.d.ts:978

Override AI SDK activeTools for this call only (restrict callable tools). Thin passthrough.

additionalTools?​

optional additionalTools?: Record<string, ToolDefinition<(...args) => unknown> | ZodToolDefinition<any, any> | Processable<unknown, unknown>>

Defined in: core/dist/types/types.d.ts:974

Extra tools for this call only, added on top of the ones the processable was built with. Composites forward options to their children, so tools added here reach every LLM turn the call performs.

This is how a caller lends a processable a capability without rebuilding it: an orchestrator can hand a worker collaboration tools while the agent keeps its own model, system prompt and tools.

A name already configured on the processable wins — an added tool must not silently replace one the agent was built with. Use activeTools to restrict the merged set.

approvalResponses?​

optional approvalResponses?: ApprovalResponse[]

Defined in: core/dist/types/types.d.ts:910

Resume a paused tool-approval turn (resumable approvals).

When a gated tool (requiresApproval) is reached without an in-process onApprovalRequired handler, the loop pauses and emits a tool_approval_request event carrying an approvalId. Collect the user's decision out-of-band, then call process() again with the same input plus these responses — each is threaded straight into AI SDK's native approval-response message so the loop continues where it left off.

The prior turn's messages (the assistant turn containing the approval request) must be supplied via conversationHistory or keepHistory.

Example​

await bot.process('Delete temp.txt', {
  conversationHistory: priorMessages,
  approvalResponses: [{ approvalId, approved: true }],
});

cache?​

optional cache?: CacheControlOption

Defined in: core/dist/types/types.d.ts:776

Prompt-cache plan. Wins over cacheControl and enableCaching.

  • { scope: 'prefix', ttl: '1h' } — last always-loaded tool + system
  • { scope: 'chat' } — last-tool + system + last four messages, capped at 4
  • false — off
  • { system: true, tools: true, lastMessages: 0, ttl: '1h' } — same as prefix

Optional file/image stamps (file(..., { cacheControl: true })) are reserved in the four-breakpoint budget. ttl is forwarded to @ai-sdk/anthropic.

cacheControl?​

optional cacheControl?: CacheControlOption

Defined in: core/dist/types/types.d.ts:993

Override prompt-cache-control for this call only. Takes precedence over construction-time model.cacheControl and enableCaching. false disables. An object is the same plan as cache; if both are set, cache wins.

conversationHistory?​

optional conversationHistory?: object[]

Defined in: core/dist/types/types.d.ts:929

Conversation history for multi-turn conversations (uses OpenAI ChatMessage format from providers)

content​

content: string | MessageContentBlock[]

role​

role: "assistant" | "user" | "system" | "tool"

tool_call_id?​

optional tool_call_id?: string

tool_calls?​

optional tool_calls?: object[]

defaults?​

optional defaults?: DefaultsPatch

Defined in: core/dist/types/types.d.ts:748

Defaults for this invocation, deep-merged over the process-wide ones.

Overriding one field of a group keeps the rest of it, so steering a single run does not drop configuration set by setDefaults.

enableCaching?​

optional enableCaching?: boolean

Defined in: core/dist/types/types.d.ts:763

Chat-style prompt cache shorthand. Same as cacheControl: true / cache: { scope: 'chat' }: stamp the last always-loaded tool, the system block, and the last four conversation messages, then drop message stamps first so the request never exceeds Anthropic's four-breakpoint cap (last-tool + system survive). Unique trailing turns still get written at 1.25× — prefer cache { scope: 'prefix' } when the tools+system prefix is stable and the turns are not.

execution?​

optional execution?: ExecutionContext

Defined in: core/dist/types/types.d.ts:741

Scoped invocation context. Propagate it unchanged when calling children.

extraVars?​

optional extraVars?: Record<string, unknown>

Defined in: core/dist/types/types.d.ts:950

Extra variable bindings injected at process-time (used by BAL map/for iterators).

hooks?​

optional hooks?: ProcessHooks

Defined in: core/dist/types/types.d.ts:1030

Per-step lifecycle hooks. Awaitable — the runner awaits each hook before proceeding, so persistence can land before the next step runs.

Every composite fires the boundary hooks — onStepStart and one terminal: graph() per node, pipeline() per step, loop/map/filter per iteration, gate/router/tryCatch for the branch actually taken, and parallel() for fanOut, each branch, and the merge.

onStepEvent is narrower — today only graph() intercepts a child's stream and forwards it. Passing hooks to a pipeline() gets you its step boundaries but no per-token events; subscribeToAll() on the step is the way to watch those in the meantime.

A composite fires boundaries for the children it runs; a leaf never fires for itself. That is what makes nesting work without a double-fire guard — if a bot reported its own boundary and the graph containing it reported one on its behalf, every bot in a graph would appear twice.

The consequence worth knowing: bot.process(input, { hooks }) on a lone bot fires nothing, because nothing composed it. Use subscribeToAll(), which every Processable supports, to observe a single processable — hooks describe composition, and a lone bot has none.

Nested composites qualify their children's ids via NodeContext.path, so [...path, nodeId] is unique across arbitrary nesting where bare nodeId is not.

onStepEvent rides on the same categorized subscribeToAll contract every Processable implements — there is no separate event-emission path, just this graph-specific ordering/batching layer on top of it.

See ProcessHooks in ./graph/types.ts for the full callback shape and ordering contract.

hooksAreFatal?​

optional hooksAreFatal?: boolean

Defined in: core/dist/types/types.d.ts:1036

If true, a throwing hook rejects the run. Default (false) logs the error and continues execution — observability should not be able to break a pipeline by accident.

interruptResponses?​

optional interruptResponses?: InterruptResponse[]

Defined in: core/dist/types/types.d.ts:918

Resume answers for mid-execute() askHuman pauses (baleybots-owned).

Separate from approvalResponses — those are AI SDK native tool gates before execute. Interrupt responses replay the tool with answers injected so await askHuman(...) resolves.

maxTokens?​

optional maxTokens?: number

Defined in: core/dist/types/types.d.ts:956

Override maxTokens for this call only. Takes precedence over construction-time maxTokens.

model?​

optional model?: string | ModelConfig

Defined in: core/dist/types/types.d.ts:952

Override the model for this call only. Takes precedence over construction-time model. Independent of providerOptions/cacheControl below — overriding the model no longer drops them.

onApprovalRequired?​

optional onApprovalRequired?: (botName, toolCall, toolDefinition) => Promise<ToolApprovalResult>

Defined in: core/dist/types/types.d.ts:888

Request approval for individual tool calls (v6 pattern)

Called when a tool has requiresApproval: true or returns true from its requiresApproval function. This is called per-tool, not per-batch.

Parameters​

botName​

string

toolCall​

ToolCall

toolDefinition​

ZodToolDefinition<ZodType<unknown, unknown, $ZodTypeInternals<unknown, unknown>>, unknown>

Returns​

Promise<ToolApprovalResult>

Example​

const bot = new Baleybot({
  name: 'bot',
  goal: 'Help with files',
  tools: {
    deleteFile: defineZodTool({
      name: 'delete_file',
      description: 'Delete a file',
      inputSchema: z.object({ path: z.string() }),
      requiresApproval: true,  // Always require approval
      execute: async ({ path }) => { ... },
    }),
  },
});

await bot.process('Delete temp.txt', {
  onApprovalRequired: async (botName, toolCall, toolDef) => {
    // Show approval UI
    const approved = await showApprovalDialog(toolCall);
    return approved
      ? { approved: true }
      : { approved: false, reason: 'User cancelled' };
  },
});

onComplete?​

optional onComplete?: (botName, result) => void

Defined in: core/dist/types/types.d.ts:853

Called when processing completes with final result

Note: You can also get the final result from process() return value. This callback is provided for convenience when you need both streaming and completion notification.

Parameters​

botName​

string

result​

unknown

Returns​

void

onError?​

optional onError?: (botName, error) => void

Defined in: core/dist/types/types.d.ts:854

Parameters​

botName​

string

error​

Error

Returns​

void

onInterruptRequired?​

optional onInterruptRequired?: (botName, request) => Promise<InterruptAnswer | { cancelled: true; reason?: string; }>

Defined in: core/dist/types/types.d.ts:924

In-process handler for askHuman (Alert.showAlert-style). When omitted, askHuman emits interrupt_request and throws InterruptSignal so the turn can pause for an edge resume.

Parameters​

botName​

string

request​

InterruptRequest

Returns​

Promise<InterruptAnswer | { cancelled: true; reason?: string; }>

onStart?​

optional onStart?: (botName) => void

Defined in: core/dist/types/types.d.ts:777

Parameters​

botName​

string

Returns​

void

onStepEnd?​

optional onStepEnd?: GenerateTextOnStepEndCallback<ToolSet, Context>

Defined in: core/dist/types/types.d.ts:982

Override AI SDK onStepEnd for this call only. Thin passthrough.

onToken?​

optional onToken?: TokenHandlers | ((botName, event) => void)

Defined in: core/dist/types/types.d.ts:846

Streaming event handlers - receive events in real-time during execution

You can use BOTH streaming events AND final results together:

  • Streaming events: Provide onToken handlers to receive real-time updates via callbacks
  • Final result: Also available when process() Promise resolves (see return value)

Accepts either:

  • A callback function that receives all events
  • An object with specific handlers for each event type (recommended for type safety)

Examples​

Using both streaming AND final result (recommended)

// Stream events in real-time AND get final result
const result = await bot.process(input, {
  onToken: {
    // Real-time streaming events
    onTextDelta(botName, event) {
      process.stdout.write(event.content);  // Stream as it generates
    },
    onToolExecutionStart(botName, event) {
      console.log(`🔧 ${event.toolName} starting...`);  // Real-time tool status
    },
    onToolExecutionOutput(botName, event) {
      console.log(`✅ Tool result:`, event.result);  // Final tool result event
    },
    onToolExecutionStream(botName, event) {
      // Nested streaming from child bots
      const nested = event.nestedEvent;
      if (nested.type === 'text_delta') {
        process.stdout.write(nested.content);  // Child bot streaming
      }
    }
  }
});

// Final result available when Promise resolves
console.log('Final response:', result);  // Complete parsed response

Streaming-only (ignore final result)

await bot.process(input, {
  onToken: (botName, event) => {
    if (event.type === 'text_delta') {
      process.stdout.write(event.content);
    }
  }
});
// Don't await or use return value if you only care about streaming

Final-only (ignore streaming)

const result = await bot.process(input);
// No onToken = no streaming, just wait for final result
console.log('Response:', result);

Function approach

onToken(botName, event) {
  if (event.type === 'tool_execution_start') {
    console.log(`Starting ${event.toolName}`);
  }
}

prepareStep?​

optional prepareStep?: PrepareStepFunction<ToolSet, Context>

Defined in: core/dist/types/types.d.ts:976

Override the configured AI SDK step hook for this call; keep selection state request-scoped.

providerOptions?​

optional providerOptions?: Record<string, Record<string, unknown>>

Defined in: core/dist/types/types.d.ts:960

Override provider-specific options for this call only. Takes precedence over construction-time model.config.providerOptions.

repairToolCall?​

optional repairToolCall?: ToolCallRepairFunction<ToolSet>

Defined in: core/dist/types/types.d.ts:984

Override AI SDK experimental_repairToolCall for this call only. Thin passthrough.

runtimeContext?​

optional runtimeContext?: unknown

Defined in: core/dist/types/types.d.ts:986

Override AI SDK runtimeContext for this call only. Thin passthrough.

signal?​

optional signal?: AbortSignal

Defined in: core/dist/types/types.d.ts:752

AbortSignal to cancel the request

stopWhen?​

optional stopWhen?: StopCondition

Defined in: core/dist/types/types.d.ts:958

Override stopWhen for this call only. Takes precedence over construction-time stopWhen.

temperature?​

optional temperature?: number

Defined in: core/dist/types/types.d.ts:954

Override temperature for this call only (0–2). Takes precedence over construction-time temperature.

toolCallId?​

optional toolCallId?: string

Defined in: core/dist/types/types.d.ts:948

Tool call ID - set by executeTools when invoking a tool. Used by tools that emit streaming events (like spawn_agent) to identify which tool call the events belong to for correct UI routing.

toolOrder?​

optional toolOrder?: readonly string[]

Defined in: core/dist/types/types.d.ts:980

Override AI SDK toolOrder for this call only. Thin passthrough.

verbose?​

optional verbose?: boolean

Defined in: core/dist/types/types.d.ts:750

Enable verbose logging for debugging