Two gaps surfaced by a live fan-out smoke in a downstream host (mort):

1) A single-loop run that exhausts its step budget (ErrMaxSteps / ErrToolLoop)
   returned empty Output + a hard error, discarding all the reasoning it had
   produced — unlike the phased path, which already salvages a partial
   transcript and continues. Add opt-in single-loop salvage
   (Defaults.SalvageSingleLoopMaxSteps, default off): on budget exhaustion with
   empty Output, reconstruct a best-effort answer from the step narration
   (reusing salvagePhaseTranscript) and downgrade the run to a successful
   partial result. Off by default so a structured-output host keeps its clean
   hard error; an interactive host opts in.

2) RunnableAgent carried no tool-call ceiling — MaxIterations bounds STEPS, but
   one step can dispatch several tool calls, so a host's "max tool calls" cap
   had nowhere to land. Add RunnableAgent.MaxToolCalls (<=0 = unlimited,
   backward-compatible): the step observer counts executed calls and, once the
   cap is reached, stepCeilingOption forces the loop to exit; the resulting
   ErrMaxSteps is relabeled to the new ErrMaxToolCalls sentinel. Enforced
   single-loop only for now (phased is a follow-up). A cap hit is budget
   exhaustion, so salvage recovers its partial reasoning too.

isPhaseBudgetExhaustion becomes the shared isBudgetExhaustion (now also matching
ErrMaxToolCalls) so the phased and single-loop paths never drift, and the
RunStateAccessor now reports the real tool-call cap (was hardcoded 0).

Additive + backward-compatible: new optional DTO field, new opt-in Defaults
flag, new exported sentinel; unlimited/off reproduce prior behavior exactly. No
new dependencies (go mod tidy clean). Tests cover salvage on/off/no-prose, cap
enforcement + sentinel, cap+salvage, unlimited no-op, and cap-overrides-critic.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Q1eJh5NVR11z6RzyxLANMK

@@ -121,0 +127,4 @@
+// an unlimited-tool-call run is a true no-op. nil-safe on the binding (b == nil
+// skips the critic branch). toolCalls/steps are read live from the step
+// observer's counters (same goroutine as this poll — see executor.go).
+func (b *criticBinding) stepCeilingOption(base, maxCalls int, toolCalls, steps *int) agent.Option {

@@ -375,0 +390,4 @@
+	// atomics). stepCeilingOption reads these to force the loop to exit once the
+	// cap is reached; the caller then relabels the resulting ErrMaxSteps to
+	// ErrMaxToolCalls. maxCalls <= 0 (unlimited) leaves this inert.
+	var toolCallsSeen, stepsSeen int

@@ -401,0 +422,4 @@
+		// Only single-loop runs enforce the cap (phased pipelines are a follow-up),
+		// so gate the crossing detection on Phases to avoid a misleading audit
+		// event on a phased run that merely happens to carry a cap.
+		toolCallsSeen += n

@@ -573,0 +623,4 @@
+		// This runs only after a budget error — ResultSchema + FinalGuard above
+		// are gated on runErr == nil, so neither fired. Gated on the host default
+		// so a structured-output host keeps its clean hard error.
+		if e.cfg.Defaults.SalvageSingleLoopMaxSteps &&

@@ -573,0 +627,4 @@
+			isBudgetExhaustion(runErr) && runRes != nil &&
+			strings.TrimSpace(runRes.Output) == "" {
+			if salvaged := salvagePhaseTranscript(runRes); salvaged != "" {
+				runRes.Output = salvaged +

@@ -283,3 +281,1 @@
-// partial transcript — as opposed to a hard error (cancellation, model failure).
-func isPhaseBudgetExhaustion(err error) bool {
-	return errors.Is(err, agent.ErrMaxSteps) || errors.Is(err, agent.ErrToolLoop)
+// isBudgetExhaustion reports whether err is a soft budget/guard stop (the loop

@@ -19,0 +22,4 @@
+// relabeled to this sentinel so audit + status report the real cause. Treated
+// as budget exhaustion by isBudgetExhaustion, so the single-loop salvage path
+// recovers a partial answer from it when enabled.
+var ErrMaxToolCalls = errors.New("run: max tool calls reached without a final answer")