Work handed to a second model, which may not ask

subagent_run gives a self-contained piece of work to a helper carrying the
parent's connection, directory, model and effort, and hands its answer back as
the tool result. The mechanism is the one scheduled runs already use -- a hidden
chat, one turn, wake_chat, and a poll -- so tools, rounds, budgets, metrics and
steps all work with no second implementation. The two alternatives were
rejected where they had already been rejected once: a nested Generation is two
replies writing one transcript, and a one-shot complete() has no tools, which
schedule/runner.py records as useless for exactly this case.

Every restriction is a property of the child's row, applied by resolve_tools
after the gates, because a rule that lives in a system message is one a page the
model just read can argue with. No questions, no recursion, nothing that writes
unless the call asked for it and the parent's own mode would not have stopped
first, and commands only from a fixed read-only list -- in every mode including
Auto, because the task text can have come from a page.

Withdrawing ask_user turned out to be half of "nobody is watching". An approval
still built a card nobody could see and parked the reply until approval_timeout,
which from every screen is the feature not working. Chat.unattended is the
question now, and not the kind: _authorise answers with a refusal instead. A
scheduled task's chat had the same hole and is covered by the same flag.

Three bounds, counted where each is knowable: per reply on the parent's
Generation, instance-wide in a set a restart clears, and per helper in settings
of its own so one runs out of room long before the reply that asked. Past the
clock the helper is stopped rather than abandoned, so a partial answer comes
back with a sentence saying so.

Also: four gates had shipped into the scope menu with no name, taking the first
tool's label instead -- the canvas switch read "Canvas written". There is a test
that refuses a family without one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lembas/web/templates/admin/agents.html

@@ -433,4 +433,128 @@
     <button class="btn btn--primary" type="submit">Save changes</button>
   </div>
 </form>
+
+{#
+  A second form, and a second settings group. Subagents are not an agent-chat
+  feature — an ordinary chat can delegate as well — but this is the page
+  somebody comes to when they want to know what one reply may set going on its
+  own, and a nav entry for a single card would be worse than the near-miss.
+
+  A form cannot nest inside another, so this sits *after* the one above rather
+  than as a card inside it. Two forms means the browser posts only the one whose
+  button was pressed, which is what keeps each group's save handler writing one
+  key.
+#}
+<form method="post" action="/admin/agents/subagents" class="form-grid">
+  <section class="card">
+    <h2 class="card__title">Helpers</h2>
+    <p class="field__hint">
+      A reply can hand a self-contained piece of work to a second model that
+      runs on its own and reports back — several at once, which is what makes
+      research fan out instead of queueing. This applies to ordinary chats as
+      much as agent ones.
+    </p>
+
+    <div class="alert">
+      {{ icon("shield", "icon--sm") }}
+      <span>
+        A helper cannot ask anybody anything, so nothing in its chat can stop
+        for approval. It therefore gets only what this chat could already do
+        <em>without</em> asking: it reads, it searches, and on a machine it runs
+        a short fixed list of read-only commands and nothing else, in every mode
+        including <strong>Auto</strong>. It cannot send helpers of its own.
+      </span>
+    </div>
+
+    <div class="field">
+      <label class="checkbox">
+        <input type="checkbox" name="enabled" value="true"
+               {{ 'checked' if subagents.enabled }}>
+        <span>Let a model delegate</span>
+      </label>
+      <p class="field__hint">
+        People also need the <strong>Delegate to a helper</strong> permission,
+        and the model needs the <strong>Tools</strong> capability. Off by
+        default: a reply that spawns helpers spends model time multiplicatively,
+        and on one local endpoint four at once is four times the queue rather
+        than four times the speed.
+      </p>
+    </div>
+
+    <div class="field">
+      <label class="field__label" for="sub_max_per_reply">Most helpers one reply may send</label>
+      <input class="input" id="sub_max_per_reply" name="max_per_reply"
+             type="number" min="1" max="20" step="1"
+             value="{{ subagents.max_per_reply }}">
+      <p class="field__hint">
+        Fanning out across a handful of independent questions is what this is
+        for. A reply that wants twenty has misread the tool.
+      </p>
+    </div>
+
+    <div class="field">
+      <label class="field__label" for="sub_max_concurrent">Running at once, instance-wide</label>
+      <input class="input" id="sub_max_concurrent" name="max_concurrent"
+             type="number" min="1" max="50" step="1"
+             value="{{ subagents.max_concurrent }}">
+      <p class="field__hint">
+        Each is a whole generation against the same endpoint the reply that
+        asked for it is waiting on. Past this a model is told to do the work
+        itself rather than made to wait.
+      </p>
+    </div>
+
+    <div class="field">
+      <label class="field__label" for="sub_max_completion_tokens">Most a helper may write</label>
+      <input class="input" id="sub_max_completion_tokens" name="max_completion_tokens"
+             type="number" min="0" max="5000000" step="1000"
+             value="{{ subagents.max_completion_tokens }}">
+      <p class="field__hint">
+        In tokens, across every round. A helper answers one question, so this
+        should run out well before the reply that asked does. Zero means no
+        ceiling.
+      </p>
+    </div>
+
+    <div class="field">
+      <label class="field__label" for="sub_wall_seconds">Longest a helper may take</label>
+      <input class="input" id="sub_wall_seconds" name="wall_seconds"
+             type="number" min="30" max="7200" step="30"
+             value="{{ subagents.wall_seconds }}">
+      <p class="field__hint">
+        Seconds. Past it the helper is <em>stopped</em>, not abandoned: what it
+        had written is kept and handed back with a note saying it is partial.
+      </p>
+    </div>
+
+    <div class="field">
+      <label class="field__label" for="sub_max_rounds">Most rounds of tool calls</label>
+      <input class="input" id="sub_max_rounds" name="max_rounds"
+             type="number" min="1" max="200" step="1"
+             value="{{ subagents.max_rounds }}">
+      <p class="field__hint">
+        A backstop, as it is above. The clock and the token ceiling are what
+        normally end one.
+      </p>
+    </div>
+
+    <div class="field">
+      <label class="checkbox">
+        <input type="checkbox" name="keep_transcript" value="true"
+               {{ 'checked' if subagents.keep_transcript }}>
+        <span>Keep a helper's own chat afterwards</span>
+      </label>
+      <p class="field__hint">
+        Off means it is deleted once its answer has been handed over, which is
+        what keeps this cheap to use. Turn it on to work out why one came back
+        with something odd. Kept chats are temporary either way and are swept a
+        day later, and neither appears in anybody's sidebar.
+      </p>
+    </div>
+  </section>
+
+  <div class="btn-row">
+    <button class="btn btn--primary" type="submit">Save changes</button>
+  </div>
+</form>
 {% endblock %}