Skip to content

emrg: the shared prompt asks for a count of calls, not for a plan of the round #2437

Closed

Description

@argszero

What is observed

emrg/server/prompts/system.j2:40 is the one bullet every session receives about how many tool calls one round may carry:

  • Issue every call you can already specify, in one response. Sending several is the normal case: a call goes alone only when its arguments need an answer you have not read yet, and then its intent names the specific answer it waits for. Every round re-sends the conversation and emits fresh output.

It names a count and a cost. It never asks the reader to work out, before calling anything, what the round has to establish — so a reader can meet it one call at a time, because the bullet's only test is whether a call "needed" an answer.

Why that is the defect

scripts/check-batching-share.py, run on this installation over ~/.emrg (162 history files, window 2026-07-27T11:03:55 .. 2026-10-21T14:13:09):

rounds:  137592 assistant record(s) carrying at least one tool call
  share with two or more: 13320 (9.7%)
  share with exactly one:  124272 (90.3%)
  lone intents naming no awaited answer (lexical proxy): 114898 of 124272 (92.5%)

So the rule is not being engaged with. A lone round is the default, and the sentence the rule puts on a lone call — an intent naming what it waits for — is carried by 7.5% of them. The bullet's subject is the count; the behaviour it wants is a plan of the round, formed before the first call.

What the fix must satisfy

1. The bullet's replacement, verbatim. One bullet, in the same place, with ## How you work keeping its three bullets — replaced, not added to, and with no new section, no examples and no dates:

  • Plan the round before the first call. Enumerate what this round has to establish and the readings it needs, and write that enumeration out as the opening lines of your reply, before you call anything. Every reading you can already specify goes out in one response; a call stands alone only when its arguments need an answer you have not read yet. The plan is revised between rounds, when a reading changes what the round can still settle — never between two calls of the same round. One round re-sends the whole conversation and emits fresh output, so a lone call buys a single reading at the price of a round.

The clause never between two calls of the same round is load-bearing, not decoration: a variant that says to update the plan before each call turns the enumeration into a per-call ritual and puts the behaviour back where it started.

2. A test anchors the two action phrases, Plan the round before the first call and write that enumeration out as the opening lines of your reply, and each one's removal turns that test red.

3. The change stays inside the prompt. The same PR's diff carries no daemon change, no client change and no emrg/server/evolution_prompt.md change; rulebook R10 and the shipped bullet are allowed to state the rule at different lengths.

4. The guards that read this bullet move with it. tests/test_several_calls_rule_reach.py names the lead phrase and the parts of the ruling; tests/test_evolution_prompt_round_cost.py compares the phrases the two carriers share word for word. Both must be re-pointed at what the new text says, and the second only at phrases both carriers still carry.

Out of scope, and named so it is not read as solved

Once the last message in the conversation is a tool result, the position admits no wording: a prompt cannot ask for a plan before a round whose first move the reader is already mid-way through. This issue changes the wording of one bullet and nothing else.

Activity

  1. argszero commented on Oct 21, 2026

    @argszero
    OwnerAuthor

    Handled by 2438

  2. argszero commented on Oct 21, 2026

    @argszero
    OwnerAuthor

    Handled by #2438 (the earlier comment on this issue wrote the number without its #, so nothing read it as a claim)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions