@juno-ai/bind 14.0.0 → 15.0.0

package/README.md

@@ -35,6 +35,15 @@ constraints that will fail CI if you break them.
 
 **Added**
 
+- **Three loop ports for a host whose transcript is durable** —
+  `ToolLoopTurn.acceptMessage`, `ToolLoopParams.beforeToolMessageAccepted` and
+  `ToolLoopParams.onStepSettled` (plus `StepSettlement`,
+  `DiscardedTurnWithToolCallsError` and `InputBlockedBySuspendError`).
+  Together they let a host record each accepted message as the loop accepts
+  it, in the order it accepts it, and hand back messages it has committed.
+  All three are optional and unwired behaviour is unchanged. See "How to
+  commit a transcript as the loop builds it".
+
 - **`@juno-ai/bind/skills`** — progressive disclosure for *instructions*, the
   mirror of `@juno-ai/bind/plugins`. `createSkillRegistry` for what your source
   ships, `partitionSkillCatalog` for the Tier-1 catalog and its token budget,
@@ -831,6 +840,84 @@ represent faithfully — a `Map`, a `Set`, a class instance, `NaN`, a cycle —
 because a silent collision here reads as "same call" and skips a write that
 never happened.
 
+### How to commit a transcript as the loop builds it
+
+`state.messages` is an in-memory array. If your host persists each message as it
+lands — a Durable Object writing transitions, an event-sourced run that replays
+after eviction — you need three things the array alone cannot give you: the
+exact message at the moment it is accepted, its position among the results the
+batch actually produced, and a point where you can hand back input your users
+committed while the agent was working.
+
+```ts
+await runToolLoop({
+  // …
+  callModel: async (messages, tools) => {
+    const completion = await transport(messages, tools);
+    const empty = !completion.content.trim() && completion.toolCalls.length === 0;
+    if (empty) await settleReservation(turnId, "failed");
+    else await commit({ kind: "assistant_accepted", turnId, message: completion.message });
+    return { ...completion, acceptMessage: !empty };
+  },
+  beforeToolMessageAccepted: async (message, resultOrdinal) => {
+    // Throws → the message is NOT appended and the run fails.
+    await commit({ kind: "tool_result_accepted", message, resultOrdinal });
+  },
+  onStepSettled: async ({ wouldEnd }) => {
+    const pending = await claimCommittedInput({ wouldEnd });
+    return { messages: pending.messages, stop: pending.runWasCancelled };
+  },
+});
+```
+
+**`acceptMessage: false` keeps a turn out of the transcript without hiding what
+it cost.** The case is a tolerated empty completion: the provider returned
+nothing, your host has already settled the slot it reserved, and appending an
+empty assistant message would persist a turn that said nothing and re-send it on
+every later call. Tokens and cost are still folded into `stats` and `state`. The
+loop **refuses** the discard for a turn that requested tools — those results are
+about to be appended and would have no request to pair with — and reports the
+misuse through `onToolCallRejected` as a `DiscardedTurnWithToolCallsError`.
+
+**`resultOrdinal` is dense over accepted results.** It is not the call's index
+in `tool_calls`: an `answer`-suspend withholds its result, so the calls after it
+close the gap, and the answer takes the ordinal it is accepted at when it
+arrives. Reconstructing that order from `state.messages` afterwards is the one
+thing that goes wrong for exactly the batch that suspended.
+
+**`beforeToolMessageAccepted` covers results this loop produced, not messages
+you hand back.** A `tool` message you return from `onStepSettled` skips the
+port and takes no ordinal — you committed it before handing it over, so
+reporting it back would ask you to record the same thing twice.
+
+**A settled step is where input can join.** `onStepSettled` fires **at most
+once per iteration**, and `wouldEnd` says which of the two shapes that
+iteration took: `true` when the model asked for no tools (the run is about to
+end), `false` when the batch's results are all in the transcript. Anywhere
+else, an appended message lands between an assistant message and the results
+it is waiting on, which is a transcript providers reject. Returned messages
+are appended in order and the run continues; `stop` ends it as `aborted` with
+them already appended, and a throw propagates out of `runToolLoop`
+unconverted.
+
+Two behaviours worth knowing before you wire it:
+
+- At `wouldEnd: true`, `onStepSettled` runs **before** `onTurnWouldEnd`. Real
+  input outranks a nudge — a turn with more to answer was never stalled.
+- A returned `role:"tool"` message carrying an **open suspend's `tool_call_id`
+  clears the suspension**, so a host that already has the answer keeps going
+  instead of pausing for a reply it has been handed. A `wake`-suspend from
+  another call in the same batch still ends the run: the answer says nothing
+  about it.
+- **While a suspend is open, only `tool` messages are accepted.** A `user`
+  message delivered ahead of the answer is refused and reported as an
+  `InputBlockedBySuspendError`: appending it is how a resumed run ends up
+  sending `assistant(tool_calls) → user → tool`, which providers reject. Put
+  the answering result first in the array and the rest is accepted after it.
+- **`shouldStop` outranks delivered input.** The messages are kept — your host
+  committed them — and the run ends as `aborted` rather than making another
+  model call.
+
 ### How to stream tokens to a user without breaking fallback
 
 Three granularities reach you, and the third is the one with a retry problem.
@@ -1464,6 +1551,12 @@ what happens to the tool message:
 `request` is an opaque render/route payload, validated by the consumer and never
 inspected by the loop.
 
+An open `"answer"` suspend can also be resolved **within the same step**: a
+`role:"tool"` message returned from `onStepSettled` that carries the open call's
+`tool_call_id` clears the suspension and the run continues, for a host that
+already holds the reply. A `"wake"` suspend from another call in the same batch
+still ends the run — see "How to commit a transcript as the loop builds it".
+
 ---
 
 ## Usage scenarios

package/loop/index.d.ts

@@ -1,2 +1,2 @@
 export type { StopReason, RunStats } from "../contracts/turn.js";
-export { runToolLoop, MissingActivationPortError, type ToolLoopParams, type ToolLoopResult, type ToolLoopState, type ToolLoopTurn, type ToolCallOutcome, type CompactionApplied, type RunStatus, } from "./tool-loop.js";
+export { runToolLoop, MissingActivationPortError, DiscardedTurnWithToolCallsError, InputBlockedBySuspendError, type ToolLoopParams, type ToolLoopResult, type ToolLoopState, type ToolLoopTurn, type ToolCallOutcome, type StepSettlement, type CompactionApplied, type RunStatus, } from "./tool-loop.js";

package/loop/index.js

@@ -1 +1 @@
-export { runToolLoop, MissingActivationPortError, } from "./tool-loop.js";
+export { runToolLoop, MissingActivationPortError, DiscardedTurnWithToolCallsError, InputBlockedBySuspendError, } from "./tool-loop.js";

package/loop/tool-loop.d.ts

@@ -40,6 +40,30 @@ export interface ToolLoopTurn {
      * simply does not count this turn, rather than counting it as a zero.
      */
     cachedInputTokens?: number | null;
+    /**
+     * Set `false` to keep this completion OUT of the transcript while still
+     * accounting for what it cost. The turn happened — it is folded into
+     * `stats` and `state` either way — but `state.messages` never grows an
+     * assistant entry for it.
+     *
+     * The case it exists for is a **tolerated empty completion**: a provider
+     * answered with no text and no tool calls, the host decided that is a
+     * nothing rather than a failure, and the host had already reserved a
+     * transcript slot for the message it never got. Appending the empty
+     * assistant message would persist a turn saying nothing and re-send it on
+     * every later call; dropping it leaves the transcript exactly as the model
+     * found it, so the next turn is a clean retry of the same question.
+     *
+     * **Only a turn with no tool calls may be dropped.** Withholding a
+     * tool-calling assistant message orphans every `tool` result the batch is
+     * about to append, which is an invalid transcript the next model call
+     * rejects. The loop refuses that rather than building it — it reports the
+     * misuse through `onToolCallRejected` (one report per orphaned call, the
+     * same channel a missing activation port uses) and keeps the message.
+     *
+     * Defaults to accepting: omit it, or pass `true`, and nothing changes.
+     */
+    acceptMessage?: boolean;
 }
 /**
  * Outcome of running one tool call inside an assistant `tool_calls` batch.
@@ -155,6 +179,44 @@ export declare class MissingActivationPortError extends Error {
     readonly name = "MissingActivationPortError";
     constructor(port: "activatePlugins" | "activateSkills");
 }
+/**
+ * A turn returned `acceptMessage: false` while also requesting tools.
+ *
+ * Reported through `onToolCallRejected` rather than thrown, and the discard is
+ * refused rather than honoured: the tool calls are about to run, and a
+ * transcript carrying their results without the assistant message that asked
+ * for them is one the next provider call rejects outright. Keeping the message
+ * costs an assistant entry the host did not want; dropping it costs the run.
+ *
+ * Match on `error.name === "DiscardedTurnWithToolCallsError"` rather than
+ * `instanceof` — see {@link MissingActivationPortError} for why.
+ */
+export declare class DiscardedTurnWithToolCallsError extends Error {
+    readonly toolCallCount: number;
+    readonly name = "DiscardedTurnWithToolCallsError";
+    constructor(toolCallCount: number);
+}
+/**
+ * A settled step delivered a message that cannot be appended yet: a call is
+ * still awaiting its answer, and the provider rule is that nothing comes
+ * between an assistant message and the `tool` results it is waiting on.
+ *
+ * Appending it anyway builds `assistant(tool_calls) → user → tool` the moment
+ * the answer is threaded back on resume, which providers reject outright — so
+ * the message is refused and reported (through `onToolCallRejected`, against
+ * the open call) rather than silently corrupting the transcript. Deliver the
+ * answering `tool` result first, in the same settlement, and everything after
+ * it is accepted normally.
+ *
+ * Match on `error.name === "InputBlockedBySuspendError"` rather than
+ * `instanceof` — see {@link MissingActivationPortError} for why.
+ */
+export declare class InputBlockedBySuspendError extends Error {
+    readonly openToolCallId: string;
+    readonly refusedRole: string;
+    readonly name = "InputBlockedBySuspendError";
+    constructor(openToolCallId: string, refusedRole: string);
+}
 /**
  * What a completed loop reports back.
  *
@@ -198,6 +260,17 @@ export interface ToolLoopResult {
      */
     readonly stats: RunStats;
 }
+/**
+ * What a host hands back from {@link ToolLoopParams.onStepSettled}: the
+ * messages to append at this settled step, and whether the run should end
+ * after appending them.
+ */
+export interface StepSettlement {
+    /** Appended to the transcript in this order. Empty means "nothing queued". */
+    messages: OpenAI.ChatCompletionMessageParam[];
+    /** End the run as `aborted` once the messages above are appended. */
+    stop: boolean;
+}
 export interface ToolLoopParams {
     state: ToolLoopState;
     /**
@@ -217,6 +290,90 @@ export interface ToolLoopParams {
     buildTools: () => OpenAI.ChatCompletionTool[];
     /** Execute one tool call → the `tool` message + control signals. */
     runToolCall: (toolCall: OpenAI.ChatCompletionMessageToolCall) => Promise<ToolCallOutcome>;
+    /**
+     * Record the exact `tool` message the loop is about to append, immediately
+     * before it appends it. For a host that persists the transcript as it is
+     * built, this is the only point where "what was accepted" and "what was
+     * recorded" cannot drift: a batch's outcomes are produced concurrently and
+     * an `answer`-suspend withholds one of them, so a host reconstructing the
+     * accepted set afterwards has to re-derive a decision the loop already made.
+     *
+     * `resultOrdinal` counts **accepted results in this batch, densely from 0**
+     * — not the call's index in `tool_calls`. A withheld suspend leaves no
+     * ordinal behind, so the results that follow it close the gap, and the
+     * answer that arrives later takes the ordinal it is accepted at rather than
+     * the one its call was issued at. Ordering within the batch is otherwise
+     * the model's original call order.
+     *
+     * **A throw aborts acceptance**: the message is not appended and the error
+     * propagates out of `runToolLoop`, unconverted. That is deliberate — this
+     * port exists for hosts that must record a result durably before the model
+     * may see it, and a host that cannot record one must not be handed a
+     * transcript claiming it did. Wire `isFatalToolError` the same way for the
+     * dispatch half of that rule.
+     *
+     * **Scope: results this loop produced.** A `tool` message the host itself
+     * returns from `onStepSettled` does not fire this port and takes no ordinal
+     * — the host committed that message before handing it over, so reporting it
+     * back would ask for a second record of the same thing. `resultOrdinal` is
+     * therefore a position within the batch, and a host that journals both
+     * sources keys them by where they came from rather than by one counter.
+     */
+    beforeToolMessageAccepted?: (message: OpenAI.ChatCompletionToolMessageParam, resultOrdinal: number) => Promise<void> | void;
+    /**
+     * Deliver host-committed messages at a **settled step** — a point where the
+     * model turn and its whole tool batch are complete and the transcript is
+     * coherent, so appending a `user` (or a withheld `tool`) message cannot
+     * split an assistant message from the results it is waiting on.
+     *
+     * Called **at most once per iteration** — the two points below are the two
+     * shapes an iteration can take, not two calls in one — and `wouldEnd` says
+     * which one this is:
+     *
+     *  - **`wouldEnd: true`** — the model asked for no tools and the loop is
+     *    about to finish. Returning messages CONTINUES the run with them
+     *    appended, ahead of `onTurnWouldEnd` (a host that has real input queued
+     *    delivers it rather than nudging a turn that was not actually stalled).
+     *  - **`wouldEnd: false`** — the batch ran and its results are in the
+     *    transcript. Returning messages appends them before the next model call.
+     *
+     * Return `stop: true` to end the run as `aborted`, with whatever messages
+     * came back already appended. Returning `{ messages: [], stop: false }` —
+     * or leaving the port unwired — changes nothing.
+     *
+     * **A delivered `tool` message answers an open suspend.** If the run is
+     * waiting on an `answer`-suspend and a returned message carries that call's
+     * `tool_call_id`, the loop clears the suspension and keeps going rather than
+     * pausing for a reply it has just been handed. It still ends the run if some
+     * *other* call in the same batch asked for a `wake`-suspend, which is a
+     * separate request that a delivered answer says nothing about.
+     *
+     * **While a suspend is open, only `tool` messages are accepted.** Nothing
+     * may come between an assistant message and the results it is waiting on, so
+     * a `user` message delivered ahead of the answer is refused and reported as
+     * an {@link InputBlockedBySuspendError} — appending it is how a resumed run
+     * ends up sending `assistant(tool_calls) → user → tool`, which providers
+     * reject. Return the answering result first and the rest is accepted after
+     * it, in order.
+     *
+     * **A host that asked to stop still stops.** Delivered input says the turn
+     * is not over; `shouldStop` says the run is, and the run wins — the messages
+     * are kept and the loop ends as `aborted` rather than paying for another
+     * model call.
+     *
+     * Messages are otherwise appended in the order returned, and the loop does
+     * not validate them further: this is the host's transcript, committed on the
+     * host's side, arriving at the one place the loop can take it.
+     *
+     * **A throw propagates out of `runToolLoop` unconverted**, like
+     * `beforeToolMessageAccepted` and for the same reason: a host that cannot
+     * say what it has committed cannot be told the run went on without it.
+     */
+    onStepSettled?: (step: {
+        assistantMessage: OpenAI.ChatCompletionMessage;
+        cumulativeToolCalls: number;
+        wouldEnd: boolean;
+    }) => StepSettlement | Promise<StepSettlement>;
     /**
      * Activate newly loaded plugins (mutate the catalog/active set). Optional:
      * a host with a fixed tool surface has nothing to activate, and requiring an

package/loop/tool-loop.js

@@ -29,6 +29,56 @@ export class MissingActivationPortError extends Error {
         this.port = port;
     }
 }
+/**
+ * A turn returned `acceptMessage: false` while also requesting tools.
+ *
+ * Reported through `onToolCallRejected` rather than thrown, and the discard is
+ * refused rather than honoured: the tool calls are about to run, and a
+ * transcript carrying their results without the assistant message that asked
+ * for them is one the next provider call rejects outright. Keeping the message
+ * costs an assistant entry the host did not want; dropping it costs the run.
+ *
+ * Match on `error.name === "DiscardedTurnWithToolCallsError"` rather than
+ * `instanceof` — see {@link MissingActivationPortError} for why.
+ */
+export class DiscardedTurnWithToolCallsError extends Error {
+    toolCallCount;
+    name = "DiscardedTurnWithToolCallsError";
+    constructor(toolCallCount) {
+        super(`A turn asked the loop to drop its assistant message, but the message ` +
+            `requests ${toolCallCount} tool call(s) whose results would be left ` +
+            `unpaired. The message was kept. Only a tool-less turn may be dropped.`);
+        this.toolCallCount = toolCallCount;
+    }
+}
+/**
+ * A settled step delivered a message that cannot be appended yet: a call is
+ * still awaiting its answer, and the provider rule is that nothing comes
+ * between an assistant message and the `tool` results it is waiting on.
+ *
+ * Appending it anyway builds `assistant(tool_calls) → user → tool` the moment
+ * the answer is threaded back on resume, which providers reject outright — so
+ * the message is refused and reported (through `onToolCallRejected`, against
+ * the open call) rather than silently corrupting the transcript. Deliver the
+ * answering `tool` result first, in the same settlement, and everything after
+ * it is accepted normally.
+ *
+ * Match on `error.name === "InputBlockedBySuspendError"` rather than
+ * `instanceof` — see {@link MissingActivationPortError} for why.
+ */
+export class InputBlockedBySuspendError extends Error {
+    openToolCallId;
+    refusedRole;
+    name = "InputBlockedBySuspendError";
+    constructor(openToolCallId, refusedRole) {
+        super(`A settled step delivered a \`${refusedRole}\` message while tool call ` +
+            `${openToolCallId} is still awaiting its answer. It was refused: the ` +
+            `answer has to reach the transcript first, or the resumed run sends ` +
+            `a \`tool\` result the message has already split from its call.`);
+        this.openToolCallId = openToolCallId;
+        this.refusedRole = refusedRole;
+    }
+}
 /**
  * The key a tool call is measured under in {@link RunStats.toolTimeBreakdownMs}.
  *
@@ -67,7 +117,7 @@ function toolCallStatsKey(tc) {
  * run's conclusion, which only exists once the loop is over.
  */
 export async function runToolLoop(params) {
-    const { state, maxIterations, callModel, buildTools, runToolCall, activatePlugins, activateSkills, now = Date.now, ensureNotCancelled, throwIfTimedOut, onStatus, signal, onThinking, onAssistantMessage, flushProgress, onProgressUpdate, shouldStop, onTurnWouldEnd, drainInterrupts, onInterruptReceived, needsCompaction, applyCompaction, runsSerially, isFatalToolError, onToolCallRejected, } = params;
+    const { state, maxIterations, callModel, buildTools, runToolCall, activatePlugins, activateSkills, now = Date.now, ensureNotCancelled, throwIfTimedOut, onStatus, signal, onThinking, onAssistantMessage, flushProgress, onProgressUpdate, shouldStop, onTurnWouldEnd, drainInterrupts, onInterruptReceived, needsCompaction, applyCompaction, runsSerially, isFatalToolError, onToolCallRejected, beforeToolMessageAccepted, onStepSettled, } = params;
     let stats = emptyRunStats();
     // The default is the outcome of falling out of the `for` — every other exit
     // assigns before it breaks. Seeding it here rather than at each `break` means
@@ -116,6 +166,55 @@ export async function runToolLoop(params) {
             // Nothing useful to do — the reporting channel is the thing that broke.
         }
     };
+    // Ask the host what it has committed for this settled step. Unwired, the
+    // answer is "nothing, keep going" — the one shape every call site below
+    // reads, so neither of them branches on whether the port exists.
+    const settleStep = async (assistantMessage, wouldEnd) => {
+        const settlement = await onStepSettled?.({
+            assistantMessage,
+            cumulativeToolCalls: state.toolCalls,
+            wouldEnd,
+        });
+        // Read field by field rather than trusting the object whole: the types say
+        // both are present, and a JavaScript host (this package is published, and
+        // was reimplemented once already as a patch) that returns `{ stop: true }`
+        // would otherwise crash the run inside the loop rather than stop it.
+        return {
+            messages: settlement?.messages ?? [],
+            stop: settlement?.stop === true,
+        };
+    };
+    // Append a settlement's messages, honouring the one ordering rule an open
+    // `answer`-suspend imposes: until that call has its result, nothing else may
+    // come between it and the assistant message that asked for it. A delivered
+    // result for the open call clears the pause (the answer arrived in the same
+    // breath as the question); anything that is not a `tool` message is refused
+    // while the pause is open, because appending it is how a resumed run ends up
+    // sending `assistant(tool_calls) → user → tool`.
+    //
+    // Shared by both settle sites rather than living in the batch arm alone: a
+    // caller may seed `state.suspended` when it resumes a run, and the rule is
+    // about the transcript, not about which branch produced it.
+    const applySettledMessages = (messages) => {
+        let appended = 0;
+        let answeredSuspend = false;
+        for (const message of messages) {
+            const openSuspension = state.suspended;
+            if (openSuspension) {
+                if (message.role !== "tool") {
+                    reportRejection(openSuspension.toolCallId, new InputBlockedBySuspendError(openSuspension.toolCallId, message.role));
+                    continue;
+                }
+                if (message.tool_call_id === openSuspension.toolCallId) {
+                    state.suspended = undefined;
+                    answeredSuspend = true;
+                }
+            }
+            state.messages.push(message);
+            appended += 1;
+        }
+        return { appended, answeredSuspend };
+    };
     // Swap in a freshly-compacted transcript and reset the live counts. The
     // provider count no longer reflects the compacted array, so drop it — the
     // auto-compaction check skips while it's 0 (preventing an immediate
@@ -209,7 +308,20 @@ export async function runToolLoop(params) {
         state.lastOutputTokens = result.outputTokens;
         state.hasFreshTokenCount = true;
         const assistantMessage = result.message;
-        state.messages.push(assistantMessage);
+        // `acceptMessage: false` keeps a tolerated empty completion out of the
+        // transcript — the turn is still accounted for above. Refused for a
+        // tool-calling turn: the batch below appends results, and results whose
+        // request is missing are a transcript the next provider call rejects.
+        const requestedToolCalls = assistantMessage.tool_calls ?? [];
+        if (result.acceptMessage === false && requestedToolCalls.length > 0) {
+            const misuse = new DiscardedTurnWithToolCallsError(requestedToolCalls.length);
+            for (const tc of requestedToolCalls) {
+                reportRejection(tc.id, misuse);
+            }
+        }
+        if (result.acceptMessage !== false || requestedToolCalls.length > 0) {
+            state.messages.push(assistantMessage);
+        }
         if (assistantMessage.content && assistantMessage.tool_calls?.length) {
             onThinking?.(assistantMessage.content);
         }
@@ -244,6 +356,32 @@ export async function runToolLoop(params) {
             state.toolCalls += toolCalls.length;
         onProgressUpdate?.(state.outputTokens, state.toolCalls);
         if (!toolCalls || toolCalls.length === 0) {
+            // The step is settled: no batch to run, so the transcript is coherent
+            // right here. Ask the host for anything it has committed since the turn
+            // began — real input outranks a nudge, so this runs BEFORE
+            // `onTurnWouldEnd`. A host that delivers a message is saying the turn is
+            // not over, so the loop continues with it appended rather than asking
+            // whether a turn that has more to answer looked stalled.
+            const settlement = await settleStep(assistantMessage, true);
+            const settledInput = applySettledMessages(settlement.messages);
+            if (settlement.stop) {
+                stopReason = "aborted";
+                break;
+            }
+            if (settledInput.appended > 0) {
+                // Delivered input says the turn is not over; a host that asked to stop
+                // says the RUN is. The stop wins, exactly as it does over a nudge
+                // below — otherwise `shouldStop` ("stop after the current turn") pays
+                // for another model call and answers after it was cancelled. The
+                // messages stay: the host committed them, and dropping them here would
+                // leave its ledger and this transcript disagreeing.
+                if (stopRequested) {
+                    onProgressUpdate?.(state.outputTokens, state.toolCalls);
+                    stopReason = "aborted";
+                    break;
+                }
+                continue;
+            }
             // The model stopped calling tools — normally the turn is done. Give a
             // caller a chance to push it forward instead: if `onTurnWouldEnd` returns
             // text, inject it as a synthetic user message and keep looping. The hook
@@ -398,6 +536,17 @@ export async function runToolLoop(params) {
         }
         let compactionRequested = false;
         let suspendRequested = false;
+        // Dense over ACCEPTED results, so a withheld suspend leaves no gap — see
+        // `beforeToolMessageAccepted`. Reset per batch: it is a position within
+        // this step, not a running total.
+        let acceptedResultOrdinal = 0;
+        const acceptToolMessage = async (message) => {
+            // A throw propagates: a host that could not record the result must not
+            // be handed a transcript that says the model already saw it.
+            await beforeToolMessageAccepted?.(message, acceptedResultOrdinal);
+            state.messages.push(message);
+            acceptedResultOrdinal += 1;
+        };
         for (const outcome of outcomes) {
             // An `answer`-suspend WITHHOLDS its tool message — the result is the
             // future answer, threaded back on resume. At most one may be open: the
@@ -412,6 +561,14 @@ export async function runToolLoop(params) {
                         // Rebuild with the literal "answer" kind so the assignment matches
                         // `ToolLoopState.suspended` (always answer — see its type).
                         state.suspended = { ...outcome.suspend, resumeKind: "answer" };
+                        // The message is withheld; the call's OTHER signals are not. A
+                        // compaction asked for by the same outcome is skipped while the
+                        // pause is open (the arm below checks `state.suspended`) and runs
+                        // if a same-step answer clears it — whereas dropping the flag here
+                        // loses it for good, which is only invisible while an answered
+                        // suspend could not continue the run.
+                        if (outcome.requestCompaction)
+                            compactionRequested = true;
                         continue; // withhold this call's tool message
                     }
                     // Through the shared encoder, and carrying a `kind`, like every
@@ -420,7 +577,7 @@ export async function runToolLoop(params) {
                     // in one transcript — the exact thing `toolResultMessage` exists to
                     // prevent. `conflict` because it is a concurrency loss: the call was
                     // refused only because another question is already open.
-                    state.messages.push(toolResultMessage(outcome.suspend.toolCallId, {
+                    await acceptToolMessage(toolResultMessage(outcome.suspend.toolCallId, {
                         success: false,
                         kind: "conflict",
                         error: "This question was not asked — you already have one waiting " +
@@ -433,7 +590,7 @@ export async function runToolLoop(params) {
                 // `wake` (e.g. sleep_until): fall through and push the tool message, then
                 // end the run — it re-enters via a prompt, not a threaded answer.
             }
-            state.messages.push(outcome.toolMessage);
+            await acceptToolMessage(outcome.toolMessage);
             if (outcome.requestCompaction)
                 compactionRequested = true;
         }
@@ -469,6 +626,23 @@ export async function runToolLoop(params) {
             stopReason = "aborted";
             break;
         }
+        // The step is settled: every result the batch produced is in the
+        // transcript and nothing is half-applied, so this is where host-committed
+        // input can join without splitting a call from its result.
+        const settlement = await settleStep(assistantMessage, false);
+        const settledInput = applySettledMessages(settlement.messages);
+        // The answer arrived in the same breath as the question, so the run is no
+        // longer waiting on a person. A `wake`-suspend from another call in the
+        // same batch is a separate request the answer says nothing about, so it
+        // still ends the run — recomputed from the outcomes rather than left set,
+        // because `suspendRequested` is true for the answered call too.
+        if (settledInput.answeredSuspend) {
+            suspendRequested = outcomes.some((outcome) => outcome.suspend?.resumeKind === "wake");
+        }
+        if (settlement.stop) {
+            stopReason = "aborted";
+            break;
+        }
         // A tool asked to end the run (it scheduled its own resume, or recorded an
         // open call awaiting an answer). The tool results are already in
         // state.messages above; stop now so the run doesn't keep going. Mark it as

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juno-ai/bind",
-  "version": "14.0.0",
+  "version": "15.0.0",
   "description": "Agent harness: the tool-calling turn kernel, deterministic LLM provider routing with transport-error classification, the streaming-completion watchdog, run mechanics, sub-agent lineage and admission, transcript healing, tool-schema sanitization, the plugin/tool vocabulary, and the skill vocabulary (`./skills`) for progressive knowledge disclosure. MIT-licensed; published to npm from the canonical repo via scripts/publish-bind.ts (docs/bind.md).",
   "license": "MIT",
   "type": "module",