← Блог

Личная корпорация: сотрудники живут в компьютере

Сережа Рис · 12 February 2026

agentsавтоматизация

У тебя уже есть агенты. Один пишет код, другой ревьюит, третий генерит контент. Ты жонглируешь ими вручную — открыл терминал, дал промпт, дождался, проверил, перешёл к следующему. Это работает. Но не масштабируется.

Я хочу построить систему, где задачи ставятся в очередь, а агенты подхватывают их сами. Без моего пинга. Как в реальной компании — CEO задаёт направление, а отделы работают автономно.

Это концепция “личной корпорации”. Я пока ничего не построил — только исследую, как это сделать правильно.

Проблема: ты — узкое горлышко

Типичный день вайбкодера: открыл Claude Code, попросил агента пофиксить баг. Пока ждёшь — переключился на Telegram, ответил подписчику. Вернулся — агент закончил. Теперь нужно написать пост. Открыл новую сессию, дал промпт. Ждёшь.

Ты координируешь всё руками. Каждый агент ждёт твоей команды, а каждая задача начинается с твоего “сделай”.

В реальной компании так не работает. CEO не стоит над каждым сотрудником. Есть очередь задач, зоны ответственности, процессы. Задача появилась — нужный человек подхватил.

Я хочу так же, только вместо людей — агенты.

Идея: event-driven архитектура для одного человека

Event-driven — это когда система реагирует на события, а не ждёт команд. Новый issue в GitHub — агент подхватил и начал разбирать. Пришло письмо — другой агент классифицировал и ответил. Ты запушил пост в блог — третий сам сделал анонс в Telegram.

Архитектура выглядит так:

┌─────────────────────────────────────────────────┐
│                  CEO (ты)                       │
│  Ставишь цели. Создаёшь задачи. Проверяешь.    │
└──────────────────────┬──────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────┐
│          Очередь задач (GitHub Issues)          │
│  Labels = отделы   │   Priority = срочность     │
│  Events = триггеры │   Assignee = владелец      │
└──────────┬──────────┴──────────┬────────────────┘
           │ issue:labeled       │ issue:created
           │ "content"           │ "bug"
           ▼                     ▼
┌──────────────────┐  ┌──────────────────┐
│  Агент-контент   │  │  Агент-кодер     │
│                  │  │                  │
│  Пишет посты,    │  │  Фиксит баги,    │
│  готовит рассылки│  │  пишет фичи      │
└──────────────────┘  └──────────────────┘
           │                     │
           ▼                     ▼
┌──────────────────┐  ┌──────────────────┐
│  Агент-ревьюер   │  │  Агент-тестер    │
│                  │  │                  │
│  Проверяет       │  │  Запускает       │
│  качество        │  │  тесты           │
└──────────────────┘  └──────────────────┘

Каждый агент подписан на определённые события. Никто не ждёт команды — событие произошло, нужный агент реагирует.

Кейсы: это уже работает у других

Я не первый, кто об этом думает. Вот что нашёл.

Christian Houmann — open-source мейнтейнер. Построил triage-бота на базе Claude Code SDK. Результат: 85 issues закрыто за выходные. 111 issues за месяц. Бот анализирует каждый issue в контексте всего кодобейза, рекомендует действие, готовит ответ. Параллельные агенты обрабатывают несколько issues одновременно.

85 issues за уикенд. Один человек.

По-моему, главное тут даже не количество. А то, что Christian не сидел над каждым issue. Система работала, пока он занимался другими делами.

Federico Viticci из MacStories запустил OpenClaw на M4 Mac mini. Агент интегрирован с Notion, Todoist, Gmail, умным домом. Общение через Telegram. За неделю — 180 миллионов токенов. Не чат-бот. Цифровой коллега, который работает 24/7 на собственном железе.

Автономные переговоры. Соло-предприниматель дал агенту задачу: купить машину дешевле. Агент изучил Reddit, связался с дилерами, вёл email-переписку. Выторговал скидку $4,200 на автомобиль за $56,000. Пока владелец был на совещании.

Но есть и обратная сторона. Другой пользователь дал агенту слишком широкие права — тот выстрелил 500+ сообщений по всем контактам, включая жену и случайных людей. Не успели остановить.

Одна технология. Одни и те же широкие права. Один сэкономил тысячи долларов. Другой засыпал контакт-лист спамом. Разница — в ширину хорошо написанной спецификации.

Паттерн: competing consumers

В очереди лежат задачи. К ней подключены несколько агентов — кто свободен, тот берёт следующую. Одну задачу обрабатывает ровно один агент, остальные не дублируют работу.

Это competing consumers — паттерн из enterprise-мира, который отлично ложится на масштаб одного человека.

Ты (ставишь задачи)
        │
        ▼
┌──────────────────┐
│  Очередь задач   │──→ Агент 1 (свободен → берёт)
│                  │──→ Агент 2 (занят → пропускает)
│  issue, issue,   │──→ Агент 3 (свободен → берёт)
│  issue...        │
└──────────────────┘

Для меня это значит: накидал десять задач в GitHub Issues перед сном — утром часть уже сделана. Агенты разобрали очередь, пока я спал.

Подробнее про GitHub Issues как реестр задач для агентов писал в Контекст проекта в GitHub Issues.

Маленькие агенты лучше одного универсального

Sudhir Dubey формулирует точно: один агент — одна задача. Узкий scope, ограниченные инструменты, чёткий критерий успеха.

Не нужен один “суперагент”, который делает всё. Нужны маленькие специалисты:

Каждый знает свою зону и реагирует на свои события. Если один упал — остальные продолжают.

Координация: без неё будет хаос

Вот что происходит без координации между агентами:

На personal scale агентов меньше, конфликты реже. Но думать об этом нужно с самого начала. Иначе один агент пофиксит баг, а другой откатит фикс, потому что работает с устаревшей веткой.

Решения есть: общий контекст между агентами, правила владения задачами, очереди с приоритетами. Координация — не самая сложная часть. Но без неё система разваливается.

Как я вижу реализацию

Конкретных шагов пока нет. Но направление такое.

GitHub Issues как центральная очередь. Задачи создаются как issues. Labels определяют, какой агент подхватит. Priority — что делать первым. GitHub уже движется в эту сторону с gh-aw: воркфлоу на естественном языке в markdown, где агенты выполняют задачи через GitHub Actions.

Мгновенная реакция вместо опроса очереди. Агенты подписаны на события: новый issue, смена label, merge. Событие произошло — агент среагировал. Не нужно проверять очередь каждые пять минут.

Всё на своём железе. Агенты живут на моей машине. Данные — мои. Контекст хранится локально. Как у Viticci с его Mac mini: агент крутится 24/7, ничего не утекает в облако.

Асинхронные задачи через MCP. Официальная спецификация Model Context Protocol уже включает механизм для долгих операций — отправил задачу и забыл, результат придёт когда готов.

Промпт, который я дал бы агенту для первого шага:

“Создай GitHub Action, который при появлении нового issue с label content запускает Claude Code агента. Агент читает issue, пишет черновик поста в отдельную ветку, создаёт PR. Я проверяю и мержу. Если issue без label — добавь label triage и назначь triage-агента.”

Цифры

Мне напоминает момент, когда GitHub Actions только появились — казалось, это для больших команд. Сейчас я использую их в каждом проекте. С event-driven агентами вижу похожий цикл.

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

Что может пойти не так

Я не хочу быть наивным.

Контекст теряется. Каждый агент работает в своём окне. Один не знает, что делает другой. Нужен общий контекст — но его ещё нужно построить.

Агенты галлюцинируют. Автономный агент без контроля может натворить дел. Вспомни 500+ сообщений. Ручное одобрение критичных действий — обязательно, хотя бы поначалу.

Стоимость. 180 миллионов токенов в неделю у Viticci — это extreme case с 24/7 ассистентом. Но даже скромный setup стоит денег. Баланс между автономией и бюджетом придётся искать.

Сложность отладки. Когда один агент передаёт задачу другому, а тот третьему — найти, где что сломалось, непросто. Логи и история событий критически важны.

Промпт для защиты от хаоса:

“Перед выполнением любого действия, которое отправляет сообщения людям, меняет данные в production или тратит деньги — остановись и запроси моё подтверждение. Покажи, что собираешься сделать, и жди ответа.”

Следующий шаг

Я не собираюсь строить всё сразу. Начну с одного агента на одну задачу. Один event — одна реакция. Убеждаюсь, что работает. Добавляю второго. Постепенно наращиваю.

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

“Личная корпорация” — это про организацию работы, а не про технологию. Ты — CEO. Агенты — отделы. Очередь задач — клей, который всё соединяет.

Я думаю, для одного человека с промптами и терминалом это станет нормой быстрее, чем кажется.

FAQ

Нужно ли уметь программировать, чтобы построить личную корпорацию из агентов?

Нет. Ты описываешь задачу агенту на естественном языке, он реализует. GitHub Actions, webhooks, конфиги — всё это агент настроит по описанию. Нужно понимать архитектуру — что с чем связано — но не писать код руками.

Чем event-driven агенты отличаются от обычных AI-ассистентов?

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

Сколько стоит запуск такой системы?

Один агент на одну задачу — минимально. API-токены по usage. Локальный сервер (Mac mini, VPS) — от $5/мес. Federico Viticci сжигал 180M токенов в неделю, но это 24/7 ассистент со всеми интеграциями. Начинать можно с нескольких долларов в день.

Как предотвратить ошибки автономных агентов?

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

Читайте также

Об авторе

Подписаться на обновления — @sereja_tech