Как устроен AI-PM внутри
Агентный рантайм под вертикаль: рой агентов слушает коммуникации, ведёт сделку и действует от лица команды — с человеком в контуре.
✦
Принцип: детерминированная оркестрация + модельная когниция. Процесс (что за чем, что требует аппрува, куда пишем) — жёсткий аудируемый каркас; LLM зовётся точечно на «умных» шагах. Не один большой агент, который решает всё.
Кликни по любому блоку → разворот ниже с описанием, примером и MVP-стеком.
1
Оркестратор
Событийный durable-исполнитель пайплайнов и точка применения политики автономии. Подбирает пайплайн под событие, исполняет его узлы, умеет встать на паузу на аппруве и продолжиться, и пишет журнал.
in: event envelope out: исполненный пайплайн + журнал действий
жизненный цикл
событие
из коннектора
→
триггер
подбор пайплайна
→
durable-инстанс
исполнение узлов
→
⏸ gate
ждёт аппрув
→
▶ resume
после клика
→
журнал
+ откат
# событие на входе — нормализованный конверт
{ type: "meeting.transcript_ready",
source: "conf://meridian-tech",
dealId: "meridian",
payload: { transcriptId: "…" },
provenance: { ts: "2026-05-20T15:38" } }
🎯 Матч события на пайплайнtrigger-router
⏸ Suspend на gate, resume по аппрувуdurable state
🛡 Политика автономии на каждом узлеpolicy-engine
🧾 Неизменяемый журнал + откатaudit-log
🔒 Сериализация по сделкеper-deal lock
MVP-стекdurable workflow (Temporal / очередь+БД)trigger-routerpolicy-engineaudit-log
2
Конструктор пайплайнов
Процесс = декларативный типизированный граф узлов (YAML), версионируемый. Узлы: agent service connector knowledge gate control: branch/map/loop. Между узлами — JSON-схемы (structured output), сквозь весь граф — провенанс.
in: trigger + inputs out: эффекты (только через gate)
прогон пайплайна «post_meeting_v1» — нажми ▶
extract
agent · извлечь
→
persist
knowledge · записать
→
plan
agent · спланировать
→
gate
аппрув наружу
→
apply
connector · разнести
пайплайн «post_meeting_v1» на встрече «Меридиан» — нажми «Прогнать»
pipeline: post_meeting_v1
trigger: { on: meeting.transcript_ready, filter: { type: customer } }
inputs:
transcript: $event.transcript
deal: $knowledge.deal($event.dealId)
steps:
- id: extract # когниция
agent: meeting_analyst
in: { transcript: $transcript, deal_context: $deal }
out: Extraction # решения/задачи/вопросы/риски + provenance
- id: persist
knowledge: upsert # entity-resolution внутри
in: { deal: $deal.id, facts: $extract }
- id: plan
agent: pm_agent
out: ProposedActions # tasks[], notes[], emails[]
- id: review
gate: { autonomy: act, approve: $plan.emails } # suspend → ждём человека
- id: apply
map: $plan.actions
do: { connector: $item.target, action: $item.op }
records: audit
MVP-стекYAML-DSL + валидатор схемисполнитель графаnode-registrystructured-output контракты
3
Набор агентов
Когнитивные юниты = типизированные функции «схема → схема» поверх LLM. Контекст впрыскивает оркестратор (агент не хранит долгую память) — это паттерн сабагента: узкий контекст + свои тулзы → структурированный результат.
контракт агента
вход
context (из ④) + payload · по схеме
→
🧠 агент
role + tools + LLM
→
выход
structured JSON · валидируется
🎙 Аналитик встречи
структура: решения, задачи, вопросы, риски
тулзы: knowledge.query · автономия: Observe→Structure
📌 PM-агент
задачи, сроки, follow-up, пинги
тулзы: tracker, calendar · автономия: Structure→Act
📚 Архивариус
досье сделки и вики в актуальном виде
тулзы: knowledge, wiki · автономия: Structure
✉️ Коммуникатор
драфты писем, дайджесты, резюме
тулзы: mail (draft) · потолок: только draft
🛰 Наблюдатель
зависшее, обещания вне встреч, эскалации
тулзы: knowledge.query · автономия: Structure→Act
🗣 Ведущий встречи
повестка, тайминг, фиксация на лету
realtime · автономия: Observe
MVP-стекLLM-обвязкаprompt/roletool-bindingstructured outputeval-наборы
4
Внутренние знания
Гибрид по онтологическому статусу: события — то, что реально произошло (immutable, in+out); знания — то, что система поняла/нагенерила (mutable граф нот). Знания ссылаются провенансом в события. Сверху — 2 вектор-индекса.
как лежат знания: вольт-директория + граф связей
/deals/meridian/
├─ _overview.md стадия · бюджет · health
├─ _instructions.md как вести сделку
├─ people/
│ ├─ elena-karpova.md 👤 ЛПР
│ └─ sergey-vlasov.md
├─ meetings/
│ └─ 2026-05-20-tech.md
├─ tasks/
│ └─ task-031-tz.md ✅ doing
├─ decisions/ commitments/
├─ questions/ risks/ landscape/
└─ threads/ 💬 чаты · ✉️ почта
наведи на ноду → подсветятся её связи · папки = навигация, рёбра = wikilinks
два слоя по статусу: реальность vs интерпретация
События — реальность (immutable)
📹 meeting/2026-05-20 · транскрипт
💬 chat/… · ✉️ email-in/…
✉️ email-out · ✅ tracker/created · →done
◀ provenance
Знания — интерпретация (mutable граф)
⚖ decision/erp-gateway
✅ task-031 {status: doing}
👤 person/elena {ЛПР} · 🤝 commitment/…
Нота-сущность = front-matter (типы для детерминированных поверхностей) + тело (для агентов):
---
id: task-031
type: task
status: doing # двигается событиями
assignee: [[igor-lebedev]]
due: 2026-05-27
provenance: [ meeting/2026-05-20#13:10 ]
state: confirmed # proposed|confirmed
---
## Подготовить ТЗ на интеграцию через шлюз
Контекст: доступ к ERP только через шлюз…
<!-- summary: derived, regen on change -->
📜 Событийный лог — append-onlyисточник истины (реальность)
🕸 Граф нот — front-matter + wikilinksmutable, провенанс, журнал
🔗 Entity-resolution / temporal mergeключевой вызов
🧭 idx:events (транскрипты/сообщения)вектор #1
🧭 idx:knowledge (ноты)вектор #2
📦 Context-builder — срез под агентаretrieval + сборка
MVP-стекevent-log (append-only)markdown-вольт/графentity-resolution2× vector indexcontext-builder
5
Детерминированные сервисы
Не-рассуждающие тулзы со стабильным I/O. Stateless, идемпотентны, кешируемы. Чистое разделение: сервисы = детерминированные тулзы · агенты = рассуждение · коннекторы = I/O. Тяжёлые (ASR на GPU) — центры стоимости.
in: аудио / файл / текст out: нормализованный результат (схема)
пример: типизированный детерминированный сервис
🎧 аудио
запись встречи
→
ASR + диаризация
детерминированный сервис
→
транскрипт
[{ t, sp, text }]
🎧 ASR + диаризацияаудио → транскрипт со спикерами
📄 OCRскан/PDF → текст
🔡 Embeddingsтекст → вектор
🗓 Парсинг календаря/писемraw → события
Тот же типизированный интерфейс, что у агентов и коннекторов — пайплайн зовёт их одинаково. Часть — heavy-GPU (ASR/диаризация), это влияет на инфра-оценку MVP.
MVP-стекASR (Whisper-class)diarizationOCRembeddingsGPU-деплой
6
Маршрутизатор / коннекторы
Граница I/O. Контракт = MCP (Model Context Protocol): внешняя система отдаёт resources (ingest) и tools (act). Роутер мапит абстрактное действие («создать задачу») на привязанный к сделке коннектор; нормализация в формат событий — на этой границе.
ingest: resources → события act: tools ← действия
маршрутизация действия — нажми ▶
действие
«создать задачу»
→
🧭 роутер
action → connector
→
✅ Трекер MCP · create_task
✉️ Почта MCP · send
📖 Вики MCP · upsert
→
внешняя система
—
«создать задачу» для сделки «Меридиан» → роутер выберет привязанный коннектор
📹 Конференции
resource: запись/транскрипт
💬 Мессенджеры
resource: сообщения · tool: post
✉️ Почта
resource: письма · tool: send(draft)
✅ Трекер
tool: create/update task
📖 Вики
tool: upsert page
🏢 CRM / Календарь
resource + tool
Агностик-ядро + 1–2 эталонных коннектора в пилоте; остальные — по тому же MCP-контракту. Новый инструмент = новый сервер, ядро не меняется.
MVP-стекMCP-серверы/адаптерыOAuthнормализация событийроутер действий
📐 Следующий шаг: каждый из 6 блоков — самостоятельный модуль с понятным контрактом → оцениваем ресурсы и сроки MVP по каждому отдельно. «MVP-стек» под каждым блоком — это и есть список того, что закладываем в оценку.