Custom AI Agents и по-добри runtime контроли

Ако избирам архитектура за custom AI agents, вече не питам кой модел има най-големия context window. Питам кои runtime контроли държат агента фокусиран след 50 tool calls, няколко прочитания на големи файлове и едно лошо summary. Това всъщност е ключовото решение зад последната вълна документи за long-horizon агенти от AWS, Anthropic, LangChain, OpenAI и Manus.

Полезната промяна е проста: надеждността се измества от model layer към AI integration architecture. Според обобщението на MarkTechPost за актуалните насоки при агентите, екипите се обединяват около четири контроли: context budgeting, compaction, todo-state и memory.

Comparison table: which control fixes which failure?

Runtime control	Best at fixing	Cost trade-off	When I would use it	Main risk
Context budgeting and offloading	Context overflow	Extra file I/O, retrieval logic	Any agent expected to read long tool outputs or documents	Pointer strategy gets messy if retrieval is weak
Compaction	Window resets on long sessions	Summary quality work, eval overhead	Multi-step tasks that will definitely cross a threshold	Goal loss if the summary drops a constraint
Todo-state and recitation	Goal drift between compactions	Small token tax every turn	Long tasks with many branches or handoffs	Extra chatter can raise cost without improving reward
Persistent memory	Cross-session continuity	Standing attention tax, stale memory cleanup	Repeated workflows in AI workflow automation	Reloading too much context every run

На практика това не са взаимозаменяеми опции. Те се наслагват. Но редът има значение. Аз започвам с budgeting, защото всеки token, който не вкарам в prompt-а, е token, който после няма да трябва да обобщавам.

Why custom AI agents fail on long-horizon tasks

В една клиентска реализация за вътрешни support процеси първият проблем никога не беше интелигентността на модела. Беше натрупването. Агентът продължаваше да добавя tool output, докато първоначалната инструкция не се озова по средата на prompt-а, а после планът започваше да се разклаща. Този модел съвпада с рамката на AWS, цитирана от MarkTechPost: повърхностните агенти удрят context overflow, губят целта и не успяват да поддържат state.

Аргументът за по-голям window звучи привлекателно, но данните са по-слаби, отколкото повечето екипи очакват. Докладът Context Rot на Chroma установява, че надеждността се влошава с нарастването на входа, дори при retrieval задачи. Ръководството на Anthropic за context engineering обяснява защо: цената на attention расте с взаимодействията между token-ите, така че допълнителният context носи намаляваща възвръщаемост. Manus добавя и операторската гледна точка: типична задача може да изисква около 50 tool calls при съотношение вход към изход близо до 100:1, което означава, че раздуването на prompt-а много бързо се превръща в runtime проблем.

От playbook-а на Encorp: Третирам дълго работещите агенти като distributed systems, а не като fancy prompts. Слагайте твърди лимити на това какво влиза в context-а, решавайте какво оцелява след reset и тествайте compaction умишлено, преди workflow-ът изобщо да стигне production. За екипи, които изграждат AI Automation Implementation, runtime политиката е толкова важна, колкото и изборът на модел.

Mechanism 1: Budget context before it enters the window

Това е най-чистият компромис от четирите. Ако отговорът от даден tool е твърде голям, за да е полезен в context, не го дръжте там. LangChain Deep Agents използва твърди прагове, които си струва да копирате като отправна точка: tool responses над 20,000 tokens се изнасят на disk, а когато session context мине 85% от window-а, по-старите редакции могат да се заменят с pointers. Това е добро AI agent development, защото избягва да хабите compaction цикли за шум, който изобщо не е трябвало да присъства.

Документацията на Claude Code показва сходен модел с ограничена auto memory и отложени tool schemas. Същият принцип се вижда и в Amazon Bedrock AgentCore, където subagents вършат локалната си работа и връщат само структурирани findings. Харесвам този дизайн, защото променя единицата context от суров trace към summary, готово за решение.

Компромисът тук е сложността на имплементацията. Когато offload-вате агресивно, качеството на retrieval става критично. Ако file pointers са непоследователни или read-back стъпката е бавна, агентът започва да thrash-ва. При enterprise AI integrations предпочитам да приема малко допълнителна storage логика, вместо да плащам за раздут prompt при всяка стъпка.

Mechanism 2: Compaction must preserve the goal

Compaction е контролата, към която посягам, когато дългите задачи са неизбежни, но е и тази, на която имам най-малко доверие, докато не видя evals. Лошото summary не се проваля шумно. То тихо изтрива едно бизнес правило, едно ограничение по пътя или един нерешен bug, от който следващите 30 минути са зависели.

Затова детайлите по имплементацията имат значение. Подходът на Claude към compaction запазва архитектурни решения, нерешени bug-ове и детайли по имплементацията, след което препрочита последните файлове след reset. Compaction flow-ът в Responses API на OpenAI пренася същата идея в API слоя, като връща compacted context window, който разработчиците трябва да подават нататък без промяна. Съобщава се, че Deep Agents са подобрили резултатите, като структурират summaries около session intent, създадени artifacts и следващи стъпки.

Компромисът тук е инженерна дисциплина. Summary prompt-овете не са setup формалност; те са production артефакти. В AI implementation services ги тествам по същия начин, по който тествам retry логика. Форсирайте compaction при 10% до 25% от window-а по време на evals, след това търсете провалите, които LangChain посочва: агентът иска уточнение след summary или обявява победа твърде рано.

Mechanism 3: Recite the plan with todo-state

Todo-state изглежда примитивно, затова екипите го отхвърлят твърде рано. Аз не бих. Кратък task файл, пренаписван на всеки няколко хода, държи целта близо до най-скорошния край на context-а, където моделът е по-вероятно да ѝ обърне внимание. Manus описва това директно с todo.md, а насоките на Anthropic за структурирано водене на бележки показват същия модел в по-дълги сценарии.

Компромисът е измерим token cost. LangChain направи todo middleware optional във v0.7, след като evals показаха малко по-добър reward и по-ниска цена с изключени todos в някои категории. Това съвпада с наблюденията ми: при кратки support автоматизации recitation на todo обикновено е шум; при разклонена AI business automation с retries и approvals често си заслужава.

Правилото ми е просто. Ако workflow-ът има повече от едно разклонение, каквато и да е human approval стъпка или вероятно runtime над 10 минути, поддържам устойчив task файл. Ако не, го пропускам, докато trace-овете не докажат, че ми трябва.

Mechanism 4: Add memory that survives the session

Persistent memory е най-изкушаващата и най-лесната за прекаляване контрола. Да, continuity между сесиите помага. Amazon Bedrock AgentCore Memory и file-based memory моделите на Anthropic поддържат recall в следващи изпълнения. За повтаряеми support, analytics или software delivery задачи това може да намали излишното проучване.

Но memory не е безплатен context. Изследването на ETH Zurich за repository context files установява увеличение на разходите от постоянно активни context файлове без последователно повишение в успеха, включително 20% до 23% по-висок inference cost от LLM-generated файлове в цитираните benchmarks. Собствената препоръка на Claude project memory да остава кратка е правилният инстинкт.

Компромисът е дългосрочен prompt tax срещу recall. В AI workflow automation запазвам устойчиви правила, IDs и факти за средата. Не запазвам всяко наблюдение. Ако зареждате всичко при всяка сесия, просто премествате overflow от днешното изпълнение в стартовия prompt на утрешното.

The trade-offs by criterion

Overflow protection

Тук budgeting печели. Offloading и summary от subagents спират растежа на token-ите, преди window-ът да се замърси. Compaction помага едва след като проблемът вече съществува.

Goal preservation

Todo-state е най-директната защита между compaction циклите, а structured compaction е защитата по време на reset. Ако трябва да избера едно решение за дълги coding или ops агенти, бих комбинирал и двете и бих държал целта във файл, а не само в chat history.

Cross-session continuity

Memory печели, но само когато workflow-ът се повтаря. При еднократни задачи persistent memory е просто допълнителен багаж. При повтарящи се AI automation agents, които работят по support опашки, cloud задачи или analytics pipelines, то започва да има смисъл.

Engineering effort

Budgeting обикновено е най-бързото подобрение с висока стойност. Compaction изисква повече работа по evaluation. Memory изисква най-много оперативна дисциплина, защото остарелите факти остават, ако никой не поеме поддръжката им.

What teams should implement first

Ако изграждах custom AI agents за production това тримесечие, бих внедрил runtime контролите в следния ред:

Първо budget-вайте context-а с твърди прагове за големи tool outputs и file reads.
Добавете compaction като втора стъпка със структурирано summary, което изрично пази intent, constraints, artifacts и next steps.
Включете todo-state като трета стъпка за workflow-и, които се разклоняват, чакат или работят достатъчно дълго, за да се получи drift.
Добавете persistent memory накрая само за workflow-и, които се повтарят между сесиите.

Неочевидната част е тестването. Не чакайте реален overflow. Задействайте compaction рано в staging, умишлено премахнете чрез summary един възстановим факт и проверете дали агентът може да си го върне от storage. Ако не може, системата не е готова за production, независимо от модела.

Verdict

Изберете context budgeting, ако основният ви проблем е раздут prompt от tools и документи. Изберете compaction, ако задачата със сигурност ще надрасне window-а и можете да инвестирате в evals. Изберете todo-state, ако агентът губи нишката между стъпките. Изберете memory, ако същият workflow се връща утре и повтарящото се откриване на информация е истинският разход.

За повечето екипи правилният отговор не е един механизъм. Той е budgeting първо, compaction второ и след това селективно recitation или memory там, където trace-овете оправдават допълнителната цена.