@juno-ai/bind 3.0.0 → 4.0.0

package/README.md

@@ -36,7 +36,8 @@ is; you do not need it to use the package.*
 
 ### What a harness is, and what it is not
 
-A harness owns the parts of an agent loop that are the same for everyone:
+A harness owns the parts of an agent loop that are the same for everyone: the
+iteration itself — call the model, run what it asked for, repeat — plus
 deciding which provider to call and what to do when it fails, bounding a run in
 wall-clock time, keeping a transcript in a shape providers accept, rewriting
 tool schemas that strict validators reject, and tracking which tools are
@@ -106,8 +107,15 @@ losing it.
 Transports' request construction and wire-error classification, credentials and
 environment parsing, your routing policy configuration, billing accounting
 (persistence and charging), inference logging, authorization, prompt rendering,
-and run orchestration — the queue a run is scheduled on, and any child runs it
-spawns (see [Spawning child runs](#spawning-child-runs-sub-agents)).
+and run orchestration — the queue a run is scheduled on, and the enqueuing and
+storage behind any child runs it spawns. The harness decides whether a child is
+*allowed*; putting it on a queue is yours (see
+[Spawning child runs](#spawning-child-runs-sub-agents)).
+
+The loop is here, but the **driver** around it is not: starting a run, recording
+what it did, delivering its output, and deciding when to run it again. That is
+where a runtime's identity, storage, and product behaviour live, and it is why
+`runToolLoop` takes a dozen observers instead of doing any of it.
 
 ---
 
@@ -246,6 +254,93 @@ progressive tool disclosure with
 *Goal-oriented. Each answers one question and assumes you know roughly what you
 are doing.*
 
+### How to run the loop
+
+`runToolLoop` is the engine: it calls the model, runs the tools the model asks
+for, and repeats until the model stops asking, a tool suspends the run, a caller
+stops it, or `maxIterations` is reached. Everything that *happens* as a result is
+a callback you supply.
+
+```ts
+import { runToolLoop, type ToolLoopState } from "@juno-ai/bind/loop";
+
+const state: ToolLoopState = {
+  messages: [systemMessage, userMessage],
+  inputTokens: 0,
+  outputTokens: 0,
+  costCents: 0,
+  lastPromptTokens: 0,
+  lastOutputTokens: 0,
+  hasFreshTokenCount: false,
+  toolCalls: 0,
+};
+
+await runToolLoop({
+  state,
+  activePlugins,
+  maxIterations: 30,
+
+  callModel: (messages, tools) => llm.complete({ messages, tools }),
+  buildTools: () => registry.toolDefinitions([...activePlugins]),
+  runToolCall: (call) => dispatch(call),
+  activatePlugins: (names) => names.forEach((n) => activePlugins.add(n)),
+  activateSkills: (refs) => loadInstructions(refs),
+});
+
+// `state` is mutated in place — read totals off it after, or mid-run from a
+// heartbeat.
+console.log(state.inputTokens, state.outputTokens, state.toolCalls);
+```
+
+`state` is mutated rather than returned so a heartbeat can read live totals while
+the run is still going; a returned result could not report anything until the
+run ended.
+
+### How to make a tool take effect mid-batch
+
+A model can request several tools at once, and one of them may change what the
+others can do — activating a plugin, loading an instruction module. Those must
+run first, alone, or a dependent call in the same batch executes against the old
+tool surface.
+
+```ts
+runsSerially: (call) =>
+  call.type === "function" && ACTIVATION_TOOLS.has(call.function.name),
+```
+
+The loop runs those one at a time, applies each outcome immediately, then fans
+the rest out concurrently (pooled per tool name). Outcomes are reassembled in the
+model's original order either way — every `tool_call_id` gets its answer in the
+sequence the provider expects.
+
+Unwired, nothing is serial. That is correct for a host whose tools do not reshape
+the tool surface, and wrong the moment one does.
+
+### How to decide which tool failures kill the run
+
+By default a thrown tool becomes a tool error the model can read and recover
+from, which is what you want for an isolated failure. Two kinds are not that:
+
+```ts
+isFatalToolError: (error) =>
+  error instanceof RunCancelledError ||   // must abort, not be answered
+  error instanceof PersistenceError,      // we could not RECORD the outcome
+```
+
+Cancellation has to propagate even when no `ensureNotCancelled` observer is
+wired. A persistence failure matters for a subtler reason: synthesizing "the tool
+failed" over a write you could not record tells the model a lie about work that
+may well have happened.
+
+Everything not fatal is answered and observed:
+
+```ts
+onToolCallRejected: (toolCallId, error) => log.warn("tool rejected", { toolCallId, error }),
+```
+
+Wire it. The model sees these failures either way; without the observer, nothing
+else does.
+
 ### How to pin a model to one provider
 
 Use a hard `only` fence. Plan-time filtering and runtime traversal both respect
@@ -428,8 +523,9 @@ keeps a consumer who only wants routing from pulling in the rest.
 | Import | Owns | Reach for it when |
 |---|---|---|
 | `@juno-ai/bind/routing` | Route plans, the planner, the failure taxonomy, the plan executor, the circuit breaker, billing-basis arithmetic, config degradation | You call more than one provider or model, or you want retries and fallback governed by one table |
-| `@juno-ai/bind/contracts` | Turn vocabulary — `TurnFn`, `ModelTurnResult`, `StopReason`, `RunStats` | You want one seam between your loop and any LLM client, and comparable per-run metrics |
-| `@juno-ai/bind/run` | Wall-clock deadline, failure classification, coalesced heartbeat, tool-batch pooling | A run must be bounded, observable, and able to say *why* it stopped |
+| `@juno-ai/bind/contracts` | Turn vocabulary — `TurnFn`, `ModelTurnResult`, `StopReason`, `RunStats` and its folds | You want one seam between your loop and any LLM client, and comparable per-run metrics |
+| `@juno-ai/bind/loop` | `runToolLoop` — the iteration engine: model turn, two-phase tool batch, activation, compaction, interrupts, suspend | You want the agent loop itself, not just the pieces to build one |
+| `@juno-ai/bind/run` | Wall-clock deadline, failure classification, coalesced heartbeat, tool-batch pooling, child-run lineage and admission, poll backoff | A run must be bounded, observable, and able to say *why* it stopped — or it can spawn runs of its own |
 | `@juno-ai/bind/transcript` | `validateAndHealMessages` | You send transcripts to more than one provider, or you build them across turns |
 | `@juno-ai/bind/tools` | `sanitizeToolSchema` | Any tool schema reaches a provider — especially third-party ones |
 | `@juno-ai/bind/plugins` | Tool/plugin vocabulary, the registry factory, progressive-disclosure activation | You have more tools than fit comfortably in one prompt |
@@ -462,6 +558,20 @@ tenant's revoked key opens the circuit for every tenant sharing that
 60 s ceiling including `Retry-After` extensions. Resolve a half-open probe that
 ended without a recordable outcome via `releaseProbe`, or the slot sticks.
 
+**Run — a child is admitted before it exists, never after.** `admitChildRun`
+judges counts you supply; call it ahead of enqueuing. A chain bounded only once
+its runs are on the queue is not bounded, it is billed. A rule whose measurement
+is `NaN` or `Infinity` refuses rather than admits — every comparison is false
+against `NaN`, so the naive reading of a broken count is an unbounded chain.
+
+**Run — chain lineage is "null means me".** A root run's `rootRunId` and
+`parentRunId` are both `null`, because a chain's origin has no id to point at
+until its own row exists. Read any chain's root as `chain.rootRunId ?? runId`;
+`descendChain` does that when it hands the id down, so every descendant carries
+a concrete root. Adopting the parent's id at *every* level instead makes each
+generation a fresh chain, and every per-chain bound then counts the wrong set
+and silently never fires.
+
 **Run — whoever classifies the outcome owns the deadline.** `timedOut` reflects
 *that* deadline firing, and stays false when only a combined external signal
 aborts — which is what separates a timeout from a cancellation. Handle
@@ -865,14 +975,13 @@ try {
 
 ### Spawning child runs (sub-agents)
 
-> **Not in the harness yet.** There is no sub-agent, spawn, or child-run concept
-> in `bind` today — the vocabulary below is yours to define. The admission
-> policy is a planned addition; see [Roadmap](#roadmap).
-
 A sub-agent is not a special kind of thing. It is **a run that another run
 asked for**, so everything the harness already gives a run applies unchanged:
 its own deadline, its own heartbeat, its own `RunStats`, its own route plan.
-Only three things are genuinely new, and all three are currently yours.
+Three things are genuinely new — lineage, admission, and waiting — and
+`@juno-ai/bind/run` owns the decision in each. It owns none of the measuring:
+counting runs in a chain needs your database, and judging whether a count is
+too high does not.
 
 **1. The spawn tool is an ordinary plugin.** Nothing special is needed here —
 the tool vocabulary is already shared.
@@ -892,10 +1001,10 @@ const orchestration: ToolPlugin<Ctx> = {
   async execute(toolName, args, ctx) {
     const { objective, plugins } = spawnArgsSchema.parse(args);
 
-    const admission = await admitChildRun(
-      { depth: ctx.chainDepth, chainId: ctx.chainId, parentKey: ctx.runKey },
-      BOUNDS,
-    );
+    const admission = admitChildRun([
+      { kind: "depth", parentDepth: ctx.chain.depth, maxDepth: 5 },
+      { kind: "chain_budget", runsInChain: await countRuns(ctx.chain), maxRuns: 50 },
+    ]);
     if (!admission.admitted) {
       return { success: false, kind: "validation", error: admission.reason };
     }
@@ -903,9 +1012,7 @@ const orchestration: ToolPlugin<Ctx> = {
     const childRunId = await queue.enqueueRun({
       objective,
       plugins,
-      chainId: ctx.chainId,
-      depth: ctx.chainDepth + 1,
-      parentRunId: ctx.runId,
+      chain: descendChain(ctx.runId, ctx.chain),
     });
     return { success: true, data: { childRunId } };
   },
@@ -914,34 +1021,47 @@ const orchestration: ToolPlugin<Ctx> = {
 
 **2. Admission is the part worth getting right.** An agent that can spawn can
 spawn agents that spawn. Bound it *before* enqueuing, not after — an unbounded
-chain is a runaway spend, and the failure mode is silent. The counting needs
-your database; the deciding does not.
+chain is a runaway spend, and the failure mode is silent.
 
-```ts
-type Admission = { admitted: true } | { admitted: false; reason: string };
+Each rule carries its limit **and** the measurement it judges, so a bound you
+configure but never wired a count for is not expressible. That shape exists
+because the alternative fails quietly: a bounds object beside a facts object
+lets a limit sit in config and never fire, and nothing looks wrong.
 
-async function admitChildRun(chain: Chain, bounds: Bounds): Promise<Admission> {
-  if (chain.depth >= bounds.maxDepth) {
-    return { admitted: false, reason: `chain depth limit reached (${chain.depth}/${bounds.maxDepth})` };
-  }
-  if (await countRunsInChain(chain.chainId) >= bounds.maxRunsPerChain) {
-    return { admitted: false, reason: "chain run budget exhausted" };
-  }
-  if (Date.now() - (await lastSpawnBetween(chain.parentKey)) < bounds.pairCooldownMs) {
-    return { admitted: false, reason: "spawn cooldown active" };
-  }
-  return { admitted: true };
+```ts
+import { admitChildRun, descendChain, type ChainRule } from "@juno-ai/bind/run";
+
+const rules: ChainRule[] = [
+  { kind: "depth", parentDepth: chain.depth, maxDepth: 5 },
+  { kind: "chain_budget", runsInChain: await countRunsInChain(chain), maxRuns: 50 },
+  { kind: "pair_cooldown", msSinceLastSpawn: await msSinceLastSpawn(runId), cooldownMs: 30_000 },
+  { kind: "tenant_ceiling", activeRuns: await countActiveRuns(tenantId), maxActiveRuns: 200 },
+];
+
+const admission = admitChildRun(rules);
+if (!admission.admitted) {
+  log.warn("child run refused", { rule: admission.rule });
+  return { success: false, kind: "validation", error: admission.reason };
 }
 ```
 
-Pick bounds against your own cost model. Depth caps runaway recursion; a
-per-chain run budget caps total spend once a chain starts; a pair cooldown stops
-two agents ping-ponging. A separate per-tenant ceiling on *directly triggered*
-runs is worth having too — depth limits do not constrain someone starting a
-thousand independent runs.
+Rules are evaluated in order and the first refusal wins, so you choose which
+reason the model sees. Pick the set against your own cost model: depth caps
+runaway recursion, a chain budget caps a chain that stays shallow but keeps
+fanning out, a pair cooldown stops two runs ping-ponging, and a tenant ceiling
+covers what none of the chain rules can — someone starting a thousand
+independent chains. A broken measurement (`NaN`, `Infinity`) refuses rather
+than admits: every comparison is false against `NaN`, so the naive reading
+would turn a broken count into an unbounded chain.
 
-**3. Waiting, and rolling results up.** Two shapes work. Suspend the parent and
-let child completion wake it, which frees the worker slot:
+`descendChain` handles the lineage arithmetic, including the root-id fallback
+that is easy to get backwards — a first-generation child adopts its parent's
+*id* as the chain root, later generations keep the root the parent already
+carries. Getting that wrong makes every generation its own chain, and every
+per-chain bound then counts the wrong set and never fires.
+
+**3. Waiting.** Two shapes work. Suspend the parent and let child completion
+wake it, which frees the worker slot:
 
 ```ts
 return {
@@ -952,27 +1072,51 @@ return {
 ```
 
 …or poll inside the tool, which keeps the parent's transcript intact but holds
-its slot — so cap the poll well under the parent's deadline.
+its slot — so budget the poll well under the parent's own deadline.
+`createPollSchedule` is a doubling backoff bounded by that budget; it clamps
+the final delay so a sleep can never overshoot the deadline you promised.
+
+```ts
+import { createPollSchedule } from "@juno-ai/bind/run";
+
+const startedAt = Date.now();
+const poll = createPollSchedule({
+  initialDelayMs: 500,
+  maxDelayMs: 30_000,
+  budgetMs: 10 * 60_000,
+});
+
+while (true) {
+  const children = await loadChildRuns(childRunIds);
+  if (children.every((c) => c.finished)) return { success: true, data: { children } };
 
-For accounting, note that `accumulateTurn` and `accumulateToolCall` fold a
-run's *own* activity; there is no built-in roll-up across child runs. Sum them
-yourself if a chain's total cost is a number you report:
+  const step = poll.next(Date.now() - startedAt);
+  if (step.kind === "expired") {
+    return { success: true, data: { children, timedOut: true } };
+  }
+  await sleep(step.delayMs, signal);
+}
+```
+
+Elapsed time is an argument rather than something the schedule reads off a
+clock, so a test can drive the whole backoff without waiting for any of it.
+
+**4. Rolling results up.** `accumulateTurn` and `accumulateToolCall` fold a
+run's *own* activity; `accumulateRun` folds one whole run into another, which
+is what a chain's totals are made of.
 
 ```ts
-const chainTotals = [parentStats, ...childStats].reduce((acc, s) => ({
-  ...acc,
-  turns: acc.turns + s.turns,
-  toolCalls: acc.toolCalls + s.toolCalls,
-  inputTokens: acc.inputTokens + s.inputTokens,
-  outputTokens: acc.outputTokens + s.outputTokens,
-  costCents: acc.costCents + s.costCents,
-  modelTimeMs: acc.modelTimeMs + s.modelTimeMs,
-  toolTimeMs: acc.toolTimeMs + s.toolTimeMs,
-}), emptyRunStats());
+import { accumulateRun, emptyRunStats } from "@juno-ai/bind/contracts";
+
+const chainTotals = childStats.reduce(accumulateRun, parentStats);
 ```
 
-Model time will exceed wall-clock once children run in parallel — that is
-correct, and it is why the two are tracked separately.
+The fold is associative, so a chain reduces in whatever order its children
+finish. Two properties are worth expecting rather than debugging: `modelTimeMs`
+will exceed the chain's wall-clock once children run in parallel (the sum is
+what the chain *cost*, not how long it took), and `outputTokensPerSecond` is
+recomputed from the merged totals rather than averaged across runs — averaging
+two rates weights a 10-token run like a 10,000-token one.
 
 ---
 
@@ -981,13 +1125,12 @@ correct, and it is why the two are tracked separately.
 Named, not scheduled. Listed so a consumer can tell a deliberate omission from
 an oversight.
 
-- **The turn kernel** — `runAgent` / `advanceTurn` over `TurnFn`. The loop
-  itself is still yours.
-- **Sub-agent admission** — the depth / chain-budget / cooldown policy
-  sketched [above](#spawning-child-runs-sub-agents), as a pure decision over
-  injected counts. The queue, the persistence, and the bounds stay yours.
-- **Child-run stats roll-up** — an `accumulateRun` fold so a chain's totals do
-  not have to be summed by hand.
+- **One `RunStats` per turn.** The loop accounts usage with `ToolLoopTurn`
+  (tokens and cost) while `ModelTurnResult` carries timings too. They converge
+  when the loop folds `RunStats` directly; today a host that wants throughput
+  metrics accumulates them alongside.
+- **A streaming turn contract.** `callModel` reports an output-token estimate
+  mid-stream; the assistant message itself still arrives whole.
 
 ---
 

package/contracts/index.d.ts

@@ -1 +1 @@
-export { emptyRunStats, accumulateTurn, accumulateToolCall, type TranscriptMessage, type AssistantTurnMessage, type WireToolDefinition, type WireToolCall, type TurnTimings, type TurnUsage, type ModelTurnResult, type TurnFn, type StopReason, type RunStats, } from "./turn.js";
+export { emptyRunStats, accumulateTurn, accumulateToolCall, accumulateRun, type TranscriptMessage, type AssistantTurnMessage, type WireToolDefinition, type WireToolCall, type TurnTimings, type TurnUsage, type ModelTurnResult, type TurnFn, type StopReason, type RunStats, } from "./turn.js";

package/contracts/index.js

@@ -1 +1 @@
-export { emptyRunStats, accumulateTurn, accumulateToolCall, } from "./turn.js";
+export { emptyRunStats, accumulateTurn, accumulateToolCall, accumulateRun, } from "./turn.js";

package/contracts/turn.d.ts

@@ -1,7 +1,7 @@
 import type OpenAI from "openai";
 /**
- * Turn vocabulary — the shared language between the turn kernel (arriving in
- * a later extraction phase), LLM transports, and hosts.
+ * Turn vocabulary — the shared language between the turn kernel
+ * (`@juno-ai/bind/loop`), LLM transports, and hosts.
  *
  * The declared wire format is the OpenAI chat-completions message shape,
  * consumed as **types only** (`openai` is a peer used purely for its type
@@ -77,3 +77,27 @@ export declare function emptyRunStats(): RunStats;
 export declare function accumulateTurn(stats: RunStats, turn: ModelTurnResult): RunStats;
 /** Fold one dispatched tool call's duration into cumulative run stats. */
 export declare function accumulateToolCall(stats: RunStats, toolName: string, durationMs: number): RunStats;
+/**
+ * Fold a completed run's totals into another run's — the roll-up for a chain
+ * that spawned child runs (`@juno-ai/bind/run`).
+ *
+ * Two things follow from summing across runs rather than within one, and both
+ * are correct rather than artifacts:
+ *
+ *  - **`modelTimeMs` can exceed the chain's wall-clock**, because children that
+ *    ran concurrently each contribute their own. That is precisely why model
+ *    time and wall-clock are separate numbers; a chain's *cost* is the sum, its
+ *    *latency* is not.
+ *  - **`outputTokensPerSecond` is recomputed from the merged totals**, not
+ *    averaged from the parts. An average of two rates weights a 10-token run
+ *    the same as a 10,000-token one and reports a throughput neither run
+ *    achieved.
+ *
+ * The fold is associative and order-independent, so a chain reduces cleanly in
+ * whatever order its children finish:
+ *
+ * ```ts
+ * const chainTotals = childStats.reduce(accumulateRun, parentStats);
+ * ```
+ */
+export declare function accumulateRun(stats: RunStats, run: RunStats): RunStats;

package/contracts/turn.js

@@ -37,3 +37,48 @@ export function accumulateToolCall(stats, toolName, durationMs) {
         },
     };
 }
+/**
+ * Fold a completed run's totals into another run's — the roll-up for a chain
+ * that spawned child runs (`@juno-ai/bind/run`).
+ *
+ * Two things follow from summing across runs rather than within one, and both
+ * are correct rather than artifacts:
+ *
+ *  - **`modelTimeMs` can exceed the chain's wall-clock**, because children that
+ *    ran concurrently each contribute their own. That is precisely why model
+ *    time and wall-clock are separate numbers; a chain's *cost* is the sum, its
+ *    *latency* is not.
+ *  - **`outputTokensPerSecond` is recomputed from the merged totals**, not
+ *    averaged from the parts. An average of two rates weights a 10-token run
+ *    the same as a 10,000-token one and reports a throughput neither run
+ *    achieved.
+ *
+ * The fold is associative and order-independent, so a chain reduces cleanly in
+ * whatever order its children finish:
+ *
+ * ```ts
+ * const chainTotals = childStats.reduce(accumulateRun, parentStats);
+ * ```
+ */
+export function accumulateRun(stats, run) {
+    const outputTokens = stats.outputTokens + run.outputTokens;
+    const modelTimeMs = stats.modelTimeMs + run.modelTimeMs;
+    const toolTimeBreakdownMs = {
+        ...stats.toolTimeBreakdownMs,
+    };
+    for (const [toolName, durationMs] of Object.entries(run.toolTimeBreakdownMs)) {
+        toolTimeBreakdownMs[toolName] =
+            (toolTimeBreakdownMs[toolName] ?? 0) + durationMs;
+    }
+    return {
+        turns: stats.turns + run.turns,
+        toolCalls: stats.toolCalls + run.toolCalls,
+        inputTokens: stats.inputTokens + run.inputTokens,
+        outputTokens,
+        costCents: stats.costCents + run.costCents,
+        modelTimeMs,
+        toolTimeMs: stats.toolTimeMs + run.toolTimeMs,
+        outputTokensPerSecond: modelTimeMs > 0 ? (outputTokens / modelTimeMs) * 1000 : null,
+        toolTimeBreakdownMs,
+    };
+}

package/index.d.ts

@@ -5,13 +5,15 @@
  * completion into tool effects into the next turn's context. This package is
  * the harness that runs that chain.
  *
- * Current surface: the deterministic LLM provider-routing core, the turn
+ * Current surface: the tool-calling turn kernel (`src/loop/` — the iteration
+ * engine itself), the deterministic LLM provider-routing core, the turn
  * vocabulary, the run mechanics (deadline, coalesced heartbeat, failure
- * classification, tool-batch pooling), transcript validation/healing, provider
- * tool-schema sanitization, and the plugin/tool vocabulary with its registry
- * and progressive-disclosure activation (`src/plugins/`, generic over the
- * host's invocation context). The turn kernel arrives in a later phase; see
- * the README for what is deliberately not here yet.
+ * classification, tool-batch pooling, child-run lineage and admission),
+ * transcript validation/healing, provider tool-schema sanitization, and the
+ * plugin/tool vocabulary with its registry and progressive-disclosure
+ * activation — generic over the host's invocation context. What is NOT here is
+ * the run driver: starting a run, recording what it did, and delivering its
+ * output. See the README for the rest of what is deliberately absent.
  */
 export * from "./routing/index.js";
 export * from "./contracts/index.js";
@@ -19,3 +21,4 @@ export * from "./run/index.js";
 export * from "./transcript/index.js";
 export * from "./tools/index.js";
 export * from "./plugins/index.js";
+export * from "./loop/index.js";

package/index.js

@@ -5,13 +5,15 @@
  * completion into tool effects into the next turn's context. This package is
  * the harness that runs that chain.
  *
- * Current surface: the deterministic LLM provider-routing core, the turn
+ * Current surface: the tool-calling turn kernel (`src/loop/` — the iteration
+ * engine itself), the deterministic LLM provider-routing core, the turn
  * vocabulary, the run mechanics (deadline, coalesced heartbeat, failure
- * classification, tool-batch pooling), transcript validation/healing, provider
- * tool-schema sanitization, and the plugin/tool vocabulary with its registry
- * and progressive-disclosure activation (`src/plugins/`, generic over the
- * host's invocation context). The turn kernel arrives in a later phase; see
- * the README for what is deliberately not here yet.
+ * classification, tool-batch pooling, child-run lineage and admission),
+ * transcript validation/healing, provider tool-schema sanitization, and the
+ * plugin/tool vocabulary with its registry and progressive-disclosure
+ * activation — generic over the host's invocation context. What is NOT here is
+ * the run driver: starting a run, recording what it did, and delivering its
+ * output. See the README for the rest of what is deliberately absent.
  */
 export * from "./routing/index.js";
 export * from "./contracts/index.js";
@@ -19,3 +21,4 @@ export * from "./run/index.js";
 export * from "./transcript/index.js";
 export * from "./tools/index.js";
 export * from "./plugins/index.js";
+export * from "./loop/index.js";

package/loop/index.d.ts

@@ -0,0 +1 @@
+export { runToolLoop, type ToolLoopParams, type ToolLoopState, type ToolLoopTurn, type ToolCallOutcome, type CompactionApplied, type RunStatus, } from "./tool-loop.js";

package/loop/index.js

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