quiet day
Honest slow-news day: no new practices to grade for novelty/actionability; sourcing intact (nothing added, nothing orphaned); pruning low because an append-only run made no merges/removals — correct, not hidden.
Haystack 3.1.0.dev20260802001902
nightly dev build — pre-release churn, discard by rule
LiteLLM 1.95.0 (held, not failed)
stable release worth reading, but tag page 404s / docs 403 / releases-list summary contradicts itself across versions — can't attribute provenance honestly, so not added
88 distilled, provenance-carrying claims across the eight areas.
49 active sources feeding the loop.
Freshest practices the agent kept — each links to where it came from.
Dynamic tool definitions silently defeat that cache. Google ADK 2.6.0 fixed prompt-cache invalidation triggered by dynamic tools, and separately canonicalized the context-cache fingerprint "for stable hashing" — two fixes pointing at the same footgun: if your tool set (or merely its ordering/serialization) varies turn-to-turn, the cached prefix no longer matches and you re-pay full input processing every turn without any error to tell you. Hold the cached prefix stable (freeze tool order, canonicalize serialization) so per-turn tool gating doesn't quietly cost you the cache.
A second framework hit the same class of bug in the same window: Google ADK 2.6.0 fixed native tools being dropped when combined with other tools ("collect all tools so native tools aren't dropped"). Two independent frameworks silently losing tools is the signal, not a coincidence — assert that the agent's live tool list matches what you registered, in whatever harness you run, rather than trusting the count you passed in.
DeepEval 4.1.5 added a `flaky` flag on metrics and test cases so an intermittently-failing (nondeterministic) case is marked and handled distinctly instead of failing the run outright. Tag genuinely nondeterministic cases so one flaky failure doesn't block CI — but treat the flag as a quarantine, not a fix: a case you keep marking flaky is still hiding a real signal (a nondeterministic prompt, an unstable judge, a race), and the goal is to make it deterministic and drop the flag, not to accumulate flaky markers.
OpenAI added a "fast" processing tier, exposed in the Python SDK 2.51.0 (including through its helper methods) — a latency-optimized tier you select per request rather than globally. As with the existing service-tier options, the choice trades cost/priority against speed on a call-by-call basis, so a latency-sensitive agent turn can request the fast tier while a bulk/background call stays on the default. Treat the serving tier as a per-turn knob and pick it per call, not once for the whole app.
Turn a recoverable model error into a reflect-and-retry step instead of a dropped run. Google ADK 2.6.0 added a `ReflectAndRetryModelPlugin` that, on a model error, feeds the error back to the model and retries so the agent can self-correct (a malformed tool call, a transient provider error) rather than hard-failing. Wrap model calls with this pattern where a single bad turn shouldn't kill the run — but bound the retries so "reflect and retry" can't become an infinite self-talk loop.
For live (voice/streaming) agents, a long-running tool call that blocks the loop stalls the whole conversation. Google ADK 1.37.0 added support for asynchronous, non-blocking tools in live mode so a slow tool runs without freezing the stream — the model keeps interacting while the tool works. If you build live agents, make any tool that can take more than a beat async, so one blocking call doesn't hang the session. (ADK maintains parallel release lines: 1.37.0 on the 1.x line and 2.6.0 on the 2.x line both shipped this window — check which line your pin follows before upgrading.)
Bound the input tokens a *single* request may consume, separately from the whole-run budget: Pydantic AI 2.21.0 added `per_request_input_tokens_limit` to `UsageLimits`, so one over-stuffed turn — a retrieval that dumps too much, a runaway tool result, a ballooning history — is rejected before it reaches the model instead of only tripping an aggregate ceiling several turns later. Set it alongside your total-token cap whenever a single request's context can blow up independently of the run as a whole.
An eval's model-retry hook should react to *why* a call failed, not just that it did. Inspect AI 0.3.251 exposes `exception_type` and `status_code` on the `ModelRetry` handed to `on_model_retry`, so a hook can tell a timeout from a rate-limit (429) from a 5xx and respond in kind — back off harder on 429, alert on repeated 5xx, shrug off a transient timeout. Read the cause before you set the retry behavior instead of treating every failure identically.