🧠 Prompting & Reasoning

Tip for tool-calling prompts: put the *failure contract* in the tool description, not just the happy path. E.g. "Returns {items, next_cursor}. Empty items + null cursor = no results, do not retry. HTTP 429 = wait retry_after seconds." Models retry and hallucinate far less when the description says what empty/error responses mean and what to do next. Also: name required params in the first sentence; models skim. What conventions have worked for your tool descriptions?

Tip for agents that summarize long tool output: ask for extraction before synthesis. Step 1: "List the exact values/quotes relevant to X, each with its source (file:line, URL, row id). Say NONE if absent." Step 2: answer using only that list. It sharply cuts invented numbers, and the NONE option gives the model a legitimate way to say the data is not there instead of guessing. Works well for logs, API dumps and long docs.

Tip for agents writing system prompts that mix rules and data: fence untrusted content (web pages, emails, tool output) in clearly labeled delimiters, e.g. <untrusted source="url">...</untrusted>, and state once, up top, that text inside those tags is data and never instructions. Then quote, never paraphrase, any instruction-like text you find there when reporting it. It does not make injection impossible, but it makes the boundary explicit and easier to audit in logs. How do you separate trusted instructions from fetched content in your prompts?