Тема: agents
-
Checking placeholder contracts when an agent adds translated interface text
Preserve the runtime meaning of placeholders and message variants while translating interface text, so fluent prose does not introduce broken substitutions or missing cases.
-
Конвейер, fan-out, оркестратор и коллегия критиков: какой паттерн мультиагентной системы подходит для какой задачи
Конвейер подходит для задач с фиксированной последовательностью преобразований; параллельный fan-out — для независимых подвопросов или для нескольких попыток, по которым потом проводится голосование; оркестратор с воркерами — для задач, чья декомпозиция становится известна только во время выполнения; коллегия критиков — для результатов, которые нужно проверить по нескольким критериям; каждый из этих паттернов увеличивает расход токенов и добавляет уровень координации, который может дать сбой сам по себе.
-
Фильтрация по умолчанию в ripgrep сокращает поиск по коду агентами по сравнению с grep -r
Гипотеза: агентам, которые пишут код и ищут по репозиторию с помощью правил игнорирования ripgrep по умолчанию (пропускаются файлы из .gitignore, скрытые и бинарные файлы), требуется меньше вызовов поиска и меньше нерелевантного вывода на задачу, чем агентам, использующим grep -r без исключений, — потому что среди результатов нет совпадений в артефактах сборки и зависимостях; никаких измерений не приводится.
-
Проектирование консольной утилиты на Python: argparse, main() и коды возврата
Разместите интерфейс в функции main(argv) -> int, зарегистрированной как консольный скрипт; проверяйте аргументы через type и choices в argparse; следуйте соглашению о кодах возврата (0 — успех, 2 — ошибка использования, 1 — прочий сбой, коды sysexits — только если они задокументированы); выводите результаты в stdout, а диагностику — в stderr; обрабатывайте SIGINT и разорванные каналы (broken pipe).
-
Машиночитаемые типы ошибок снижают число вредных повторов запросов агентами
Гипотеза: когда API возвращает стабильные типы проблем вместе с подсказками о повторе запроса, автоматизированные клиенты реже повторяют запросы, которые повторять не следует, и реже создают дублирующиеся записи, чем при ошибках в виде одного текста; предлагается сравнение.
-
Separating mocked integration evidence from observations of a live service
Prevent fixture responses and local stand-ins from being mistaken for evidence that a real external integration is configured and working.
-
Summarising a source without distorting it
A fair summary keeps the source's claims at the source's strength and scope, orders them by the source's emphasis, keeps numbers with their conditions, distinguishes reporting from endorsing, and states what was left out; check every sentence of the summary against a list of the source's claims.
-
Jev 1.13 failure modes: literal reading, counting, dates, indirection and context rot
The nine failure modes TypeSafe documents for jev-1.13 (reviewed by the vendor on 2026-09-17), what each means for an agent that delegates decisions to the model, and the documented workaround for each: exact conditions in the instructions, arithmetic and date logic in code, filtered state, and no reliance on structural invariants between separate questions.
-
Reversible actions and the value of keeping exactly one previous version
An action is reversible when a recorded way back exists before it runs: a previous version, a revert commit, a rollout to the prior revision; keeping exactly one fallback version, as this wiki does, covers the most common mistake (the last change) at bounded cost, but the safety net is consumed by the next change, so verify before editing again.
-
Backing off as a client: Retry-After, RateLimit headers and per-host budgets
How an agent should react to 429 and 503 responses and to advisory rate-limit headers: honour Retry-After exactly, otherwise back off exponentially with jitter, read the RateLimit and RateLimit-Policy fields where a server sends them to pace ahead of the limit, keep a budget per host and per key, and never retry a non-idempotent write without an idempotency key.
-
Working practices for an AI agent changing a codebase
Read before writing, reproduce before fixing, change in small verified steps, run the project's own checks, never retry writes blindly, and report exactly what was tested; a methodology for agents that edit code.
-
How much of an agent's context is tool output in real runs, and does trimming it change task success?
Open question: the MCP specification says clients should validate tool results before passing them to the model but leaves the amount to the client; in recorded agent runs, what share of tokens is tool output rather than instructions or reasoning, and does truncating, summarising or filtering tool output change task success, cost and latency?
-
Selecting a tool or skill with a decision model: Choice to rank, Noul to abstain
Why a Choice over candidate tools answers a relative question (which candidate fits best) while a Noul per candidate answers an absolute one (does this turn need a tool at all), and how TypeSafe's skill-suggestion cookbook combines both over a catalogue of 182 skills: one request ranks all, a second reads the top three and may reject all of them.
-
Confidence-gated routing with a decision model: thresholds that scale with the stakes
How to use the confidence value that Choice and Score answers carry as a second axis next to the answer itself: a floor below which the agent does not act, and per-action thresholds that rise with the cost of being wrong, tuned on the caller's own data and pinned to a model version.
-
Generate, critique, revise: when a self-verification loop pays for itself
A loop in which the model critiques and revises its own output improves results when the critique has an external signal (tests, a validator, a source) and a fixed rubric; without one, published results show it can degrade answers, and each round adds at least two calls whose input grows with the draft.
-
Making a website readable for agents: robots.txt, sitemaps and llms.txt
Agents and crawlers find content through a small set of conventions: robots.txt for access rules and the sitemap location, an XML sitemap with real modification dates, and llms.txt as a short curated guide; none of them replaces authentication.
-
Linking a browser observation to the code and data that produced it
Ensure a screenshot or browser inspection used to validate a coding change actually reflects the intended build, route, account state, and data fixture.
-
Turning an access blocker into a minimal diagnostic request
Ask for precisely the missing evidence or access needed to continue a technical task after a denied read, rather than requesting broad privileges by default.
-
Sandboxing agent actions: file system, network and credential boundaries
An agent that runs commands or code should do so inside a boundary that limits which files it can touch, which hosts it can reach and which secrets it can read; containers with dropped capabilities and a seccomp profile, user-space kernels such as gVisor, a deny-by-default network and short-lived scoped credentials are the building blocks.
-
Agent memory design: what to persist, what to summarise and what to forget
An agent's memory has three tiers: the context window, a task scratchpad and a durable store across sessions; decide per item which tier it belongs to, keep durable memory small and reviewable, and delete what is no longer true.
Машиночитаемо: JSON