loopengine 0.0.21 → 0.1.3

package/dist/core/run-agent.js

@@ -16,7 +16,9 @@ import { Recovery } from './recovery.js';
 import { loadAgentModule } from './discover-agents.js';
 import { agentAsTool } from './agent-as-tool.js';
 import { loadGatewayToolsFromDir } from './gateway-tools.js';
-import { systemTools, createAskUserTool } from './system-tools/index.js';
+import { systemTools, createAskUserTool, CliQuestionHandler, isDurableQuestionHandler } from './system-tools/index.js';
+import { resolveHttpNotifier } from './http-notifier.js';
+import { CRASH_RECOVERY_CONTINUATION } from './session-store.js';
 export { systemTools } from './system-tools/index.js';
 // Resolved relative to *this file's own location* (via import.meta.url),
 // not process.cwd() — the same reasoning core/agent-registry.ts's own
@@ -31,6 +33,23 @@ export { systemTools } from './system-tools/index.js';
 // tools/index.ts is real code that only exists compiled, at a different
 // relative location, once dist/ is what's actually running.
 const agentsRootDir = join(dirname(fileURLToPath(import.meta.url)), '..', 'agents');
+// agentsRootDir above is right when agents/ is compiled alongside core/
+// into the same dist/ tree (this repo's own reference agents; also this
+// repo's own Dockerfile, which copies dist/agents/**/*.js this way) — but
+// a project that only *depends on* the published loopengine package has
+// no dist/agents/<name> inside node_modules/loopengine at all, just its
+// own agents/<name>/ at the project root, found only via process.cwd(),
+// the same way loadRules/skillsDirs already resolve their own (data, not
+// code) defaults. Tried first since it's this repo's own existing,
+// tested behavior; process.cwd() only kicks in when nothing's built
+// there to find — so this repo's own agents are unaffected either way.
+function resolveAgentCodeDir(name, subpath, indexRequired) {
+    const built = join(agentsRootDir, name, subpath);
+    const builtExists = indexRequired
+        ? existsSync(join(built, 'index.ts')) || existsSync(join(built, 'index.js'))
+        : existsSync(built);
+    return builtExists ? built : join(process.cwd(), 'agents', name, subpath);
+}
 // Same "resolved relative to this file's own location" reasoning as
 // agentsRootDir above, but system-skills/ is a same-level sibling of
 // run-agent.ts itself (both live directly under core/ — see package.json's
@@ -58,7 +77,7 @@ function flattenForBudget(message) {
         return { role: message.role, content: message.content };
     const text = message.content
         .map((block) => {
-        if (block.type === 'text')
+        if (block.type === 'text' || block.type === 'thinking')
             return block.text ?? '';
         if (block.type === 'tool_use')
             return `[tool_use ${block.name}(${JSON.stringify(block.input)})]`;
@@ -155,7 +174,7 @@ async function loadToolsFromDir(toolsDir) {
     return [];
 }
 export async function loadDefaultTools(config) {
-    return loadToolsFromDir(join(agentsRootDir, config.name, 'tools'));
+    return loadToolsFromDir(resolveAgentCodeDir(config.name, 'tools', true));
 }
 /** Every other folder-form default in this file (loadDefaultTools,
  * loadRules, the skillsDirs default below) resolves against
@@ -227,7 +246,7 @@ async function resolveSubagentConfig(config, dir) {
  * this can't cycle the way a hand-wired agentAsTool(getEntry(...)) call
  * elsewhere could. */
 export async function loadSubagentAsTools(config) {
-    const subagentsDir = join(agentsRootDir, config.name, 'subagents');
+    const subagentsDir = resolveAgentCodeDir(config.name, 'subagents', false);
     if (!existsSync(subagentsDir))
         return [];
     const tools = [];
@@ -245,7 +264,7 @@ export async function loadSubagentAsTools(config) {
     }
     return tools;
 }
-export async function runAgent(config, modelCall, userMessage, history = [], options = {}) {
+async function buildTurnContext(config, modelCall, options) {
     const log = options.onEvent ?? (() => { });
     // tenant: resolved by the caller (adapters/http.ts calls
     // AgentConfig.tenantFor with the request's headers/body; every other
@@ -278,7 +297,7 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
         askUserTool,
         ...(config.tools ?? (await loadDefaultTools(config))),
         ...(await loadSubagentAsTools(config)),
-        ...(await loadGatewayToolsFromDir(join(agentsRootDir, config.name))),
+        ...(await loadGatewayToolsFromDir(join(process.cwd(), 'agents', config.name))),
     ]);
     // Omitted entirely (undefined): default to this agent's own
     // agents/<name>/skills — the folder-form convention every agent in
@@ -305,63 +324,36 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
     const budgetTracker = new BudgetTracker({ budgetTokens: config.contextBudgetTokens ?? 8000 });
     const compactor = new Compactor({ budgetTokens: config.contextBudgetTokens ?? 8000, softThreshold: budgetTracker.softThreshold, tailMessages });
     const rules = loadRules(config);
-    const gate = new Gate(rules, config.approver ?? options.approver ?? new ConsoleApprover());
+    // AgentConfig.httpNotifier only ever stands in for the http channel —
+    // see its own doc comment for why cli/http_stream never consult it at
+    // all, not even as a fallback.
+    const httpNotifier = resolveHttpNotifier(config);
+    // httpNotifier.approver, when the http channel has one, wins outright
+    // over options.approver — the same "the agent's own explicit choice for
+    // this channel beats whatever the adapter would otherwise default to"
+    // precedent a channel-keyed override always had here. This ordering
+    // matters in practice, not just on paper: adapters/http.ts's own plain
+    // /messages route always passes *some* options.approver (its own
+    // deployment-wide durable default, or a live tracked one) — checking
+    // httpNotifier first is what lets a single agent's own httpNotifier
+    // actually take effect there, rather than being silently shadowed by
+    // that per-deployment default every time.
+    const approver = (options.channel === 'http' ? httpNotifier.approver : undefined) ?? options.approver ?? new ConsoleApprover();
+    const gate = new Gate(rules, approver);
+    // Exact mirror of approver's own resolution above, same reasoning and
+    // same ordering (httpNotifier checked before options.questionHandler,
+    // not after — see approver's own comment for why that order matters in
+    // practice, not just on paper) — see RunAgentOptions.questionHandler's
+    // own doc comment for the one place this still isn't a full mirror of
+    // approver (only the durable branch below actually reads this; the live
+    // branch keeps resolving independently, via onQuestionPending).
+    const questionHandler = (options.channel === 'http' ? httpNotifier.questionHandler : undefined) ?? options.questionHandler ?? new CliQuestionHandler();
     // No explicit isSafeTool: fall back to each called tool's own `safe`
     // flag (looked up by name) rather than defaulting every tool to unsafe
     // outright — see ToolDefinition.safe's own doc comment for why this is
     // the less powerful of the two (name-only, no per-call nuance).
     const isSafeTool = config.isSafeTool ?? ((call) => tools.some((t) => t.name === call.name && t.safe === true));
     const toolLane = new ToolLane({ isSafe: isSafeTool });
-    let messages = [...history, { role: 'user', content: userMessage }];
-    // Tracked in parallel with `messages`, but never rewritten wholesale by
-    // recovery the way `messages` is — this is the actual, authoritative
-    // answer to "what did this turn add," independent of how many times (if
-    // any) the head of `messages` got drained/summarized along the way. See
-    // pushMessage() below and the reconciliation inside onPromptTooLong.
-    let newMessages = [{ role: 'user', content: userMessage }];
-    function pushMessage(message) {
-        messages.push(message);
-        newMessages.push(message);
-    }
-    const recovery = new Recovery({
-        onPromptTooLong: async (currentMessages) => {
-            // newMessages (this turn's own content — not durably stored
-            // anywhere else yet) must never be handed to the compactor at all.
-            // An earlier version of this reconciliation tried to recover
-            // newMessages *after* compaction by reusing whatever the
-            // compactor's synthetic head contained — that's unsound: its cheap
-            // "drain" stage doesn't produce a head at all, it just deletes old
-            // messages outright, trusting there's a durable copy elsewhere.
-            // That trust is only valid for the *prior* portion; only that
-            // portion is safe to compact at all.
-            const priorCount = currentMessages.length - newMessages.length;
-            const priorPortion = currentMessages.slice(0, priorCount);
-            const result = await compactor.recover(priorPortion.map(flattenForBudget));
-            log({ type: 'prompt:compaction', from: currentMessages.length, to: result.messages.length + newMessages.length });
-            if (result.action === 'unchanged')
-                return currentMessages;
-            // Same tail-preservation reuse as before, just scoped to
-            // priorPortion alone now — newMessages is appended back whole,
-            // always, regardless of how large it's grown this turn.
-            const preservedTailCount = Math.min(tailMessages, priorPortion.length);
-            const structuredTail = priorPortion.slice(priorPortion.length - preservedTailCount);
-            const newHead = result.messages.slice(0, result.messages.length - preservedTailCount);
-            const recovered = [...newHead, ...structuredTail, ...newMessages];
-            // Recovery.call() only ever returns {value, recoveries, truncated} —
-            // it never hands back whatever `currentMessages` became after a
-            // retry, so recovery would otherwise only ever affect the one
-            // retried call. Reassigning the outer `messages` binding here (this
-            // hook is the only place that has both the recovered array and a
-            // reason to persist it) is what makes recovery durable: every
-            // subsequent budgetTracker.check() in this loop, and the `history`
-            // this function eventually returns, both see the compacted
-            // conversation from this point on — not the original, ever-growing
-            // one. newMessages itself needs no reconciliation at all — it was
-            // never part of what could be compacted away.
-            messages = recovered;
-            return recovered;
-        },
-    });
     const toolsByName = new Map(tools.map((t) => [t.name, t]));
     // Object identity, not name — an agent that overrides a system tool's
     // name with its own ToolDefinition (dedupeToolsByName's own "config
@@ -412,6 +404,81 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
     // (or ping-ponging) tool calls forever — checked before spending a model
     // call on the (maxTurns + 1)-th turn, not after.
     const maxTurns = config.maxTurns ?? 25;
+    return {
+        modelCall,
+        log,
+        scope,
+        sessionId: options.sessionId,
+        skillGarden,
+        toolsByName,
+        systemToolInstances,
+        toolSchemas,
+        systemPrompt,
+        budgetTracker,
+        compactor,
+        gate,
+        toolLane,
+        maxTurns,
+        tailMessages,
+        askUserTool,
+        questionHandler,
+        httpNotifier,
+    };
+}
+/** The turn's actual ReAct loop — shared by runAgent (a fresh turn, its
+ * own starterMessage is the user's own message) and resumeAgent (a
+ * paused turn's completing tool_result message as starterMessage,
+ * picking up right where run-agent.ts's own bucket-then-execute left
+ * off — see RunAgentResult.stopReason's own 'pending_approval' doc
+ * comment). `messages`/`newMessages` are owned by the caller (built
+ * fresh in each case) but mutated here via pushMessage, same as the
+ * single function this was split out of always did. */
+async function runLoop(ctx, messages, newMessages, starterMessage) {
+    const { modelCall, log, scope, sessionId, skillGarden, toolsByName, systemToolInstances, toolSchemas, systemPrompt, budgetTracker, compactor, gate, toolLane, maxTurns, tailMessages, askUserTool, questionHandler } = ctx;
+    function pushMessage(message) {
+        messages.push(message);
+        newMessages.push(message);
+    }
+    const recovery = new Recovery({
+        onPromptTooLong: async (currentMessages) => {
+            // newMessages (this turn's own content — not durably stored
+            // anywhere else yet) must never be handed to the compactor at all.
+            // An earlier version of this reconciliation tried to recover
+            // newMessages *after* compaction by reusing whatever the
+            // compactor's synthetic head contained — that's unsound: its cheap
+            // "drain" stage doesn't produce a head at all, it just deletes old
+            // messages outright, trusting there's a durable copy elsewhere.
+            // That trust is only valid for the *prior* portion; only that
+            // portion is safe to compact at all.
+            const priorCount = currentMessages.length - newMessages.length;
+            const priorPortion = currentMessages.slice(0, priorCount);
+            const result = await compactor.recover(priorPortion.map(flattenForBudget));
+            log({ type: 'prompt:compaction', from: currentMessages.length, to: result.messages.length + newMessages.length });
+            if (result.action === 'unchanged')
+                return currentMessages;
+            // Same tail-preservation reuse as before, just scoped to
+            // priorPortion alone now — newMessages is appended back whole,
+            // always, regardless of how large it's grown this turn.
+            const preservedTailCount = Math.min(tailMessages, priorPortion.length);
+            const structuredTail = priorPortion.slice(priorPortion.length - preservedTailCount);
+            const newHead = result.messages.slice(0, result.messages.length - preservedTailCount);
+            const recovered = [...newHead, ...structuredTail, ...newMessages];
+            // Recovery.call() only ever returns {value, recoveries, truncated} —
+            // it never hands back whatever `currentMessages` became after a
+            // retry, so recovery would otherwise only ever affect the one
+            // retried call. Reassigning the outer `messages` binding here (this
+            // hook is the only place that has both the recovered array and a
+            // reason to persist it) is what makes recovery durable: every
+            // subsequent budgetTracker.check() in this loop, and the `history`
+            // this function eventually returns, both see the compacted
+            // conversation from this point on — not the original, ever-growing
+            // one. newMessages itself needs no reconciliation at all — it was
+            // never part of what could be compacted away.
+            messages = recovered;
+            return recovered;
+        },
+    });
+    pushMessage(starterMessage);
     let turn = 0;
     for (;;) {
         turn++;
@@ -460,6 +527,15 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
         const resultBlocks = [];
         const approvedCalls = [];
         const deniedTools = [];
+        // A DurableApprover/DurableQuestionHandler deferred this call to a
+        // durable record instead of resolving it inline (see
+        // HUMAN_IN_THE_LOOP.md) — collected separately from
+        // approvedCalls/deniedTools since it's neither run now nor denied now.
+        // No tool_result is pushed for these yet; the batch's post-loop
+        // handling below decides what happens to them. One shared array for
+        // both kinds (not two parallel ones) — see PendingItem's own doc
+        // comment for why a mixed batch has to share one checkpoint.
+        const pending = [];
         // Keyed by tool_use id — approvedCalls (a toollane LaneCall) has no
         // room for extra fields of its own, and toolLane.run's own results
         // only carry `id`/`name`/status, not anything about the *decision*
@@ -481,6 +557,38 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
                 resultBlocks.push({ type: 'tool_result', tool_use_id: block.id, content: body });
                 continue;
             }
+            // Checked before the systemToolInstances bypass just below (which
+            // would otherwise auto-run ask_user's own execute() straight away,
+            // in-process) — when the resolved QuestionHandler for this channel
+            // is durable (isDurableQuestionHandler — see its own doc comment,
+            // mirroring Gate's isDurableApprover), a system_ask_user call gets
+            // the exact same bucket-then-execute treatment a durably-gated tool
+            // call gets from gate.evaluate() below, never actually invoking the
+            // tool's own execute()/onPending live path at all. See PendingItem's
+            // own doc comment for why this shares `pending` with approvals
+            // rather than its own separate array. Identity, not name
+            // (`toolsByName.get(...) === askUserTool`, not `block.name ===
+            // 'system_ask_user'`) — same reasoning the systemToolInstances check
+            // just below already uses: an agent that deliberately overrode the
+            // name with its own ToolDefinition must still fall through to
+            // gate.evaluate() like any other tool, not get silently swallowed
+            // into the durable-question bucket just because the name happens to
+            // match. The *live* case (questionHandler resolved to something,
+            // just not durable — including the hard CliQuestionHandler default)
+            // deliberately falls through to the systemToolInstances bypass below
+            // unchanged — see RunAgentOptions.questionHandler's own doc comment
+            // for why that half isn't wired to this resolved value yet.
+            if (toolsByName.get(block.name) === askUserTool && isDurableQuestionHandler(questionHandler)) {
+                const question = String(block.input?.question ?? '');
+                const questionOptions = Array.isArray(block.input?.options) ? block.input.options.map(String) : undefined;
+                const { pendingId } = questionHandler.notifyPendingQuestion(question, questionOptions, scope.agent, sessionId);
+                // No 'tool:started'/'tool:result' here — same reasoning the
+                // durably-gated 'pending' branch below has: nothing to report
+                // until a resolve call answers it, later, possibly in a
+                // different process.
+                pending.push({ kind: 'question', toolUseId: block.id, tool: block.name, args: { question, options: questionOptions }, pendingId, reason: question });
+                continue;
+            }
             // See systemToolInstances' own doc comment above — bypasses
             // gate.evaluate entirely, not just auto-approves through it, since
             // ask_user itself can be the approver's own only way to ask a human
@@ -520,6 +628,15 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
                     execute: () => toolsByName.get(block.name).execute(block.input ?? {}),
                 });
             }
+            else if (decision.decision === 'pending') {
+                // No 'tool:started'/'tool:result' here — unlike a live 'ask',
+                // this call isn't running and isn't decided yet; it genuinely
+                // has nothing to report until a resolve call answers it, later,
+                // possibly in a different process. See 'loop:pending_approval'
+                // below (once every block in the batch is known) for the live
+                // signal this batch needed a durable decision.
+                pending.push({ kind: 'approval', toolUseId: block.id, tool: block.name, args: block.input ?? {}, pendingId: decision.pendingId, reason: decision.reason });
+            }
             else {
                 // Every requested tool gets exactly one tool_result back — a
                 // denied call is not simply dropped, or the model has no way to
@@ -569,6 +686,26 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
                 // just above.
                 log({ type: 'tool:result', id: call.id, tool: call.name, args: approvedMetaById.get(call.id)?.args, detailText: skipReason, statusText: 'Skipped.' });
             }
+            // A pending call/question closes exactly the same way an
+            // approved-but-never-run one does above — see HUMAN_IN_THE_LOOP.md's
+            // own "denial closes the checkpoint immediately" semantics: since
+            // this never actually becomes a checkpoint (the batch is resolved
+            // synchronously right here), there's nothing durable left dangling —
+            // only the DurableApprover's/DurableQuestionHandler's own pendingId
+            // record, orphaned but harmless: a resolve call against it later
+            // finds no checkpoint at all (never created) and no-ops, same as any
+            // other unknown pendingId.
+            for (const pendingItem of pending) {
+                log({ type: 'loop:skipped', name: pendingItem.tool, deniedTools });
+                const skipReason = `a sibling tool call in this turn (${deniedTools.join(', ')}) was denied`;
+                resultBlocks.push({
+                    type: 'tool_result',
+                    tool_use_id: pendingItem.toolUseId,
+                    content: `skipped: ${skipReason}`,
+                    is_error: true,
+                });
+                log({ type: 'tool:result', id: pendingItem.toolUseId, tool: pendingItem.tool, args: pendingItem.args, detailText: skipReason, statusText: 'Skipped.' });
+            }
         }
         else {
             // result.id is the same id LaneCall.id was given above — the exact
@@ -604,6 +741,30 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
                     statusText: result.status === 'fulfilled' ? 'Approved.' : 'Error.',
                 });
             }
+            // At least one call this batch is durably pending — resultBlocks is
+            // incomplete (missing an entry for every pending item) and must
+            // NOT be pushed as the completing tool_result message: a real model
+            // API expects exactly one, complete, tool_result per tool_use
+            // message, not a partial one now and a follow-up later. Stop here
+            // instead — newMessages already ends at the dangling assistant
+            // tool_use message pushed above, the same crash-recovery shape
+            // session-store.ts's own hasUnresolvedToolCall already detects (see
+            // RunAgentResult.stopReason's own doc comment). Turning this into a
+            // durable TurnCheckpoint is the caller's job — this loop does no I/O.
+            if (pending.length > 0) {
+                // A mixed batch (both kinds present) reports 'pending_approval' —
+                // see RunAgentResult.stopReason's own doc comment for why that's
+                // the right call, not an arbitrary tie-break.
+                const stopReason = pending.some((p) => p.kind === 'approval') ? 'pending_approval' : 'pending_question';
+                log({ type: stopReason === 'pending_question' ? 'loop:pending_question' : 'loop:pending_approval', pendingIds: pending.map((p) => p.pendingId) });
+                return {
+                    text: `Stopped — awaiting durable ${stopReason === 'pending_question' ? 'answer' : 'approval'} for: ${pending.map((p) => p.tool).join(', ')}.`,
+                    history: messages,
+                    newMessages,
+                    stopReason,
+                    pending: { resultsSoFar: resultBlocks, outstanding: pending },
+                };
+            }
         }
         pushMessage({ role: 'user', content: resultBlocks });
         // Stop here, don't loop back for another model call — same reasoning
@@ -620,3 +781,101 @@ export async function runAgent(config, modelCall, userMessage, history = [], opt
         }
     }
 }
+/** Invokes an AgentConfig.onRunStart/onRunFinish callback per its own
+ * never-awaited contract (see AgentConfig's own doc comments on each) —
+ * whether `call()` throws synchronously or returns a rejected Promise,
+ * the failure is logged, never surfaced to (or awaited by) the loop that
+ * triggered it. One shared implementation for both hooks and both of
+ * runAgent/resumeAgent's own call sites, rather than four copies of the
+ * same try/catch-and-maybe-.catch dance. */
+function fireLifecycleHook(label, agentName, call) {
+    try {
+        const result = call();
+        if (result && typeof result.catch === 'function') {
+            result.catch((err) => console.error(`[loopengine] ${label} threw for agent '${agentName}':`, err));
+        }
+    }
+    catch (err) {
+        console.error(`[loopengine] ${label} threw for agent '${agentName}':`, err);
+    }
+}
+/** `cli` and `http_stream` both already deliver the start/finish signal
+ * to whoever's actually waiting, synchronously, as part of that channel's
+ * own normal response — a terminal that just ran the command, or an SSE
+ * connection that already carries its own `session`/`done` events on the
+ * exact same stream. Firing onRunStart/onRunFinish there too would just
+ * be a second, redundant copy of information the caller already has, so
+ * neither hook is invoked for those two channels — not left to each
+ * implementation to notice and filter out itself the way `channel` in
+ * the fired context still lets you filter *within* the channels this
+ * does fire for (`http`, or no channel at all — a bespoke script has no
+ * such guaranteed synchronous delivery to assume either way, so it still
+ * fires there). */
+function shouldFireLifecycleHooks(channel) {
+    return channel !== 'cli' && channel !== 'http_stream';
+}
+export async function runAgent(config, modelCall, userMessage, history = [], options = {}) {
+    const ctx = await buildTurnContext(config, modelCall, options);
+    // config.onRunStart, if set, still wins outright over notifier's own
+    // derived hook — see NotifierConfig's own doc comment on precedence.
+    const onRunStart = config.onRunStart ?? (options.channel === 'http' ? ctx.httpNotifier.onRunStart : undefined);
+    if (onRunStart && shouldFireLifecycleHooks(options.channel)) {
+        fireLifecycleHook('onRunStart', config.name, () => onRunStart({ agent: config.name, tenant: ctx.scope.tenant, sessionId: options.sessionId, channel: options.channel, trigger: 'message' }));
+    }
+    const result = await runLoop(ctx, [...history], [], { role: 'user', content: userMessage });
+    const onRunFinish = config.onRunFinish ?? (options.channel === 'http' ? ctx.httpNotifier.onRunFinish : undefined);
+    if (onRunFinish && !result.pending && shouldFireLifecycleHooks(options.channel)) {
+        fireLifecycleHook('onRunFinish', config.name, () => onRunFinish({ agent: config.name, tenant: ctx.scope.tenant, sessionId: options.sessionId, channel: options.channel, text: result.text, stopReason: result.stopReason }));
+    }
+    return result;
+}
+/** Continues a turn durably paused on RunAgentResult.stopReason ===
+ * 'pending_approval' — see HUMAN_IN_THE_LOOP.md for the full design.
+ * `history` is durable session history including the dangling assistant
+ * tool_use message the pause left behind (exactly what a caller's
+ * SessionStore.getHistory/withSession already returns — this needs no
+ * special resumed-session handling, since that message is real, already
+ * on disk). `resolution` is the *complete* set of tool_result blocks
+ * answering that message — every entry from a resolved TurnCheckpoint's
+ * own resultsSoFar, once its outstanding is empty; assembling that is the
+ * caller's job (core/durable-approvals.ts's own CheckpointStore only
+ * stores it, it doesn't execute tools or know when a batch is complete —
+ * see that module's own doc comment), not something this function
+ * derives on its own.
+ *
+ * Pushes `resolution` as the completing message and picks the loop back
+ * up from there — a fresh model call, now with the full picture, exactly
+ * like a synchronous 'ask' would have continued if it hadn't needed to
+ * pause at all. Can itself return with stopReason 'pending_approval'
+ * again (the model's next round of tool calls hits another durably-gated
+ * one), 'denied', 'max_turns', or a genuine finish — runLoop handles all
+ * of those uniformly regardless of how this turn started. */
+export async function resumeAgent(config, modelCall, history, resolution, options = {}) {
+    const ctx = await buildTurnContext(config, modelCall, options);
+    const onRunStart = config.onRunStart ?? (options.channel === 'http' ? ctx.httpNotifier.onRunStart : undefined);
+    if (onRunStart && shouldFireLifecycleHooks(options.channel)) {
+        fireLifecycleHook('onRunStart', config.name, () => onRunStart({ agent: config.name, tenant: ctx.scope.tenant, sessionId: options.sessionId, channel: options.channel, trigger: 'resolution' }));
+    }
+    // sessions.withSession's own load (adapters/http.ts's respondAfterResolution)
+    // runs through the exact same hasUnresolvedToolCall check real crash
+    // recovery uses — a durable pause deliberately leaves the identical
+    // dangling-tool_use shape (see HUMAN_IN_THE_LOOP.md's own "same
+    // crash-recovery shape... entered on purpose"), so session-store.ts has
+    // no way to tell the two apart and injects its own synthetic
+    // CRASH_RECOVERY_CONTINUATION message regardless. Only resumeAgent
+    // itself knows, by the fact that it's being called at all with a real
+    // resolution in hand, that this wasn't a crash — so it's the only place
+    // that can safely strip that message back out before it ends up wedged
+    // between the assistant's tool_calls message and the tool_result
+    // answering it, which every OpenAI-wire-compatible provider rejects
+    // outright (an assistant message with tool_calls must be immediately
+    // followed by one tool message per call, nothing in between).
+    const lastMessage = history[history.length - 1];
+    const effectiveHistory = lastMessage?.role === 'user' && lastMessage.content === CRASH_RECOVERY_CONTINUATION ? history.slice(0, -1) : history;
+    const result = await runLoop(ctx, [...effectiveHistory], [], { role: 'user', content: resolution });
+    const onRunFinish = config.onRunFinish ?? (options.channel === 'http' ? ctx.httpNotifier.onRunFinish : undefined);
+    if (onRunFinish && !result.pending && shouldFireLifecycleHooks(options.channel)) {
+        fireLifecycleHook('onRunFinish', config.name, () => onRunFinish({ agent: config.name, tenant: ctx.scope.tenant, sessionId: options.sessionId, channel: options.channel, text: result.text, stopReason: result.stopReason }));
+    }
+    return result;
+}

package/dist/core/session-store.d.ts

@@ -42,6 +42,7 @@ export declare class KeyedMutex {
      * work across all keys has settled. */
     size(): number;
 }
+export declare const CRASH_RECOVERY_CONTINUATION = "[session resumed after an interruption \u2014 the assistant had requested tool calls but the process stopped before any results were recorded; treat those tools as not having run]";
 /** Wraps a SessionKnit log behind the flat load/run/append contract
  * runAgent's callers use. Shared by both the file- and Redis-backed
  * stores below — only the Storage and the lock differ. */

package/dist/core/session-store.js

@@ -75,11 +75,13 @@ function hasUnresolvedToolCall(message) {
         Array.isArray(message.content) &&
         message.content.some((block) => block.type === 'tool_use'));
 }
+// Exported so resumeAgent (run-agent.ts) can strip this exact message
+// back out when it turns out the "interruption" wasn't a crash at all —
+// see that constant's own doc comment for why the two can't be told
+// apart at the point sessionknit's own resume() runs.
+export const CRASH_RECOVERY_CONTINUATION = '[session resumed after an interruption — the assistant had requested tool calls but the process stopped before any results were recorded; treat those tools as not having run]';
 function buildContinuation() {
-    return {
-        role: 'user',
-        content: '[session resumed after an interruption — the assistant had requested tool calls but the process stopped before any results were recorded; treat those tools as not having run]',
-    };
+    return { role: 'user', content: CRASH_RECOVERY_CONTINUATION };
 }
 /** Wraps a SessionKnit log behind the flat load/run/append contract
  * runAgent's callers use. Shared by both the file- and Redis-backed

package/dist/core/system-skills/system-skills/composio-large-outputs/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: composio-large-outputs
+description: How to retrieve a gateway tool's real output when its result says storedInFile is true instead of returning the data inline.
+---
+
+# Gateway tools with a large result
+
+Some gateway tools (Composio-sourced ones in particular) return a small
+pointer object instead of their real output when the actual result is
+too large to return inline:
+
+```
+{
+  "successful": true,
+  "storedInFile": true,
+  "tokenCount": 10234,
+  "outputFilePath": "/tmp/.../SOME_TOOL_OUTPUT_xxxxx.json"
+}
+```
+
+When you see `storedInFile: true` in a tool result, the real data is
+**not** in that object — it's in the file at `outputFilePath`. Call
+`system_read_file` with that exact path to retrieve the actual content
+before answering. Don't guess at an answer, summarize from the pointer
+alone, or claim you don't have the data — read the file first.