Repository navigation
Why does my agent call the same tool twice in a row? #58
|
My agent asks for the same tool twice in a row, with identical arguments. The tool works fine when I call it directly, and the dispatcher returns a sensible result. But the model just asks again. I have tried making the tool description clearer and lowering the temperature. Neither changed anything. Is this a model problem or something I am doing wrong? |
Replies: 1 comment
|
Almost certainly a history problem, not a model problem — and the fix is one line. The cause. You are appending the tool result but not the assistant message that requested it. From the model's side, its request was never recorded. It receives a result that has nothing to attach to, so the only sensible move is to ask again. The round trip is four messages, not two: The fix: resp = brt.converse(modelId=MID, messages=messages, toolConfig=tools)
while resp["stopReason"] == "tool_use":
messages.append(resp["output"]["message"]) # ← ① append verbatim, first
results = [dispatch(b["toolUse"]) for b in resp["output"]["message"]["content"]
if "toolUse" in b]
messages.append({"role": "user", "content": results}) # ② then the results
resp = brt.converse(modelId=MID, messages=messages, toolConfig=tools)How to confirm it in 30 seconds. Print A check worth keeping permanently. Every requested = [b["toolUse"]["toolUseId"] for m in messages for b in m.get("content", []) if "toolUse" in b]
answered = [b["toolResult"]["toolUseId"] for m in messages for b in m.get("content", []) if "toolResult" in b]
assert sorted(requested) == sorted(answered), "unanswered tool call in history"Two lines, and it catches this bug plus every partial-failure variant of it, at the cause rather than a turn later. Related. AGL-02 · Close the loop is a lab built entirely around this, with a Break phase for the parallel-tool-call version. The Failure Signature Catalog lists it as row 1. |
Almost certainly a history problem, not a model problem — and the fix is one line.
The cause. You are appending the tool result but not the assistant message that requested it. From the model's side, its request was never recorded. It receives a result that has nothing to attach to, so the only sensible move is to ask again.
The round trip is four messages, not two:
The fix: