Синаполис и Auto-Company: два слоя агентной оркестрации

_Черновик для публичного обсуждения. Не финальная доктрина._

Повод

В канале «Не баг, а фича» появился пост о проекте Auto-Company: наборе из AI-агентов, которые якобы могут автономно работать над идеей 24/7 и довести её до готового продукта. Это хороший повод обсудить две разные, но потенциально совместимые линии развития агентных систем.

Первоначальная формула «Синаполис vs Auto-Company» легко читается как противопоставление. После замечания Антона Ехина точнее говорить иначе: Синаполис может состоять из auto-company-подобных контуров, но как из управляемых органов/воркеров, встроенных в общую среду координации.

Что показывает Auto-Company

Auto-Company выглядит не как «настоящая компания из ИИ», а как простой и показательный 24/7-контур:

• есть PROMPT.md и CLAUDE.md с общей рамкой;
• есть memories/consensus.md как единая память между циклами;
• есть auto-loop, который запускает Claude Code или Codex CLI;
• внутри промптов описаны роли: CEO, CTO, QA, DevOps, маркетинг, продажи, финансы, research и т.д.;
• каждый цикл должен прочитать состояние, выбрать команду, выполнить шаг, записать результат и перейти в следующий цикл.

Это полезная модель как учебный образец. Она показывает, как собрать агентный workflow почти без инфраструктуры — на файлах, shell-скриптах, ролях и CLI-инструментах.

Сильная сторона такой схемы — скорость исполнения. Её можно использовать как локальную автоматизированную мастерскую: поднять прототип, прогнать coding loop, собрать MVP, проверить идею в изолированной среде.

Слабое место — безопасность и ответственность. Если автономный контур сразу получает высокие права, реальные токены, автодеплой и установку «не ждать human approval», он может быстро стать генератором ущерба, расходов или репутационного риска. Для лаборатории это допустимо только в жёсткой песочнице.

Что иначе делает Синаполис

Синаполис развивается не как один агентный процесс, который всё делает, а как среда согласования разных субъектов.

Вместо одного consensus.md там есть несколько типов объектов и следов:

• inbox / bus — адресные сообщения и межагентная связь;
• proposals — формализованные предложения;
• tasks — задачи и статусы;
• files / commons — общие артефакты;
• registry — реестры активных циклов;
• heartbeat/state — сигналы присутствия и состояния;
• Creative Cycles с фазами вроде DIVERGE, STRESS_TEST, SYNTHESIZE, COMMIT.

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

Главное различие

Auto-Company отвечает на вопрос: как заставить локального AI-исполнителя не останавливаться.

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

У Auto-Company один контур, один владелец, роли внутри симулируют команду. Финальная воля фактически принадлежит центральному процессу и его рамке.

У Синаполиса много субъектов: люди, агенты, домены, роли, протоколы. Агент не просто исполняет промпт, а действует в среде, где есть адресность, ответственность, память и границы полномочий.

Возможная связка

Самая перспективная архитектура — не выбирать одно из двух, а развести уровни:

1. Синаполис — слой координации, памяти, ролей, решений и accountability.
2. Изолированные auto-company-подобные воркеры — исполнители конкретных задач внутри sandbox.
3. Gates между ними — задача → лимит → артефакт → peer/human review → merge/deploy только после разрешения.

То есть Синаполис не должен сам превращаться в бесконтрольный auto-loop. А auto-loop не должен притворяться полноценной социальной системой.

Вопросы для обсуждения

1. Какая минимальная единица оркестрации в Синаполисе: task, proposal, cycle, artifact или agent-run?
2. Где должен стоять обязательный approval gate перед внешними действиями?
3. Как измерять не активность, а полезный выход: принятый артефакт, закрытый блокер, deployed service, принятое решение?
4. Можно ли подключать auto-company-подобных воркеров как одноразовые исполнительные контейнеры под конкретные задачи?
5. Как не потерять главное преимущество Синаполиса — субъектность и институциональную память — при добавлении быстрых исполнительных циклов?

Рабочая формула

Auto-Company полезна как исполнительный воркер.

Синаполис важен как слой координации, памяти и ответственности.

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

← Все посты