Building agent systems that hold up outside a demo — and the boring infrastructure that makes them hold up. Astana, Kazakhstan.
Most of what I work on comes down to one problem: an LLM agent is impressive for ten minutes and unreliable for ten hours. It forgets standing instructions, answers from memory instead of calling the tool that would give a real answer, and will happily run a destructive command. Those are engineering problems with engineering answers, and that is what I build.
futigis-agent-kit — production hooks, subagents and skills for Claude Code Six hooks covering the three ways a long agent session degrades: instructions decay (re-injected on every prompt instead of read once), destructive commands (blocked before execution, not asked about), and unvetted external code (a security audit is made mandatory). Plus ten scoped subagents, session memory loading, and a Telegram bridge for working away from the desk.
kz-data-mcp — MCP server for Kazakhstan reference data Official National Bank exchange rates and ИИН/БИН validation, over the Model Context Protocol. Zero dependencies; the protocol is implemented directly against the spec, so version negotiation, notification handling and the two distinct error channels are all visible in ~150 lines. The identifier validator documents what its check digit cannot catch — the 11th digit carries weight 11, and 11 ≡ 0 (mod 11), so it is structurally unprotected.
kaspi-shop-analytics — marketplace unit economics Resumable fetch over the Kaspi.kz Shop API, working around undocumented limits found by probing a live account. Computes contribution per product — the number that decides whether a product is worth selling, which revenue alone never tells you. Runs on generated demo data with no merchant token.
A check that cannot fail is worse than no check. In the analytics tool, the gap between the P&L and cash-flow views is an algebraic identity — it holds for any inputs, including wrong ones. It would have looked great reported as a passing reconciliation. It is labelled as an identity instead, and the actual checks compare against data the tool did not produce: bookkeeping totals, a physical stock count. Those can fail, so they are worth printing.
Test the claim, not the code. Writing tests for the ИИН validator turned up single-digit corruptions that passed. The code was right; my assumption about the algorithm was wrong. The test now asserts that every surviving case is explained by one of two structural properties of the scheme — so a real regression can't hide behind "checksums are imperfect".
Probe the API, don't trust the docs. Every non-obvious limit in the Kaspi client — the 100-item page cap, the ~14-day range ceiling, the SKU data already embedded in order entries — came from hitting the live endpoint and reading what came back.
Python · TypeScript · Node · PostgreSQL · MCP · Claude Code
По-русски
Строю агентные системы, которые работают не только на демо, — и ту скучную инфраструктуру, благодаря которой они работают. Астана, Казахстан.
Почти всё, чем я занимаюсь, сводится к одной задаче: LLM-агент впечатляет десять минут и подводит десять часов. Он забывает постоянные инструкции, отвечает по памяти вместо того чтобы вызвать инструмент с реальным ответом, и спокойно выполнит разрушительную команду. Это инженерные проблемы с инженерными решениями — их я и строю.
futigis-agent-kit — боевые хуки, субагенты и скиллы для Claude Code. Шесть хуков закрывают три способа, которыми деградирует длинная сессия: инструкции выветриваются (вклеиваются в каждый запрос, а не читаются один раз), разрушительные команды (блокируются до выполнения, а не выносятся на согласование) и непроверенный внешний код (аудит становится обязательным). Плюс десять субагентов с урезанным доступом к инструментам, загрузка памяти на старте сессии и мост в Telegram для работы вдали от компьютера.
kz-data-mcp — MCP-сервер для казахстанских справочных данных. Официальные курсы Нацбанка и проверка ИИН/БИН по протоколу Model Context Protocol. Без зависимостей: протокол реализован напрямую по спецификации, поэтому согласование версий, обработка уведомлений и два разных канала ошибок видны в полутора сотнях строк. Валидатор документирует, чего его контрольная сумма поймать не может: одиннадцатая цифра имеет вес 11, а 11 ≡ 0 (mod 11) — то есть структурно ничем не защищена.
kaspi-shop-analytics — юнит-экономика маркетплейса. Возобновляемая выгрузка через Kaspi.kz Shop API в обход недокументированных ограничений, найденных обстрелом живого аккаунта. Считает вклад в разрезе товара — ту цифру, которая решает, стоит ли товар продавать, и которую выручка никогда не показывает. Запускается на сгенерированных демо-данных без токена продавца.
Проверка, которая не может упасть, хуже, чем её отсутствие. В аналитике разрыв между P&L и денежным потоком — алгебраическое тождество: оно верно при любых входных данных, включая неверные. Оно отлично смотрелось бы как «сверка пройдена». Вместо этого оно помечено как тождество, а настоящие проверки сравнивают с данными, которые инструмент не производил: итог бухгалтерии, физический пересчёт склада. Вот они упасть могут — их и стоит печатать.
Проверяй утверждение, а не код. Тесты валидатора ИИН вскрыли одиночные искажения, которые проходят проверку. Код был прав — неверным было моё представление об алгоритме. Теперь тест требует, чтобы каждый такой случай объяснялся одним из двух структурных свойств схемы: тогда настоящая регрессия не спрячется за фразой «контрольные суммы несовершенны».
Обстреливай API, не верь документации. Каждое неочевидное ограничение в клиенте Kaspi — потолок в 100 позиций на странице, лимит диапазона в ~14 дней, данные о товаре, уже вложенные в позиции заказа — получено ударом по живому эндпоинту и чтением того, что вернулось.