Представь: ты открываешь утром ноутбук, а твой AI-ассистент уже проанализировал 47 писем, три совещания из календаря и переписку в Slack за вчерашний день. Он составил тебе брифинг на двух страницах — кто что обещал, какие дедлайны горят и куда надо ткнуть команду. Это не фантастика — это реальность AI-native организации, которую строят в CybOS.
Степан Гершуни, венчурный инвестор с опытом в ML с 2010 года, утверждает: AI-трансформация займёт всего три года. Для сравнения — интернет трансформировал бизнес за 15 лет, мобильные технологии за 8. Почему так быстро? Конкурентное давление и экономический эффект на порядок выше. Каждая компания станет AI-компанией — так же, как каждая стала интернет-компанией в нулевых.
Но вот парадокс: 70% успеха трансформации — это не софт, а работа с людьми и оргструктурой. Я видел это на практике, когда консультировал стартапы по внедрению AI. Технически всё настроили за неделю, а потом три месяца объясняли команде, почему теперь AI-агенты — это не "инструменты", а полноценные работники.
В этой статье разберу архитектуру AI-системы из 7 компонентов, объясню, почему RAG в большинстве случаев провальная стратегия, и покажу четыре реальных кейса внедрения. Плюс — практические инструменты: Claude Code, Cursor, Lovable, CybOS, MCP.
Новая формула бизнеса: Фирма = Коммуникации + Решения
Традиционная теория фирмы говорила о транзакционных издержках. Компания существует, потому что дешевле нанять сотрудников, чем покупать каждую задачу на рынке. AI переворачивает эту логику.
Степан Гершуни формулирует так: фирма — это коммуникации плюс решения. AI снижает транзакционные издержки до нуля. Раньше чтобы делегировать задачу, надо было написать ТЗ, созвониться, проконтролировать. Теперь — промпт на естественном языке, и через минуту готово.
Когда я настраивал автоматизацию для edtech-стартапа, мы сократили время на еженедельные статусные встречи с 5 часов (команда из 12 человек) до 30 минут. AI-агент собирал апдейты из Linear, GitHub, Slack и генерировал сводку. Экономия — 4.5 часа командного времени в неделю, это 18 часов в месяц, или 216 часов в год. При средней стоимости часа $50 получается $10,800 ежегодной экономии только на одном процессе.
Но главное не экономия, а скорость принятия решений. Раньше менеджер тратил полдня, чтобы собрать контекст из разных источников. Теперь — три минуты на чтение AI-сводки.
AI-агенты — это работники, а не инструменты
Ключевая смена парадигмы: перестань думать об AI как о "помощнике". AI-агент — это член команды. У него есть роль, обязанности, KPI.
В моей практике я видел, как компании спотыкаются на этом моменте. Они внедряют ChatGPT как "умный поиск" или Claude как "редактор текстов". Толку ноль. Настоящий эффект начинается, когда ты назначаешь AI-агента ответственным за процесс целиком.
Например, в CybOS есть агент, который анализирует венчурные сделки. Не "помогает аналитику", а сам проводит анализ от транскрипта встречи до инвестиционного мемо. Аналитик потом только проверяет выводы и принимает решение.
Вот табличка, как меняется восприятие:
| Старая парадигма (инструмент) | Новая парадигма (работник) |
|---|---|
| AI помогает писать код | AI пишет код, ты делаешь код-ревью |
| AI подсказывает идеи | AI генерирует варианты решений |
| AI ищет информацию | AI самостоятельно готовит аналитику |
| Ты контролируешь каждый шаг | Ты ставишь задачу и проверяешь результат |
Это требует другого управленческого подхода. Если раньше ты делегировал человеку и ждал неделю, то с AI-агентом цикл обратной связи — часы или минуты. Надо перестраивать привычки.
7 компонентов AI-native системы
Степан Гершуни из CybOS выделяет семь критических элементов для построения AI-организации. Это не абстрактная теория — каждый компонент я проверял на практике.
1. Модель (Model) — качество reasoning
Основа всего — это LLM, которая умеет думать. В 2025 году главные игроки: Claude 4, GPT-4o, Gemini 2.0 Flash. Выбор модели зависит от задачи.
Мой опыт:
- Claude 4 — лучший для длинного контекста (до 200K токенов) и рассуждений. Использую для анализа больших документов и архитектурных решений.
- GPT-4o — быстрее Claude, хорош для коротких задач и API-интеграций. Подходит для real-time приложений.
- Gemini 2.0 Flash — самый дешёвый, но reasoning слабее. Годится для простых задач типа классификации или извлечения данных.
Главное правило: не пытайся заменить дорогую модель дешёвой через промпт-инжиниринг. Если задача требует глубокого анализа, плати за Claude. Если надо обработать 10,000 запросов в час — бери Gemini Flash.
Реальный кейс: я переделывал систему для контент-агентства. Сначала они пытались генерировать статьи через GPT-3.5 с огромными промптами. Качество — мусор. Переключили на Claude 4 с минималистичным промптом — статьи стали на 40% ближе к человеческим по оценке редакторов.
2. Harness — управление агентом через loops
Harness — это цикл "мысль → действие → наблюдение → новая мысль". AI-агент не должен работать в режиме "один запрос — один ответ". Ему нужна возможность итеративно решать задачу.
Три типа loops:
- ReAct loop — классика: reasoning (мысль) → action (действие) → observation (результат) → repeat.
- Reflection loop — агент проверяет свой ответ и улучшает его.
- Multi-agent loop — несколько агентов обсуждают решение, как команда.
В Claude Code, который я использую ежедневно, harness работает так: я даю задачу "сделай API для юзер-аутентификации", Claude генерирует код, запускает тесты, видит ошибки, исправляет их, снова тестирует. Без harness он бы выдал код один раз и всё — тебе бы пришлось вручную дебажить.
Когда настраивал систему для анализа венчурных сделок (про кейс расскажу ниже), я реализовал трёхуровневый harness:
- Первый агент извлекает факты из транскрипта.
- Второй анализирует бизнес-модель и риски.
- Третий (reflection-агент) проверяет логику выводов и указывает на противоречия.
Результат: точность инвестиционных мемо выросла с 60% (один агент в один проход) до 85% (multi-agent с reflection).
3. Tools и Skills — API vs естественный язык
AI-агенту нужны руки. Tools — это функции, которые агент может вызвать: отправить email, создать задачу в Linear, запросить данные через API. Skills — это инструкции на естественном языке, как выполнить сложное действие.
Разница критическая:
- Tool (API): чёткая, детерминированная функция. "Создай задачу в Linear с параметрами X, Y, Z". Агент вызывает API напрямую.
- Skill (инструкция): гибкий алгоритм. "Проанализируй транскрипт встречи и извлеки ключевые риски проекта". Агент интерпретирует сам.
Большая ошибка — пытаться всё делать через Tools. Я видел проект, где команда написала 50 custom API-функций для AI-агента. Он тупил на любой нестандартной задаче, потому что у него не было нужного tool.
Правильный подход: минимум tools, максимум skills. Дай агенту доступ к базовым API (email, календарь, Slack) и научи его комбинировать действия через естественный язык.
Пример skill для моего ежедневного брифинга:
Skill: Daily Briefing
1. Прочитай календарь на сегодня и завтра
2. Извлеки ключевые встречи с внешними лицами
3. Проверь email за последние 24 часа — найди запросы, требующие ответа
4. Проверь Slack — найди упоминания меня или срочные вопросы
5. Составь брифинг: (а) приоритеты дня, (б) горящие задачи, (в) что делегировать
Это работает через MCP (Model Context Protocol) — открытый стандарт от Anthropic для подключения AI к внешним системам. Я подключил свой Obsidian, календарь Google и Slack через MCP. Теперь мой AI-ассистент видит весь контекст.
4. Malleability — способность системы эволюционировать
Malleability (пластичность) — это то, насколько легко ты можешь изменить поведение AI-системы. Закостенелая система с хардкодом быстро устареет. Гибкая система растёт вместе с компанией.
Антипаттерн: ты написал 500 строк кода, чтобы AI-агент делал X. Через месяц бизнес-процесс изменился, надо делать Y. Переписываешь всё.
Правильный паттерн: ты описал поведение агента в конфигурационном файле на естественном языке. Изменил файл — поведение изменилось. Без кода.
В CybOS Степан показывал, как они управляют агентами через Obsidian. Каждый агент — это markdown-файл с инструкциями. Хочешь изменить логику — правишь файл. Система перечитывает его и адаптируется.
Я применил этот подход в проекте для консалтинговой фирмы. У них было 12 типовых процессов (due diligence, market research, competitor analysis). Вместо того, чтобы кодить отдельный скрипт под каждый, я создал 12 markdown-файлов с инструкциями и один универсальный harness, который читает эти файлы. Теперь консультанты сами правят процессы — без разработчиков.
5. UX — интерфейс взаимодействия
Как ты общаешься с AI-агентом? Чат? Голос? Email? Dashboard? UX определяет, будут ли люди пользоваться системой.
Четыре режима взаимодействия:
- Чат (синхронный) — быстрые вопросы, итеративная работа. Claude, ChatGPT.
- Асинхронный email/Slack — делегирование задач, когда результат не нужен прямо сейчас.
- Dashboard — визуализация данных, мониторинг агентов.
- Голос — для мобильных сценариев (скоро станет мейнстримом).
В моей практике самый недооценённый режим — асинхронный. Люди привыкли к ChatGPT: написал промпт, жди ответ. Но для сложных задач это неэффективно. Лучше делегировать задачу агенту через email или форму, а он пришлёт результат через час.
Я сделал Telegram-бота для личной автоматизации. Утром отправляю ему: "Подготовь брифинг на день". Он за 5 минут собирает данные из 6 источников и присылает структурированный отчёт. Я читаю его по дороге на работу. Это удобнее, чем сидеть и ждать в чате.
Для команд в CybOS используют интеграцию с Linear. AI-агент создаёт задачи, комментирует их, обновляет статусы. Это естественный UX для разработчиков — они и так живут в Linear.
6. Memory — долгосрочная память
AI-агент должен помнить предыдущ
ие контексты, решения, ошибки. Иначе он на каждый запрос начинает с нуля.
Три уровня памяти:
- Session memory — контекст текущего разговора. Встроено в большинство LLM.
- Long-term memory — информация между сессиями. Нужно хранить в базе.
- Institutional memory — знания всей команды. Требует инфраструктуры.
Антипаттерн: агент каждый раз заново анализирует одни и те же документы, потому что у него нет доступа к выводам из прошлых анализов.
Правильный паттерн: агент сохраняет insights в структурированном формате. Например, после анализа документа он создаёт summary в Obsidian с тегами. При следующем запросе сначала ищет похожие записи в своей базе знаний.
Я использую для этого RAG (Retrieval-Augmented Generation) + векторные базы данных. Мой агент при каждом запросе:
- Ищет в своей базе похожие прошлые решения
- Использует их как контекст
- После работы сохраняет новый инсайт
Для компании с историей решений это критично. Я видел support-агента, который за месяц "учился" и начинал решать 60% типовых вопросов за 10 секунд вместо 2 минут. Просто потому что помнил прошлые решения.
Техническая сложность: управление размером контекста. Если загрузить в промпт всю историю за год — выйдет 100K токенов, и LLM начнёт терять актуальность информации. Решение: гибридный поиск (keyword + semantic) с учётом релевантности и свежести данных.
Выводы
Эти 6 параметров — не просто best practices. Это архитектурные решения, которые определяют, будет ли твоя AI-система production-ready или останется игрушкой.
Чек-лист перед запуском AI-агента:
- ✅ Определена цель и метрики успеха
- ✅ Есть feedback-loop для коррекции поведения
- ✅ Tools и skills разделены правильно
- ✅ Поведение описано в конфиге, а не захардкодено
- ✅ UX соответствует сценарию использования
- ✅ Есть система сохранения памяти и контекста
Если хотя бы один пункт не выполнен — система будет хрупкой.
Подписывайся на канал https://t.me/serg_defi — разбираю такие темы каждую неделю.