Агенты и субагенты в Claude: как делить задачу на части

Субагент в Claude - это отдельный вызов той же модели с чистым контекстом, своей инструкцией и коротким списком инструментов; командует им главный агент-оркестратор. Дробить задачу имеет смысл на независимых кусках, каждый из которых требует много грязного чтения: поиск по файлам, разбор выгрузки, сверка источников. На редактуре одним голосом, на финальном решении и на расстановке приоритетов схема разваливается, потому что кускам нужен общий контекст и сквозной вкус. Короткое правило: субагент оправдан там, где он съедает тонну материала и приносит одну страницу выводов.

Каждый день в закрытом канале ИИмперии выкладываю, что нового в работе с ИИ: разборы, готовые промпты и связки, шаблоны ролей цифровых сотрудников. Если собираешь свою связку - там проще подглядеть рабочий вариант, чем изобретать с нуля.

Что такое субагент, если объяснять на пальцах?

Представь помощника, которому ты суёшь толстую папку и говоришь: прочитай и принеси одну страницу выводов. Он перелопачивает всю папку целиком, а до тебя доезжает только страница.

Так и устроен субагент. Главный агент ставит задачу, субагент уходит в свой отдельный контекст, там шуршит и возвращается с коротким ответом. Вся грязь чтения остаётся у него.

Своего у него три вещи: системная инструкция (кто он, что делает, чего не делает), короткий список инструментов - поиск, чтение файлов, запуск команд, доступ к базе, - и чистое окно, где нет вашей предыдущей переписки. Он не в курсе, что вы полчаса обсуждали до него, и ради этого незнания всё затевалось.

Отсюда засада, на которую я напоролся первым же вечером. Субагент не помнит разговор, значит, всё нужное ты кладёшь в бриф руками. Я написал ему что-то в духе «проверь тут всё», он ушёл, честно проверил что-то своё, красиво оформил и принёс мне совсем не то, чего я ждал.

Режим работы	Что делает	Когда не подходит
Обычный чат	Ты и модель в одном окне, весь контекст на виду	Задача требует перелопатить много материала - окно забивается мусором
Один агент с инструментами	Модель сама ищет, читает, запускает, всё складывает в свой контекст	Долгая задача: к середине контекст переполнен и качество плывёт
Оркестратор и субагенты	Главный раздаёт куски, субагенты возвращают сжатые результаты	Работа требует сквозного тона и накопленных решений - куски не склеятся

Пара слов про термины, чтобы дальше не путаться. Агентом называют модель, которой дали инструменты и цель: дальше она сама выбирает последовательность шагов; про это подробнее в разборе того, что вообще считается ИИ-агентом в бизнесе. Когда такого агента вызывает другой агент и даёт ему узкую задачу с обязательством вернуть результат в оговорённом виде, без права на самодеятельность, - перед тобой субагент.

Зачем дробить, если контекст и так огромный?

Потому что большое окно и живое внимание - разные вещи. Токенов помещается как в книгу, спору нет. Вопрос в том, что модель из этой книги держит в голове ровно в тот момент, когда формулирует вывод.

Сигналы всегда одни и те же. Модель ссылается на то, что мы отменили двадцать сообщений назад. Ответы становятся длиннее и обтекаемее - верный знак, что её понесло по кругу. А потом я ловлю себя на вопросе «ты помнишь, что мы решили?», и вот на нём уже пора дробить, дальше будет только хуже.

Дальше начинается история с ошибками. В одном длинном чате кривой вывод на третьем шаге тихо переезжает во все следующие, и к десятому ты чинишь всю цепочку. Когда шаг живёт в отдельном окне, косяк остаётся внутри него, и переделывать приходится один кусок вместо целого вечера.

Отдельная выгода - параллельность. Пять источников проверяются одновременно пятью субагентами вместо очереди из одного. На долгом исследовании, где основная работа сводится к чтению, выигрыш по времени видно сразу; на короткой задаче накладные расходы на брифы съедят всё, что ты выиграл.

Про последнее обычно забывают: специализация инструкции. Корректору можно написать три абзаца свирепых правил вычитки, и аналитику они мешать не будут. В одном общем промпте такие правила толкаются локтями и разбавляют друг друга. Тот же принцип, что в фреймворке 4D: чем уже рамка, тем меньше переписываешь за моделью.

Здесь обычно и прилетает возражение: «может, проще один длинный промпт?». Часто да, и этот вопрос стоит задавать себе первым. Один промпт выигрывает, пока весь материал помещается в окно и остаётся живым к моменту вывода. Как только ты начал листать разговор вверх в поисках того, о чём договорились полчаса назад, одним промптом дело уже не обходится.

Где на самом деле экономится контекст?

В одном-единственном месте: на разнице между тем, сколько субагент прочитал, и тем, сколько принёс. Он перелопатил кучу файлов, а в твой контекст лёг короткий список выводов. Читал бы ты те же файлы в основном чате, они осели бы там целиком и лежали до конца разговора.

Отсюда правило приёмки, которое я проверяю первым: сравни объём входа с объёмом выхода. Гора материала, ужатая до абзаца, вызов окупает. Когда на выходе оказывается примерно столько же, сколько было на входе, ты добавил лишний слой и заплатил за него дважды.

Я сам на этом обжёгся. Вынес в субагента написание раздела статьи. Гениально же: отдельная роль, отдельная инструкция, всё как у взрослых. Только текст по определению возвращается целиком, так что сжатия не случилось, вышла обычная пересылка. Сэкономил, называется 😏

Кандидатов на вынос легко узнать по глаголам: найди, собери, проверь, сверь, отфильтруй, посчитай - всё это сжимает материал. Формулировки вроде «реши», «выбери», «сформулируй позицию», «напиши финальную версию» держи при себе: такие задачи либо порождают текст, либо требуют всей картины разом.

Отдельная песня - большие выгрузки. Таблица на десятки тысяч строк убивает основной контекст мгновенно, а субагент прогонит её у себя, вернёт короткую сводку и уйдёт. Механика такого разбора разложена в материале про то, как Claude работает с таблицами и формулами - там же видно, где модель считает, а где делает вид.

Хочешь пройти путь по порядку, а не кусками - забирай бесплатное обучение, доступ приходит на почту, материалы открываются сразу.

Когда разбиение ломает работу?

Ломается там, где куски нельзя честно склеить.

Самое больное - сквозной тон. Отдай трём субагентам три раздела статьи и получи три статьи. Они по-разному назовут одно и то же, по-разному расставят акценты и обязательно дважды объяснят читателю один термин. Я такое сшивал вручную и потратил больше времени, чем если бы написал сам.

Вторая яма - накопленные решения. Пока агент работает, он принимает десятки мелких решений, которые нигде не записаны: этот кусок данных считаем мусором, такую формулировку не используем, этого клиента выкидываем. Субагент про них не знает и стартует с чистого листа, так что либо выписывай их в бриф явно, либо не дроби.

Третья беда приходит от слишком мелкой нарезки. Когда бриф на задачу длиннее самой задачи, ты занимаешься архитектурой ради архитектуры. Признак простой: субагент вернул то, что ты получил бы одним предложением в обычном чате.

Есть ещё случай, который редко проговаривают вслух, - задачи, где кто-то должен отвечать за итог. Модель за последствия не отвечает в принципе. Растащи работу по ролям - и уже не понять, чей вывод лёг в основу решения. Про границу между «помогает» и «решает» честно написано в тексте про то, чего нейросеть не умеет.

Что должно быть в карточке роли?

Карточка - описание роли, которое читает оркестратор, когда выбирает, кого звать. Обязательных блоков четыре: имя, описание «когда меня вызывать», список разрешённых инструментов, системная инструкция. Пятый формально необязателен, но именно он спасает связку, - жёсткий формат ответа.

Имя. Короткое и функциональное: искатель-по-базе, проверяльщик-фактов, разборщик-выгрузки. Назовёшь «Алексей» или «умный помощник» - оркестратор будет звать его наугад. Он выбирает роль по имени и описанию, больше у него ничего нет.

Описание. Оно работает как правило маршрутизации. «Вызывать, когда нужно найти упоминания темы в базе знаний и вернуть список цитат с источниками; не вызывать для написания текста» - по такому описанию оркестратор попадёт куда надо. От «эксперта по поиску информации» толку ноль.

Инструменты. Давай минимум. Искателю хватит чтения и поиска: с правом на запись он однажды перепишет то, что трогать не просили. Корректору из всего арсенала нужен сам текст, а выданный интернет он потратит не по делу, проверено. Каждый лишний инструмент - ещё одна дорога в сторону, по которой субагент уйдёт исследовать то, о чём его не просили, и спишет на это твои токены.

Инструкция. Тут ты описываешь способ работы: что считать релевантным, что игнорировать, в каком порядке идти, что делать при нехватке данных. Последний пункт критичен. Без явного «не нашёл - так и напиши, не придумывай» модель заполнит пустоту гладким текстом, и ты этого не заметишь.

Формат ответа. Задавай буквально. «Верни от трёх до семи пунктов, в каждом - утверждение, источник в виде пути к файлу и уровень уверенности; ничего кроме списка не пиши». Свободная форма - главная причина, по которой связки разваливаются на третьей задаче.

Если роли кочуют из проекта в проект, выноси их в общую библиотеку и обращайся с ними как с цифровыми сотрудниками, у каждого свой участок и свой регламент.

Как поставить задачу субагенту?

Бриф субагенту - это техзадание подрядчику, который не был на планёрке. Цель одним предложением, входные данные с точными адресами, границы, формат результата, правило поведения при нехватке информации. Всё, что ты не написал, он допридумает по-своему. Вредности тут нет, ему просто нечем заполнить дырку.

Бриф в духе «проанализируй продажи за квартал» гарантирует лотерею. Рабочий вариант выглядит так:

Цель: найти в выгрузке заказов позиции, по которым маржа упала больше чем на четверть к предыдущему кварталу. Вход: файл orders_q3.csv, колонки sku, revenue, cost, date. Границы: не считай позиции, где меньше десяти заказов за квартал. Не делай выводов о причинах. Выход: markdown-таблица sku | маржа было | маржа стало | число заказов, отсортированная по величине падения. Ничего кроме таблицы. Если данных не хватает: верни строку «недостаточно данных» и перечисли, чего не хватает.

Между этими двумя брифами лежит вся разница между связкой, которая работает сама, и той, что каждый раз доделывается руками.

Строка про границы стоит там неслучайно: причины ищет оркестратор, у которого на руках вся картина. Субагент со своим куском начнёт угадывать, причём угадает очень уверенно.

Отдельно про адреса. «Посмотри в базе» - это намёк. Адрес выглядит иначе: «открой база/клиенты/2026.md, секция „Отток”». Чем точнее адрес, тем меньше субагент бродит и тем дешевле обходится. Если база разложена аккуратно, адреса пишутся сами; как её разложить, разобрано в материале про то, как собрать базу знаний для нейросети.

И последнее: одна задача - один субагент - один ответ. Не проси его сначала найти, потом оценить, потом предложить. Это три разные рамки, и на третьей он начнёт подгонять оценку под собственное предложение. Ну попробуй, сам увидишь.

Кого выносить первым?

Тех, кто перелопачивает гору материала ради нескольких строк ответа: поиск, сверка, разбор выгрузок, проверка фактов. Они дают самую заметную разгрузку контекста и меньше всего страдают от того, что не видят общей картины. Творческое и решающее держи в основном контексте, пока не нащупаешь границы схемы руками.

Роль субагента	Что делает	Когда не подходит
Искатель	Прочёсывает базу или файлы, возвращает цитаты с адресами	Когда найденное нужно ещё и истолковать
Разборщик данных	Гонит выгрузку, считает агрегаты, возвращает сводку	Данные грязные и решение «что считать мусором» меняет ответ
Проверяльщик фактов	Сверяет утверждения с источниками, помечает сомнительные	Тема без твёрдых источников: вернёт уверенную выдумку
Корректор	Вычитывает готовый текст по чек-листу правил	Нужна смысловая редактура: задачи он не видел
Сборщик сводки	Собирает разрозненные отчёты в одну страницу	Источники противоречат друг другу - нужен человек или оркестратор
Наблюдатель за форматом	Проверяет, что результат соответствует шаблону	Шаблон не формализован: «должно быть красиво» не проверяется

Отдельно скажу про проверяльщика - самая недооценённая роль из всех.

Такой субагент читает результат другого с единственной инструкцией «найди, где утверждение не подкреплено источником», и от него требуется только ткнуть пальцем в слабое место. Ему я верю больше, чем автору текста: у него нет мотива защищать написанное. По-настоящему это работает при одном условии - проверяльщику отдают исходники вместе с выводом предыдущей роли. Иначе он сверит пересказ сам с собой и радостно поставит галочку.

Сборщика сводки удобно обкатывать на регулярной задаче, где формат один и тот же каждый день. Как это устроено на практике, показано в разборе ежедневной сводки на Claude: там видно, как страница собирается из независимых кусков без ручной склейки.

Веером или цепочкой?

Веер годится на независимых кусках: источники, регионы, товарные группы. Цепочка нужна там, где второй шаг начинается только после того, как первый что-то нашёл. Смешивать их можно, но осознанно - сначала веер, потом последовательная сборка.

Веер выигрывает время и расплачивается согласованностью. Субагенты работают одновременно и друг о друге не знают, поэтому спокойно вернут тебе пересекающиеся ответы, а то и противоречащие. Я мирил такое вручную и вынес одно: у оркестратора должно быть право сказать «данные противоречивы» вместо того, чтобы усреднять. Усреднённая чушь выглядит убедительнее исходной.

Цепочка вытягивает качество, но обходится дороже по времени и по живучести: каждое звено становится точкой отказа. Второе вернуло мусор - третье честно обработает мусор и передаст дальше с умным видом. Поэтому в цепочке обязателен контроль на стыках: оркестратор смотрит результат по формату и по здравому смыслу, и только потом отдаёт следующему.

Короткая цепочка ведёт себя предсказуемо, длинная требует лога на каждом шаге, а с какого-то момента перед тобой уже целая система, которую нельзя запускать без проверки на выходе. Если тянет удлинять, скорее всего часть шагов надо слить в один или вообще вынести из модели в скрипт: там, где логика жёсткая, код на Python дешевле и надёжнее любой модели.

Откуда берётся испорченный телефон между агентами?

Субагент возвращает пересказ, оркестратор принимает этот пересказ за факт, а следующий субагент получает его уже как исходные данные. Три перехода - и первоисточник потерян, зато формулировка звучит всё бодрее.

Механика поломки простая: каждое сжатие съедает оговорки. «В паре файлов встречается упоминание, ещё в одном контекст неясен» превращается в «упоминается в базе», а потом в «подтверждено базой». Вранья ни на одном шаге не было, просто осторожность отваливалась по дороге. Поэтому уровень уверенности я зашиваю прямо в формат ответа - у оговорки появляется шанс пережить сжатие.

Второй источник вранья - вежливость. Субагент, который ничего не нашёл, норовит вернуть хоть что-то похожее на ответ: пустой результат выглядит как невыполненная задача, а он старается. Снимается одной фразой в карточке: «пустой результат - нормальный результат, возвращай его без объяснений и без предположений».

Ещё врут задачи, которые расползлись. Дал широкие инструменты и расплывчатую цель - получил соседнюю работу: просил найти, а он ещё и починил. Умница, конечно, только оркестратор ждал совсем другой объект и теперь давится тем, что приехало.

Проверка делается за минуту. Берёшь финальный вывод и просишь показать цепочку до первоисточника. Если хоть одно звено отвечает «это было в предыдущем результате» - у тебя в системе живёт непроверяемое утверждение. Почему модель звучит уверенно на пустом месте, разобрано в тексте про то, почему Claude врёт.

Сколько это стоит и где ты переплачиваешь?

По токенам субагенты почти всегда дороже одного длинного чата: каждый заново читает свою инструкцию и свой кусок входа, то есть ты платишь за дубли. Зато по времени и по количеству ручных правок связка выходит дешевле, и оправдывает её ровно одно - способность сжимать материал в разы.

Течёт обычно в трёх местах.

Первое - раздутые инструкции. Карточка размером с реферат, а зовут её на каждом шаге, значит, ты оплатил этот реферат столько раз, сколько было шагов. Держи инструкцию в пределах экрана.

Дальше идёт поиск без границ: субагент без адресов читает подряд, и половина прочитанного к делу не относится. Он же не знает, где лежит нужное, ты ему не сказал.

И лишние звенья, у которых на выходе почти то же, что было на входе. Чинить такое звено бессмысленно, его убирают.

Лечится это скучно и надёжно. Кэшируй стабильную часть промпта: пока инструкция роли не меняется, повторное чтение обходится дешевле. Формат выхода задавай жёсткий и короткий, потому что длинный ответ стоит дороже и заодно засоряет контекст оркестратора. Детерминированные шаги вообще выноси в обычный код: фильтрация таблицы по условию интеллекта не требует, а сравнение макросов с ИИ показывает, где проходит граница.

Про главный соблазн уже говорил выше, повторю коротко: архитектура из пяти ролей выглядит серьёзно и греет самолюбие, а платят за неё токенами на каждом прогоне. Выбор между «собрать самому» и «взять готовое» тоже не праздный, про него есть разбор ИИ-агентов под ключ против самосборки.

Как понять, что разбиение сработало?

Смотри на измеримое: сколько правок внёс руками, насколько чистым остался основной контекст к концу, повторяется ли результат на втором прогоне, стало ли быстрее. Ничего не сдвинулось - разбиение было лишним. Собирай обратно, это нормально.

Самый честный тест - три прогона на одном входе. У устойчивой связки результаты совпадут по сути, разойдутся разве что формулировки. Три разных вывода означают, что кто-то в цепочке домысливает, и виновник ищется просто: сравни промежуточные ответы между прогонами и найди звено, на котором они разъехались.

Второй тест мне нравится больше всех. Подсунь заведомо плохой вход: пустой файл, битую выгрузку, вопрос про то, чего в базе нет. Здоровая связка ответит «недостаточно данных» и перечислит, чего не хватает. У сломанной на том же входе появляется уверенный текст про несуществующее. Прогоняй этот тест на каждой роли отдельно, до того как соберёшь их вместе, иначе потом не разобрать, кто врёт.

Третий тест - прослеживаемость, про которую шла речь выше: любой финальный вывод должен раскручиваться до первоисточника. Если раскручивается, связке можно отдавать рутину. Обрыв на любом звене держит её потолок на уровне черновиков.

И записывай результаты проверок туда же, где лежат карточки. Через месяц ты не вспомнишь, почему у корректора отобран интернет, вернёшь его обратно и наступишь на те же грабли. Регламент роли и история её граблей живут в одном файле.

Симптом	Что сломано	Что делать
Три прогона дают три разных вывода	Где-то в цепочке домысливание	Найти звено по промежуточным ответам, ужесточить формат выхода
Финал звучит увереннее промежуточных результатов	Потеря оговорок при сжатии	Ввести уровень уверенности в обязательный формат ответа
Субагент делает соседнюю работу	Широкие инструменты и расплывчатая цель	Урезать список инструментов, дописать явные запреты
Правок руками столько же, сколько было	Разбиение не там, где надо	Собрать в один контекст, вынести только чтение
Ответ красивый, источников нет	Не потребованы адреса	Формат: утверждение плюс путь к источнику, иначе не принимать

Чем субагент отличается от цифрового сотрудника?

Субагент - техническая единица внутри одной задачи: вызвали, отработал, забыл. За цифровым сотрудником стоит роль, которая живёт месяцами, со своим участком, регламентом, накопленной памятью и историей решений. На сборку субагента уходит вечер, роль сотрудника набирает вес по ходу работы, и подменять одно другим дорого.

Разница вылезает на вопросе «что останется завтра». После субагента не остаётся ничего, кроме ответа, и для него это норма, потому что чистый контекст - его главное свойство. Цифровой сотрудник копит базу: что уже пробовали, какие формулировки запрещены, кто наш клиент, каким голосом мы разговариваем. Без такой памяти роль каждое утро стартует с нуля и снова наступает на те же грабли.

На практике они вкладываются друг в друга: сотрудник-аналитик запускает внутри себя трёх субагентов на три выгрузки, а результат кладёт в общую память. Субагенты тут работают руками, сотрудником роль делает именно память, сколько бы исполнителей под ней ни крутилось.

Где проходит граница между рабочей ролью и красивой фантазией, разобрано в материале про цифрового двойника сотрудника: регламент живого человека переносится в модель отлично, а на попытках скопировать саму личность всё обычно и заканчивается.

Где во всей этой схеме всё равно нужен ты?

В трёх местах, и ни одно не автоматизируется: поставить цель, принять результат, ответить за последствия. Дробить и собирать работу модель умеет отлично, вот только зачем ты эту работу делаешь, ей неизвестно.

Цель - это про приоритеты и вкус. Какой из трёх найденных вариантов подходит твоему бизнесу, какой тон допустим, на что ты пойдёшь, на что нет. Субагент вернёт варианты с плюсами и минусами, и на этом его работа заканчивается: выбор остаётся за тобой. Так и должно быть.

В приёмке работает обычный здравый смысл. Связка выдаст безупречно оформленный отчёт, в котором перепутаны два периода, и внутренняя проверка этого не поймает: формально всё сходится. Человек, знающий бизнес, видит несостыковку за секунду и спрашивает «а это точно третий квартал?».

С ответственностью всё просто и неприятно: отправил клиенту неверные цифры из-за вывода связки - отвечаешь ты, Claude тут ни при чём. Поэтому договоры, цены и обещания клиентам проходят через живые глаза перед отправкой. Как выстроить такую вычитку осмысленно, показано в разборе про то, как вычитывать документ с Claude: модель помечает места, где стоит насторожиться, и дальше всё упирается в человека, который ставит подпись.

С чего собрать первую связку за вечер?

Возьми одну регулярную задачу с большим объёмом чтения и минимумом решений, и вынеси наружу ровно один кусок чтения. Схему из пяти ролей сразу не строй. От первой связки нужно понимание, в каком месте она ломается, и уже следом подтянутся рабочие результаты.

Шаг 1. Выбери задачу. Делаешь её не реже раза в неделю, в ней есть этап «перелопатить материал» и этап «принять решение». Подойдёт подготовка еженедельной сводки, разбор обращений в поддержку, сверка прайса с сайтом.

Шаг 2. Разметь этапы. Выпиши шаги как есть, без улучшений. Напротив каждого пометь: сжимает материал или порождает. Первый попавшийся «сжимает» - твой кандидат.

Шаг 3. Напиши карточку одной роли. Имя, когда вызывать, два-три инструмента, инструкция в пределах экрана, жёсткий формат ответа, фраза про пустой результат. Больше в первую карточку не клади ничего, честное слово.

Шаг 4. Прогони руками три раза. На нормальном входе, на пустом, на битом. Смотри только на две вещи: держится ли формат и признаётся ли модель в нехватке данных. Красота ответа тут не значит вообще ничего.

Шаг 5. Замерь разницу. Сколько правок руками, сколько времени, остался ли основной контекст пригодным к концу. Разницы нет - откати и вынеси другой шаг. Без сожалений.

Шаг 6. Вторую роль добавляй только после этого. Почти всегда это проверяльщик: читает результат первой и ищет неподкреплённые утверждения. Связка из искателя и проверяльщика простая, понятная, и к ней можно возвращаться годами.

Работаешь через терминал - всё это ложится на готовый механизм: карточки хранятся файлами рядом с проектом и вызываются из общей сессии, про инструмент есть отдельный разбор, что такое Claude Code и зачем он нужен. Без терминала та же схема собирается вручную в обычном чате: ты сам играешь оркестратора и таскаешь результаты между окнами. Выходит медленнее, зато на первой связке разница непринципиальна, а понимание появляется то же самое.

А теперь вопрос в зал: у кого субагенты уже крутятся - что взлетело, а что пришлось собирать обратно в один чат? Мне правда интересно, на каком месте у людей ломается раньше всего: на тоне, на накопленных решениях или на том самом испорченном телефоне. Пиши в канал, обсудим.

Источники

• Subagents в документации Claude Code - официальное описание карточек ролей, полей и правил вызова.
• Anthropic Academy - курсы Anthropic по работе с моделью, включая раздел про субагентов.
• Building effective agents - инженерный разбор паттернов: цепочки, маршрутизация, оркестратор с воркерами.
• Multi-agent research system - как устроена веерная схема с параллельными субагентами и где она проседает.
• Effective context engineering for AI agents - про деградацию внимания в длинном контексте и работу со сжатием.
• Claude Code best practices - практики постановки задач и организации файлов проекта.
• Tool use overview - как модель получает инструменты и почему их список стоит ограничивать.
• Prompt caching - механика переиспользования стабильной части промпта между вызовами.
• Context windows - справка по устройству окна контекста и подсчёту токенов.
• Claude Agent SDK - если связку нужно вынести из чата в свой продукт.
• Model Context Protocol - стандарт подключения внешних источников данных к агентам и субагентам.