@bobcao3/pi-agent-core 0.0.0-stage → 1.0.2-cpi.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2025 Mario Zechner
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/README.md CHANGED
@@ -1,3 +1,564 @@
1
- # Temporary Holding Version
1
+ # @earendil-works/pi-agent-core
2
2
 
3
- This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
3
+ Stateful agent with tool execution and event streaming. Built on `@earendil-works/pi-ai`.
4
+
5
+ ## Installation
6
+
7
+ ```bash
8
+ npm install @earendil-works/pi-agent-core
9
+ ```
10
+
11
+ ## Quick Start
12
+
13
+ ```typescript
14
+ import { Agent } from "@earendil-works/pi-agent-core";
15
+ import { createModels } from "@earendil-works/pi-ai";
16
+ import { anthropicProvider } from "@earendil-works/pi-ai/providers/anthropic";
17
+
18
+ const models = createModels();
19
+ models.setProvider(anthropicProvider());
20
+ const model = models.getModel("anthropic", "claude-sonnet-4-6");
21
+ if (!model) throw new Error("Model not found");
22
+
23
+ const agent = new Agent({
24
+ initialState: {
25
+ systemPrompt: "You are a helpful assistant.",
26
+ model,
27
+ },
28
+ streamFn: models.streamSimple.bind(models),
29
+ });
30
+
31
+ agent.subscribe((event) => {
32
+ if (event.type === "message_update" && event.assistantMessageEvent.type === "text_delta") {
33
+ // Stream just the new text chunk
34
+ process.stdout.write(event.assistantMessageEvent.delta);
35
+ }
36
+ });
37
+
38
+ await agent.prompt("Hello!");
39
+ ```
40
+
41
+ ## Core Concepts
42
+
43
+ ### AgentMessage vs LLM Message
44
+
45
+ The agent works with `AgentMessage`, a flexible type that can include:
46
+ - Standard LLM messages (`user`, `assistant`, `toolResult`)
47
+ - Custom app-specific message types via declaration merging
48
+
49
+ LLMs only understand `user`, `assistant`, and `toolResult`. The `convertToLlm` function bridges this gap by filtering and transforming messages before each LLM call.
50
+
51
+ ### Message Flow
52
+
53
+ ```
54
+ AgentMessage[] → transformContext() → AgentMessage[] → convertToLlm() → Message[] → LLM
55
+ (optional) (required)
56
+ ```
57
+
58
+ 1. **transformContext**: Prune old messages, inject external context
59
+ 2. **convertToLlm**: Filter out UI-only messages, convert custom types to LLM format
60
+
61
+ ## Event Flow
62
+
63
+ The agent emits events for UI updates. Understanding the event sequence helps build responsive interfaces.
64
+
65
+ ### prompt() Event Sequence
66
+
67
+ When you call `prompt("Hello")`:
68
+
69
+ ```
70
+ prompt("Hello")
71
+ ├─ agent_start
72
+ ├─ turn_start
73
+ ├─ message_start { message: userMessage } // Your prompt
74
+ ├─ message_end { message: userMessage }
75
+ ├─ message_start { message: assistantMessage } // LLM starts responding
76
+ ├─ message_update { message: partial... } // Streaming chunks
77
+ ├─ message_update { message: partial... }
78
+ ├─ message_end { message: assistantMessage } // Complete response
79
+ ├─ turn_end { message, toolResults: [] }
80
+ └─ agent_end { messages: [...] }
81
+ ```
82
+
83
+ ### With Tool Calls
84
+
85
+ If the assistant calls tools, the loop continues:
86
+
87
+ ```
88
+ prompt("Read config.json")
89
+ ├─ agent_start
90
+ ├─ turn_start
91
+ ├─ message_start/end { userMessage }
92
+ ├─ message_start { assistantMessage with toolCall }
93
+ ├─ message_update...
94
+ ├─ message_end { assistantMessage }
95
+ ├─ tool_execution_start { toolCallId, toolName, args }
96
+ ├─ tool_execution_update { partialResult } // If tool streams
97
+ ├─ tool_execution_end { toolCallId, result }
98
+ ├─ message_start/end { toolResultMessage }
99
+ ├─ turn_end { message, toolResults: [toolResult] }
100
+ │
101
+ ├─ turn_start // Next turn
102
+ ├─ message_start { assistantMessage } // LLM responds to tool result
103
+ ├─ message_update...
104
+ ├─ message_end
105
+ ├─ turn_end
106
+ └─ agent_end
107
+ ```
108
+
109
+ Tool execution mode is configurable:
110
+
111
+ - `parallel` (default): preflight tool calls sequentially, execute allowed tools concurrently, emit `tool_execution_end` as soon as each tool is finalized, then emit toolResult messages and `turn_end.toolResults` in assistant source order
112
+ - `sequential`: execute tool calls one by one, matching the historical behavior
113
+
114
+ In parallel mode, tool completion events follow tool completion order, but persisted toolResult messages still follow assistant source order.
115
+
116
+ The mode can be set globally via `toolExecution` in the agent config, or per-tool via `executionMode` on `AgentTool`. If any tool call in a batch targets a tool with `executionMode: "sequential"`, the entire batch executes sequentially regardless of the global setting.
117
+
118
+ The `beforeToolCall` hook runs after `tool_execution_start` and validated argument parsing. It can block execution and attach `terminate: true` to the blocked result. The `afterToolCall` hook runs after tool execution finishes and before `tool_execution_end` and final tool result message events are emitted.
119
+
120
+ Tools, blocked `beforeToolCall` results, and `afterToolCall` overrides can return `terminate: true` to hint that the automatic follow-up LLM call should be skipped. The loop only stops early when every finalized tool result in that batch sets `terminate: true`. Mixed batches continue normally.
121
+
122
+ When you use the `Agent` class, assistant `message_end` processing is treated as a barrier before tool preflight begins. That means `beforeToolCall` sees agent state that already includes the assistant message that requested the tool call.
123
+
124
+ ### Request preparation and turn finalization
125
+
126
+ `prepareRequest` runs immediately before every conversational provider request, including the first. Use it to install canonical persisted context after pending input has been emitted:
127
+
128
+ ```typescript
129
+ agent.prepareRequest = async ({ context }) => ({
130
+ context: { ...context, messages: await session.loadModelContext() },
131
+ });
132
+ ```
133
+
134
+ `prepareRequest` does not poll queues. Steering queued while it runs waits for the next normal steering poll.
135
+
136
+ `finishTurn` runs after the assistant and all tool results are finalized, but before `turn_end`. It runs for normal, error, and aborted responses:
137
+
138
+ ```typescript
139
+ agent.finishTurn = async ({ message }) => {
140
+ if (message.stopReason === "error" || message.stopReason === "aborted") return;
141
+ if (shouldEndRun(message)) return { action: "end" };
142
+ return needsAnotherResponse(message) ? { action: "continue" } : undefined;
143
+ };
144
+ ```
145
+
146
+ Returning `undefined` preserves normal scheduling. `{ action: "end" }` stops immediately after `turn_end`, before polling steering or follow-up queues or preparing another request. On a normal response, `{ action: "continue" }` ensures one next provider request. If tool results, steering, or a follow-up already cause that request, they satisfy the decision and no additional request is made; otherwise the loop makes one context-only request. Error and aborted responses remain hard exits, so their decisions are ignored. `finishTurn` runs again after the next request, so returning `{ action: "continue" }` unconditionally creates an endless loop.
147
+
148
+ To migrate from the removed `shouldStopAfterTurn`, return `{ action: "end" }`. Guard error and aborted responses to preserve the old hook's normal-response-only invocation, especially when the predicate has side effects or assumes a successful response:
149
+
150
+ ```typescript
151
+ finishTurn: async (turn, signal) => {
152
+ if (turn.message.stopReason === "error" || turn.message.stopReason === "aborted") return;
153
+ return (await shouldStop(turn, signal)) ? { action: "end" } : undefined;
154
+ },
155
+ ```
156
+
157
+ Each provider turn follows this lifecycle:
158
+
159
+ ```text
160
+ selected input events
161
+ → prepareRequest
162
+ → provider response
163
+ → tool results
164
+ → finishTurn
165
+ → turn_end
166
+ → existing continuation scheduling or agent_end
167
+ ```
168
+
169
+ ### continue() and queued input
170
+
171
+ `continue()` retains its existing queue behavior. Empty and system-only transcripts reject without consuming queues. A non-assistant tail continues from existing context: steering is polled at startup, while follow-up input waits until the response naturally stops.
172
+
173
+ ```typescript
174
+ agent.followUp({ role: "user", content: "After the retry", timestamp: Date.now() });
175
+ await agent.continue(); // The first request retries the existing user/toolResult tail.
176
+ ```
177
+
178
+ An assistant tail cannot be sent directly, so `continue()` falls back to one queued steering batch, then one queued follow-up batch. Queue mode still controls whether that selected batch contains one message or all messages:
179
+
180
+ ```typescript
181
+ agent.steer({ role: "user", content: "Continue from here", timestamp: Date.now() });
182
+ await agent.continue(); // Uses the queued message only because the tail is assistant.
183
+ ```
184
+
185
+ ### Event Types
186
+
187
+ | Event | Description |
188
+ |-------|-------------|
189
+ | `agent_start` | Agent begins processing |
190
+ | `agent_end` | Final event for the run. Awaited subscribers for this event still count toward settlement |
191
+ | `turn_start` | New turn begins (one LLM call + tool executions) |
192
+ | `turn_end` | Turn completes with assistant message and tool results |
193
+ | `message_start` | Any message begins (user, assistant, toolResult) |
194
+ | `message_update` | **Assistant only.** Includes `assistantMessageEvent` with delta |
195
+ | `message_end` | Message completes |
196
+ | `tool_execution_start` | Tool begins |
197
+ | `tool_execution_update` | Tool streams progress |
198
+ | `tool_execution_end` | Tool completes |
199
+
200
+ `Agent.subscribe()` listeners are awaited in registration order. `agent_end` means no more loop events will be emitted, but `await agent.waitForIdle()` and `await agent.prompt(...)` only settle after awaited `agent_end` listeners finish.
201
+
202
+ ## Agent Options
203
+
204
+ ```typescript
205
+ const agent = new Agent({
206
+ // Initial state. systemPrompt and tools become the leading system message
207
+ // unless messages already starts with one.
208
+ initialState: {
209
+ systemPrompt: string,
210
+ model: Model<any>,
211
+ thinkingLevel: "off" | "minimal" | "low" | "medium" | "high" | "xhigh" | "max",
212
+ tools: AgentTool<any>[],
213
+ messages: AgentMessage[],
214
+ },
215
+
216
+ // Convert AgentMessage[] to LLM Message[] (required for custom message types)
217
+ convertToLlm: (messages) => messages.filter(...),
218
+
219
+ // Transform context before convertToLlm (for pruning, compaction)
220
+ transformContext: async (messages, signal) => pruneOldMessages(messages),
221
+
222
+ // Steering mode: "one-at-a-time" (default) or "all"
223
+ steeringMode: "one-at-a-time",
224
+
225
+ // Follow-up mode: "one-at-a-time" (default) or "all"
226
+ followUpMode: "one-at-a-time",
227
+
228
+ // Required stream function. Receives a TranscriptContext: the prompt and tools
229
+ // are in the transcript's system messages, not on the context.
230
+ streamFn: models.streamSimple.bind(models),
231
+
232
+ // Session ID for provider caching
233
+ sessionId: "session-123",
234
+
235
+ // Dynamic API key resolution (for expiring OAuth tokens)
236
+ getApiKey: async (provider) => refreshToken(),
237
+
238
+ // Tool execution mode: "parallel" (default) or "sequential"
239
+ toolExecution: "parallel",
240
+
241
+ // Preflight each tool call after args are validated. Can block execution.
242
+ beforeToolCall: async ({ toolCall, args, context }) => {
243
+ if (toolCall.name === "bash") {
244
+ return { block: true, reason: "bash is disabled", terminate: true };
245
+ }
246
+ },
247
+
248
+ // Postprocess each tool result before final tool events are emitted.
249
+ afterToolCall: async ({ toolCall, result, isError, context }) => {
250
+ if (toolCall.name === "notify_done" && !isError) {
251
+ return { terminate: true };
252
+ }
253
+ if (!isError) {
254
+ return { details: { ...result.details, audited: true } };
255
+ }
256
+ },
257
+
258
+ // Rebuild finalized context immediately before every provider request.
259
+ prepareRequest: async ({ context }, signal) => {
260
+ return { context: { ...context, messages: await loadCanonicalMessages(signal) } };
261
+ },
262
+
263
+ // Finalize a completed turn before turn_end is emitted.
264
+ // `continue` ensures one next request; existing tool/queue scheduling can satisfy it.
265
+ // `end` ends this run after turn_end without polling queues.
266
+ finishTurn: async ({ message, toolResults }, signal) => {
267
+ return shouldContinue(message, toolResults) ? { action: "continue" } : undefined;
268
+ },
269
+
270
+ // Custom thinking budgets for token-based providers
271
+ thinkingBudgets: {
272
+ minimal: 128,
273
+ low: 512,
274
+ medium: 1024,
275
+ high: 2048,
276
+ },
277
+ });
278
+ ```
279
+
280
+ ## Agent State
281
+
282
+ ```typescript
283
+ interface AgentState {
284
+ model: Model<any>;
285
+ thinkingLevel: ThinkingLevel;
286
+ tools: AgentTool<any>[];
287
+ messages: AgentMessage[];
288
+ readonly isStreaming: boolean;
289
+ readonly streamingMessage?: AgentMessage;
290
+ readonly pendingToolCalls: ReadonlySet<string>;
291
+ readonly errorMessage?: string;
292
+ }
293
+ ```
294
+
295
+ Access state via `agent.state`.
296
+
297
+ Assigning `agent.state.tools = [...]` or `agent.state.messages = [...]` copies the top-level array before storing it. Mutating the returned array mutates the current agent state.
298
+
299
+ The transcript owns the system prompt and tool declarations: the leading system message is the prompt, later system messages patch it (see `SystemMessage` in pi-ai). `agent.state.systemPrompt` is read-only and replays the transcript. `agent.state.tools` is the executable loadout; before every request the loop diffs it against the tools the transcript declares and, if they differ, announces the change in a system message (merged into a pending system message when one exists). pi-ai's `getCurrentSystemMessage(messages)` returns the replayed head, including declared tools, for any message array, including agent transcripts with custom message roles.
300
+
301
+ To change the prompt mid-conversation, append a system message with `content` (added instructions) or `sections` (named replacements):
302
+
303
+ ```typescript
304
+ await agent.prompt([
305
+ { role: "system", content: "", sections: { skills: "<skills>...</skills>" }, timestamp: Date.now() },
306
+ { role: "user", content: "Continue", timestamp: Date.now() },
307
+ ]);
308
+ ```
309
+
310
+ During streaming, `agent.state.streamingMessage` contains the current partial assistant message.
311
+
312
+ `agent.state.isStreaming` remains `true` until the run fully settles, including awaited `agent_end` subscribers.
313
+
314
+ ## Methods
315
+
316
+ ### Prompting
317
+
318
+ ```typescript
319
+ // Text prompt
320
+ await agent.prompt("Hello");
321
+
322
+ // With images
323
+ await agent.prompt("What's in this image?", [
324
+ { type: "image", data: base64Data, mimeType: "image/jpeg" }
325
+ ]);
326
+
327
+ // AgentMessage directly
328
+ await agent.prompt({ role: "user", content: "Hello", timestamp: Date.now() });
329
+
330
+ // Continue existing non-assistant input; an assistant tail may use queued input as fallback
331
+ await agent.continue();
332
+ ```
333
+
334
+ ### State Management
335
+
336
+ ```typescript
337
+ agent.state.model = getModel("openai", "gpt-4o");
338
+ agent.state.thinkingLevel = "medium";
339
+ agent.state.tools = [myTool];
340
+ agent.toolExecution = "sequential";
341
+ agent.beforeToolCall = async ({ toolCall }) => undefined;
342
+ agent.afterToolCall = async ({ toolCall, result }) => undefined;
343
+ agent.prepareRequest = async ({ context }) => ({
344
+ context: { ...context, messages: await loadCanonicalMessages() },
345
+ });
346
+ agent.finishTurn = async () => undefined;
347
+ agent.state.messages = newMessages; // top-level array is copied
348
+ agent.state.messages.push(message);
349
+ const nextQueuedMessages = agent.peekQueuedMessages(); // respects queue modes; does not consume
350
+ agent.reset();
351
+ ```
352
+
353
+ ### Session and Thinking Budgets
354
+
355
+ ```typescript
356
+ agent.sessionId = "session-123";
357
+
358
+ agent.thinkingBudgets = {
359
+ minimal: 128,
360
+ low: 512,
361
+ medium: 1024,
362
+ high: 2048,
363
+ };
364
+ ```
365
+
366
+ ### Control
367
+
368
+ ```typescript
369
+ agent.abort(); // Cancel current operation
370
+ await agent.waitForIdle(); // Wait for completion
371
+ ```
372
+
373
+ ### Events
374
+
375
+ ```typescript
376
+ const unsubscribe = agent.subscribe(async (event, signal) => {
377
+ if (event.type === "agent_end") {
378
+ // Final barrier work for the run
379
+ await flushSessionState(signal);
380
+ }
381
+ });
382
+ unsubscribe();
383
+ ```
384
+
385
+ ## Steering and Follow-up
386
+
387
+ Steering messages let you interrupt the agent while tools are running. Follow-up messages let you queue work after the agent would otherwise stop.
388
+
389
+ ```typescript
390
+ agent.steeringMode = "one-at-a-time";
391
+ agent.followUpMode = "one-at-a-time";
392
+
393
+ // While agent is running tools
394
+ agent.steer({
395
+ role: "user",
396
+ content: "Stop! Do this instead.",
397
+ timestamp: Date.now(),
398
+ });
399
+
400
+ // After the agent finishes its current work
401
+ agent.followUp({
402
+ role: "user",
403
+ content: "Also summarize the result.",
404
+ timestamp: Date.now(),
405
+ });
406
+
407
+ const steeringMode = agent.steeringMode;
408
+ const followUpMode = agent.followUpMode;
409
+
410
+ agent.clearSteeringQueue();
411
+ agent.clearFollowUpQueue();
412
+ agent.clearAllQueues();
413
+ ```
414
+
415
+ Use clearSteeringQueue, clearFollowUpQueue, or clearAllQueues to drop queued messages.
416
+
417
+ When steering messages are detected after a turn completes:
418
+ 1. All tool calls from the current assistant message have already finished
419
+ 2. Steering messages are injected
420
+ 3. The LLM responds on the next turn
421
+
422
+ Follow-up messages are checked only when there are no more tool calls and no steering messages. If any are queued, they are injected and another turn runs.
423
+
424
+ ## Custom Message Types
425
+
426
+ Extend `AgentMessage` via declaration merging:
427
+
428
+ ```typescript
429
+ declare module "@earendil-works/pi-agent-core" {
430
+ interface CustomAgentMessages {
431
+ notification: { role: "notification"; text: string; timestamp: number };
432
+ }
433
+ }
434
+
435
+ // Now valid
436
+ const msg: AgentMessage = { role: "notification", text: "Info", timestamp: Date.now() };
437
+ ```
438
+
439
+ Handle custom types in `convertToLlm`:
440
+
441
+ ```typescript
442
+ const agent = new Agent({
443
+ streamFn: models.streamSimple.bind(models),
444
+ convertToLlm: (messages) => messages.flatMap(m => {
445
+ if (m.role === "notification") return []; // Filter out
446
+ return [m];
447
+ }),
448
+ });
449
+ ```
450
+
451
+ ## Tools
452
+
453
+ Define tools using `AgentTool`:
454
+
455
+ ```typescript
456
+ import { Type } from "typebox";
457
+
458
+ const readFileTool: AgentTool = {
459
+ name: "read_file",
460
+ label: "Read File", // For UI display
461
+ description: "Read a file's contents",
462
+ parameters: Type.Object({
463
+ path: Type.String({ description: "File path" }),
464
+ }),
465
+ // Override execution mode for this tool (optional).
466
+ // "sequential" forces the entire batch to run one at a time.
467
+ // "parallel" allows concurrent execution with other tool calls.
468
+ // If omitted, the global toolExecution config applies.
469
+ executionMode: "sequential",
470
+ execute: async (toolCallId, params, signal, onUpdate) => {
471
+ const content = await fs.readFile(params.path, "utf-8");
472
+
473
+ // Optional: stream progress
474
+ onUpdate?.({ content: [{ type: "text", text: "Reading..." }], details: {} });
475
+
476
+ // Optional: add `terminate: true` here to skip the automatic follow-up LLM call
477
+ // when every finalized tool result in the batch does the same.
478
+ return {
479
+ content: [{ type: "text", text: content }],
480
+ details: { path: params.path, size: content.length },
481
+ };
482
+ },
483
+ };
484
+
485
+ agent.state.tools = [readFileTool];
486
+ ```
487
+
488
+ ### Error Handling
489
+
490
+ **Throw an error** when a tool fails. Do not return error messages as content.
491
+
492
+ ```typescript
493
+ execute: async (toolCallId, params, signal, onUpdate) => {
494
+ if (!fs.existsSync(params.path)) {
495
+ throw new Error(`File not found: ${params.path}`);
496
+ }
497
+ // Return content only on success
498
+ return { content: [{ type: "text", text: "..." }] };
499
+ }
500
+ ```
501
+
502
+ Thrown errors are caught by the agent and reported to the LLM as tool errors with `isError: true`.
503
+
504
+ Return `terminate: true` from `execute()`, a blocked `beforeToolCall`, or `afterToolCall` to hint that the agent should stop after the current tool batch. This only takes effect when every finalized tool result in the batch is terminating. The hint is runtime-only; emitted `toolResult` transcript messages remain standard LLM tool results.
505
+
506
+ ### MCP and Codemode
507
+
508
+ `@earendil-works/pi-mcp` connects to MCP servers and `@earendil-works/pi-codemode` runs model-written JavaScript that calls tools. [examples/mcp-codemode](examples/mcp-codemode) wraps both as `AgentTool`s: one tool per MCP tool, and a `codemode` tool whose scripts call the agent's tools through `runToolCall()`, so `beforeToolCall` and `afterToolCall` apply to those calls too.
509
+
510
+ ## Proxy Usage
511
+
512
+ For browser apps that proxy through a backend:
513
+
514
+ ```typescript
515
+ import { Agent, streamProxy } from "@earendil-works/pi-agent-core";
516
+
517
+ const agent = new Agent({
518
+ streamFn: (model, context, options) =>
519
+ streamProxy(model, context, {
520
+ ...options,
521
+ authToken: "...",
522
+ proxyUrl: "https://your-server.com",
523
+ }),
524
+ });
525
+ ```
526
+
527
+ ## Low-Level API
528
+
529
+ For direct control without the Agent class:
530
+
531
+ ```typescript
532
+ import { agentLoop, agentLoopContinue } from "@earendil-works/pi-agent-core";
533
+
534
+ const context: AgentContext = {
535
+ messages: [{ role: "system", content: "You are helpful.", timestamp: Date.now() }],
536
+ tools: [],
537
+ };
538
+
539
+ const config: AgentLoopConfig = {
540
+ model: getModel("openai", "gpt-4o"),
541
+ convertToLlm: (msgs) => msgs.filter(m => ["user", "assistant", "toolResult"].includes(m.role)),
542
+ toolExecution: "parallel", // overridden by per-tool executionMode if set
543
+ beforeToolCall: async ({ toolCall, args, context }) => undefined,
544
+ afterToolCall: async ({ toolCall, result, isError, context }) => undefined,
545
+ };
546
+
547
+ const userMessage = { role: "user", content: "Hello", timestamp: Date.now() };
548
+
549
+ const streamFn = models.streamSimple.bind(models);
550
+ for await (const event of agentLoop([userMessage], context, config, undefined, streamFn)) {
551
+ console.log(event.type);
552
+ }
553
+
554
+ // Continue from existing context
555
+ for await (const event of agentLoopContinue(context, config, undefined, streamFn)) {
556
+ console.log(event.type);
557
+ }
558
+ ```
559
+
560
+ These low-level streams are observational. They preserve event order, but they do not wait for your async event handling to settle before later producer phases continue. If you need message processing to act as a barrier before tool preflight, use the `Agent` class instead of raw `agentLoop()` or `agentLoopContinue()`.
561
+
562
+ ## License
563
+
564
+ MIT
@@ -0,0 +1,48 @@
1
+ /**
2
+ * Agent loop that works with AgentMessage throughout.
3
+ * Transforms to Message[] only at the LLM call boundary.
4
+ */
5
+ import { type AssistantMessage, EventStream } from "@earendil-works/pi-ai";
6
+ import type { AgentContext, AgentEvent, AgentLoopConfig, AgentMessage, AgentTool, AgentToolCall, AgentToolCallOutcome, AgentToolResult, StreamFn } from "./types.ts";
7
+ export type AgentEventSink = (event: AgentEvent) => Promise<void> | void;
8
+ /**
9
+ * Start an agent loop with a new prompt message.
10
+ * The prompt is added to the context and events are emitted for it.
11
+ */
12
+ export declare function agentLoop(prompts: AgentMessage[], context: AgentContext, config: AgentLoopConfig, signal: AbortSignal | undefined, streamFn: StreamFn): EventStream<AgentEvent, AgentMessage[]>;
13
+ /**
14
+ * Continue an agent loop from the current context without adding a new message.
15
+ * Used for retries - context already has user message or tool results.
16
+ *
17
+ * **Important:** The last message in context must convert to a `user` or `toolResult` message
18
+ * via `convertToLlm`. If it doesn't, the LLM provider will reject the request.
19
+ * This cannot be validated here since `convertToLlm` is only called once per turn.
20
+ */
21
+ export declare function agentLoopContinue(context: AgentContext, config: AgentLoopConfig, signal: AbortSignal | undefined, streamFn: StreamFn): EventStream<AgentEvent, AgentMessage[]>;
22
+ export declare function runAgentLoop(prompts: AgentMessage[], context: AgentContext, config: AgentLoopConfig, emit: AgentEventSink, signal: AbortSignal | undefined, streamFn: StreamFn): Promise<AgentMessage[]>;
23
+ export declare function runAgentLoopContinue(context: AgentContext, config: AgentLoopConfig, emit: AgentEventSink, signal: AbortSignal | undefined, streamFn: StreamFn): Promise<AgentMessage[]>;
24
+ /** The `beforeToolCall` and `afterToolCall` hooks of {@link AgentLoopConfig}. */
25
+ export type ToolCallHooks = Pick<AgentLoopConfig, "beforeToolCall" | "afterToolCall">;
26
+ type ToolUpdateSink = (partialResult: AgentToolResult<any>) => Promise<void> | void;
27
+ /** Options for {@link runToolCall}. */
28
+ export interface RunToolCallOptions extends ToolCallHooks {
29
+ /** Tools the call resolves against. */
30
+ tools: readonly AgentTool<any>[];
31
+ /** Passed to the hooks as the message that issued the call. */
32
+ assistantMessage: AssistantMessage;
33
+ /** Passed to the hooks as the current agent context. */
34
+ context: AgentContext;
35
+ signal?: AbortSignal;
36
+ onUpdate?: ToolUpdateSink;
37
+ }
38
+ /**
39
+ * Run one tool call through the same steps as a model-issued call: argument preparation, schema
40
+ * validation, `beforeToolCall`, execution, and `afterToolCall`. Emits no events and adds no
41
+ * messages. Tools that call other tools use this so the hooks (for example permission checks)
42
+ * apply to those calls too.
43
+ *
44
+ * Never rejects for tool failures: unknown tools, validation errors, blocked calls, and thrown
45
+ * errors come back as `isError: true`.
46
+ */
47
+ export declare function runToolCall(toolCall: AgentToolCall, options: RunToolCallOptions): Promise<AgentToolCallOutcome>;
48
+ export {};