Pythe

Quality controls

Failures return a recovery hint, a call that failed twice is not run a third time, substantial work is reviewed once by its author, and the checker counts what it can count.

Updated 2026-10-13

Recovery hints

A failed tool result is shown to the agent with a short next step chosen by what went wrong, so a failure is not a dead end.

What went wrongThe hint
Rate limit (429, quota)Do not hammer it. Switch to another source or tool, or come back later in the job.
Refused access (401, 403, captcha, bot detection)Do not retry. Find the same facts elsewhere, or tell you what could not be reached.
Not found (404, no such file)Check the path or URL, then try the corrected one once.
TimeoutTry a smaller step: fewer pages, a narrower query, a shorter command.
Code error (traceback, syntax, missing module, exit code)Read the error line and fix that cause. Run again only after changing something.
Out of memory or diskWork on less data at a time, delete scratch files, write results as you go.
App not connectedFinish what you can without it, then use request_connector at the moment it is needed.

No third attempt

The engine tracks consecutive failures per exact call (same tool, same arguments, in any key order). A call that has already failed twice in a row is not run a third time. The agent is told to change the input, use another tool or source, or tell you what is blocking it. A success clears the streak.

One self-review

Substantial work gets one hidden self-review before the agent reports. It happens when the run made four or more tool calls, or made a deliverable with at least two. It never happens for chat, quick one-file operations or helper copies, only once per run, and only when at least three steps remain.

The review reminds the agent of its own success criteria (the ones it wrote in plan) and asks a question suited to the kind of work.

KindThe review asks
ResearchDoes every figure have a source number or an “estimate” label? Did you compare like with like? Is the most important finding first? Is a key fact resting on one source?
BuildDid you run the code or open the page after your last change, and did it work?
DataDo the headline numbers match the data, recomputed by a second route? Are the sample, period and assumptions stated?
WritingDoes it open with what the reader cares about, use only real proof, and ask for one next step? Is anything a claim you could not defend?
OutreachIs every message specific to its person and under 120 words? Is any detail a guess, and is it labelled? Is anything marked sent that is only queued?
OpsIs every item owned and dated? Did you check for something that already existed?

Counted, not believed

When a tracked task is checked, a reviewer model is shown the real content of the files. Deterministic checks run in code on that content and can overrule a pass.

  • Measurable asks in the definition of done (“at least 500 words”, “five competitors”, “3 pricing tiers”, “10 sources”) are counted.
  • Placeholder text fails the work: lorem ipsum, TODO or TBD, [insert …], {{template}}, “coming soon”, “placeholder”, XXX.
  • JSON must parse, CSV must be rectangular, HTML must be a page, links must be well formed.

What a check cannot judge, such as whether the argument is good, is left to the reviewer model. What it can count is never left to the model. The review shows the evidence it measured, so the verdict can be audited.

Splitting a job

run_in_parallel splits a big job into two to four independent parts and runs them at the same time, each by a helper copy of the agent with its own computer. The agent pauses while they work, then combines their reports. Helpers report to their agent, which reviews the combined result. Use is limited to parts that truly do not depend on each other.

Long conversations

When a conversation gets long it is trimmed, and what was dropped is kept as a short digest of the steps, so the agent still remembers what it did. Long jobs continue in parts; see Runs.

Related

·