Utility

Utility Skill

Overview

A decision framework for agent orchestration based on Liu et al., "Utility-Guided Agent Orchestration for Efficient LLM Tool Use" (arXiv:2603.19896). Each candidate action is scored by subtracting weighted costs from expected gain, producing a single utility value that guides action selection. The framework prevents over-calling tools and premature stopping by making both errors costly. Utility range is [-2.3, 1.0].

When To Use

• Deciding whether to dispatch another agent or tool call
• Gating expensive tool calls (search, code execution, delegation)
• Selecting the right model tier for a sub-task
• Continuation decisions after receiving partial results
• Verification gating before writing or committing output

When NOT to Use

• Single-step operations with one obvious action
• Trivial tasks where cost of scoring exceeds benefit
• Already-committed actions that cannot be undone

Action Space

A = {respond, retrieve, tool_call, verify, delegate, stop}

Utility Function

U(a | s_t) = Gain(a | s_t)
           - λ₁ · StepCost(a | s_t)
           - λ₂ · Uncertainty(a | s_t)
           - λ₃ · Redundancy(a | s_t)

Utility range: [-2.3, 1.0]. Positive values indicate the action is worth taking. Values below the floor (-0.5 default) indicate the action should be skipped.

Termination Conditions

Stop the loop when any of the following is true:

• (a) Selected action is stop
• (b) Step budget exhausted (default: 10 steps)
• (c) All non-stop actions score below the floor (default: -0.5)

High-gain override: If Gain >= 0.7 for any action, condition (c) may be overridden. Document the override and the gain value in your reasoning trace.

Quick Start

Minimal 4-step advisory pattern:

1. Construct state: gather task context per modules/state-builder.md 2. Score candidates: evaluate each action in A per modules/action-selector.md 3. Prefer highest utility: select the action with the maximum U(a | s_t), subject to termination conditions 4. Log score and decision: record the winning action, its utility value, and step count before executing

Detailed Resources

• State Builder: modules/state-builder.md, how to

populate s_t from task context

• Gain: modules/gain.md, estimating expected information

or progress gain

• Step Cost: modules/step-cost.md, token, latency, and

monetary cost tables

• Uncertainty: modules/uncertainty.md, confidence

estimation and calibration

• Redundancy: modules/redundancy.md, detecting duplicate

or low-delta actions

• Action Selector: modules/action-selector.md, scoring

loop and tie-breaking rules

• Integration: modules/integration.md, wiring utility

scoring into existing orchestration loops

Exit Criteria

• [ ] State constructed with task goal and prior steps
• [ ] All six actions scored before selecting one
• [ ] Termination condition checked after each step
• [ ] Score and decision logged for each step taken
• [ ] High-gain overrides documented with gain value

Action Selector

Combines scores from all four utility components and selects the highest-utility action for the current step. Produces an action report that downstream consumers use to drive execution.

Input Requirements

• Session state from state-builder (scope, step, max_steps,

lambda weights)

• Per-candidate scores: Gain, StepCost, Uncertainty,

Redundancy

Procedure

1. Enumerate candidates for the current scope (see Scope-Specific Action Sets below).

2. Compute utility for each candidate action a:

   U(a) = Gain - lambda_1*StepCost - lambda_2*Uncertainty
          - lambda_3*Redundancy

3. Select a* = argmax U(a) over all candidates.

4. Check termination conditions (see Termination Logic below).

5. Produce the action report (see Action Report Template below).

Scope-Specific Action Sets

Different scopes expose different candidate actions.

self: the top-level Claude instance answering a user:

• respond, retrieve, tool_call, verify, delegate,

stop

• delegate triggers a new dispatch-scope evaluation;

the nested scope selects its own a* independently.

subagent: a spawned agent executing a delegated task:

• respond, retrieve, tool_call, verify, stop
• No delegate; subagents execute, they do not orchestrate.

dispatch: an orchestrator managing a fleet of subagents:

• respond, delegate, retrieve, tool_call, verify,

stop

Termination Logic

Evaluate in order after selecting a*:

1. If a* == stop: terminate.

2. If step >= max_steps: terminate regardless of utility.

3. If max(U) for all non-stop actions < floor (default -0.5): terminate, UNLESS the high-gain override applies. The override applies when Gain >= 0.7 for at least one candidate action; in that case, proceed and document the override reason in the Rationale field of the report.

Action Report Template

Action: <selected>
Utility: <score>
Breakdown: Gain=X StepCost=Y Uncertainty=Z Redundancy=W
Rationale: "<1-sentence justification>"

All four breakdown fields are required. Utility is rounded to two decimal places.

Canonical Worked Example

Given scores for a tool_call candidate:

Gain        = 0.7
StepCost    = 0.12
Uncertainty = 0.6
Redundancy  = 0.0

With lambda weights [1.0, 0.5, 0.8]:

U = 0.7 - 1.0*0.12 - 0.5*0.6 - 0.8*0.0
  = 0.7 - 0.12 - 0.30 - 0.0
  = 0.28

Resulting report:

Action: tool_call
Utility: 0.28
Breakdown: Gain=0.7 StepCost=0.12 Uncertainty=0.6 Redundancy=0.0
Rationale: "Clear gap exists; tool call likely fills it at
            acceptable cost."

Prescriptive Gate

When the consuming skill's frontmatter sets utility_gated: true, the selected action a* is mandatory. The agent must not substitute a different action regardless of other heuristics or instructions.

Gain Estimation

The LLM self-estimates the marginal value of taking a candidate action before executing it. This is a heuristic signal rather than a calibrated probability.

Output

Gain(a | s_t) -> [0, 1]

Anchoring Scale

Estimation Prompts

Ask yourself these three questions before acting:

1. Does this action address an open task or an identified gap in my current answer? 2. How much new information is expected versus what I have already observed? 3. Is the current answer sufficient, or does it have clear, specific gaps?

Score higher when the answer to (1) is yes, (2) is substantial, and (3) points to a specific deficit. Score lower when the answer is already adequate or the action is exploratory.

Scope-Specific Guidance

self: Will reading this file or calling this tool fill a specific gap in my current understanding?

subagent: Will this finding advance my assigned task, or am I exploring outside my scope?

dispatch: Will this agent produce findings that existing agents haven't covered?

Match the question to your current execution scope before scoring.

Task-Aware Gain Boost

Actions that are directly mapped to the active current_task_id receive a +0.1 bonus, capped at 1.0. Use this boost only when the action explicitly advances the tracked task, not for tangentially related work.

Anti-Pattern

Never assign 0.9+ to a speculative action. Reserve the top tier for cases where the missing information is specifically identified and the action is known to retrieve it. A vague sense that more information might help is a 0.3-0.5 score, not a 0.9.

Integration

This module defines how consuming skills wire utility scoring into their orchestration loops. Two modes are available: advisory (default, no setup required) and prescriptive (opt-in, frontmatter-controlled).

Why prescriptive stays opt-in. Per

[docs/inclusive-defaults.md][inc] (TRUE-exception

category 9), advisory IS the inclusive default:

prescriptive mode requires per-skill consent because

it changes orchestration behavior, not just analysis.

[inc]: ../../../../../docs/inclusive-defaults.md

Advisory Mode

Advisory mode requires no frontmatter changes. The skill author adds a short evaluation block before each action decision.

4-step checklist:

1. Construct state per leyline:utility/modules/state-builder 2. Score candidates per leyline:utility/modules/action-selector 3. Prefer the highest-utility action unless you have a specific reason to override 4. Log the score and your decision before executing the action

Consumer can override the selected action with stated reasoning. The override must be recorded in the reasoning trace alongside the utility score.

What to add to your skill:

Before taking your next action, evaluate utility:
1. Construct state per leyline:utility/modules/state-builder
2. Score candidates per leyline:utility/modules/action-selector
3. Prefer the highest-utility action unless you have a
   specific reason to override
4. Log the score and your decision

Prescriptive Mode

Prescriptive mode enforces utility gating via frontmatter keys. The skill MUST follow the selected action; overrides are not permitted unless Gain >= 0.7 (document the override and gain value).

Frontmatter keys:

Validation rules:

• utility_lambdas: 3-element list of floats, each >= 0.

Falls back to [1.0, 0.5, 0.8] if invalid.

• utility_floor: must be in [-2.3, 1.0].

Falls back to -0.5 if out of range.

• utility_max_steps: positive integer.

Falls back to 10 if zero or negative.

Example frontmatter block:

---
name: my-skill
utility_gated: true
utility_floor: -0.3
utility_max_steps: 8
utility_lambdas: [1.0, 0.5, 0.8]
---

Dispatch Mode

Dispatch mode applies when a parent orchestrator manages subagents. Construct state with scope: "dispatch" and evaluate utility before launching each additional agent.

Per-agent utility evaluation follows the same formula but draws on dispatch-scope signals: agents_pending, total_agent_tokens, and coordination_overhead. Brooks's Law applies: adding agents to a late or saturated task increases coordination overhead faster than it increases throughput, driving StepCost up and utility down.

Decision pattern:

if U(delegate) < U(respond):
    synthesize current results and respond
else:
    launch agent N+1

Do not launch agent N+1 if utility of delegation is below utility_floor. Synthesize the results already in hand instead.

Consumer Adoption Path

Example: Prescriptive in do-issue Dispatch

Before launching agent N+1, do-issue constructs dispatch-scope state and checks utility:

state:
  scope: "dispatch"
  step: N
  agents_completed: N
  agents_pending: 0
  total_agent_tokens: <sum so far>
  coordination_overhead: <estimated from agent count>
  budget_remaining_ratio: (max_steps - N) / max_steps

Score U(delegate | s_N):
  Gain: estimated new evidence from agent N+1
  StepCost: λ₁ × cost of one more agent call
  Uncertainty: λ₂ × confidence in remaining scope
  Redundancy: λ₃ × overlap with prior agent findings

if U(delegate) < utility_floor (-0.3):
    stop dispatch, synthesize findings from agents 1..N
else:
    launch agent N+1

This pattern caps runaway agent counts without hard-coding a limit. The utility score adapts to observed evidence density and remaining budget rather than a fixed agent ceiling.

Redundancy

Redundancy penalizes repeated or similar actions to compact the execution trajectory. It reduces token waste without quality loss.

Formula

Redundancy(a | s_t) = max(exact_match, semantic_similarity)

Exact Match

Check actions_taken for an identical action+target pair. Returns 1.0 if found, 0.0 if not.

Examples:

• retrieve("src/foo.py") taken twice -> 1.0
• tool_call(grep "pattern") on the same pattern -> 1.0

Semantic Similarity

The LLM compares the proposed action to each entry in actions_taken and returns the highest similarity as a value in [0, 1].

Examples:

• Reading src/foo.py after reading src/foo_test.py -> ~0.3

(related but different files)

• Grepping for "error" after grepping for "exception" -> ~0.6

(semantically overlapping search targets)

Score closer to 1.0 when the proposed action would retrieve substantially the same information. Score closer to 0.0 when the files, targets, or intent are clearly distinct.

Dispatch-Scope Redundancy

When evaluating whether to launch agent N+1, compare its scope to the scopes of already-dispatched agents. Overlapping file sets or search targets score high on this signal.

Ask: does this agent's assigned scope duplicate work already assigned to a running or completed agent? If yes, raise the redundancy score and consider narrowing the scope or merging the agent into an existing one.

Paper Evidence

Semantic redundancy filtering reduced token consumption ~10% (1294 to 1157 tokens per trajectory) with no quality loss (F1 moved from 0.2360 to 0.2370). Source: Table 4 of Liu et al.

State Builder

Constructs the state representation that feeds all four utility scorers. The state object is populated once per evaluation session and passed unchanged to each scorer.

Scope Selection

State Template

state:
  scope: "self"            # self | subagent | dispatch

  # Static context
  query: ""                # Original user request
  action_space: []         # Available actions for this consumer
  budget:
    max_steps: 10
    token_ceiling: null
    model_tier: "opus"

  # Dynamic context
  step: 0
  actions_taken: []        # [{action, target, step, tokens_used}]
  observations: []         # Results from retrieve/tool_call/verify
  evidence_count: 0
  tokens_spent: 0

  # Task context (from TaskList)
  tasks:
    total: 0
    completed: 0
    in_progress: 0
    pending: 0
    current_task_id: null
    completion_ratio: 0.0

  # Dispatch-only fields
  agents: []               # [{agent_id, type, scope, tokens_used, status, findings_count}]
  agents_pending: 0
  agents_completed: 0
  total_agent_tokens: 0
  coordination_overhead: 0.0

  # Derived signals
  budget_remaining_ratio: 1.0
  action_diversity: 0.0
  retrieval_coverage: 0.0

Scope Transition Rules

Scope is fixed per evaluation session. A skill in self scope that decides to delegate starts a new evaluation in dispatch scope. Dispatch-only fields initialize to zero for non-dispatch scopes. The parent's self state is preserved after dispatch completes.

Observable vs Estimated

Construction Instructions

Populate state from available context in this order:

1. Step count and actions_taken: Read from conversation history. Count tool calls made since the task began. 2. Task counts: Pull from TaskList (total, completed, in_progress, pending). Compute completion_ratio = completed / total (or 0.0 if total is 0). 3. tokens_spent: Use session token counter if available; otherwise estimate from message lengths. 4. budget_remaining_ratio: Compute as (max_steps - step) / max_steps, clamped to [0.0, 1.0]. 5. retrieval_coverage: Estimate as files read divided by estimated relevant files. Use 0.5 as the default when total scope is unknown. 6. action_diversity: Count distinct action types in actions_taken divided by total actions taken. 7. Dispatch scope only: Populate agents list from dispatched agent results. Set agents_pending and agents_completed from agent statuses. Sum total_agent_tokens from each agent's tokens_used.

Subagent Constraints

Subagents cannot access the parent's TaskList. Task context for subagents comes from the dispatch prompt, not from TaskList directly. Populate tasks.total and tasks.completed from explicit counts provided in the dispatch instructions. If no task counts are provided, leave all task fields at their zero defaults and rely on step-based signals instead.

Step Cost

StepCost is an observable cost proxy that increases as budget depletes. It is not a direct measurement of tokens or latency, but a lightweight control signal used to discount Gain estimates.

Formula

StepCost(a | s_t) = w1 * step_ratio
                  + w2 * token_ratio
                  + w3 * model_cost_ratio

Component Definitions

step_ratio = current_step / max_steps (budget burn rate)

token_ratio = estimated_action_tokens / token_ceiling

Set to 0 when no ceiling is configured; weights renormalize in that case (see Null Token Ceiling below).

model_cost_ratio

External models via conjure use delegation-core's own cost estimation.

Weight Defaults

Null Token Ceiling

When token_ceiling is null, token_ratio = 0 and the w2 term drops out entirely. Weights renormalize to w1 = 0.71, w3 = 0.29.

Dispatch-Scope Overhead

For actions in dispatch scope, add a coordination_overhead term derived from Brooks's Law:

Worked Example

Step 3 of 10, opus model, no token ceiling:

StepCost = 0.71 * (3/10) + 0.29 * 1.0
         = 0.71 * 0.3 + 0.29
         = 0.213 + 0.29
         = 0.503

Design Note

Cost increases as budget depletes: early actions are cheap, late actions are expensive. This produces the diminishing-returns curve from the paper's Fig. 4.

Uncertainty Estimation

The LLM self-estimates whether current evidence is sufficient to act confidently. This is the weakest signal in the utility function (Pearson r=0.0131 with final quality) but serves as a useful tiebreaker when gain and cost scores are close.

Output

Uncertainty(a | s_t) -> [0, 1]

Behavioral Effect

High uncertainty pushes toward retrieve or verify actions. Low uncertainty pushes toward respond or stop actions.

Anchoring Scale

Estimation Prompts

Ask yourself these three questions before scoring:

1. How many of the relevant files or resources have I examined? 2. Are there known unknowns I haven't yet addressed? 3. Could my current answer be wrong in a way that matters?

Score higher when coverage is low, known unknowns remain open, or the answer has a plausible failure mode you haven't ruled out. Score lower when coverage is broad, no critical gaps remain, and the answer holds up under a quick adversarial check.

Calibration Warning

The paper found Pearson r=0.0131 between self-estimated uncertainty and final quality. This is weak correlation. Treat this signal as a tiebreaker, not a primary driver. It is weighted at lambda_2=0.5 in the combined utility formula precisely because over-relying on it degrades decision quality.

Scope-Specific Notes

self: uncertainty about your own evidence base. Have you read the files and called the tools needed to answer the question?

subagent: uncertainty about your assigned task specifically. Are there task requirements you haven't confirmed or edge cases you haven't checked?

dispatch: uncertainty about whether existing agents have covered the problem space. Are there dimensions of the problem no agent has been assigned?

Match the question to your current execution scope before scoring.