Как устроен AI-PM внутри
Агентный рантайм под вертикаль: рой агентов слушает коммуникации, ведёт сделку и действует от лица команды — с человеком в контуре.
✦
Принцип: детерминированная оркестрация + модельная когниция. Процесс (что за чем, что требует аппрува, куда пишем) — жёсткий аудируемый каркас; LLM зовётся точечно на «умных» шагах. Не один большой агент, который решает всё.
Кликни по любому блоку → разворот ниже с описанием и примером.
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
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
3
Набор агентов
По одному агенту на функцию (чат-бот, поиск по знаниям, заполнение вики, ведение задач…). Каждый = типизированная функция «схема → схема» поверх LLM; контекст впрыскивает оркестратор (паттерн сабагента: узкий контекст + свои тулзы → структурированный результат). Узкие агенты проще тестировать, переиспользовать и ограничивать по автономии.
контракт агента
вход
context (из ④) + payload · по схеме
→
🧠 агент
role + tools + LLM
→
выход
structured JSON · валидируется
💬 Чат-бот
диалог в мессенджере: отвечает, шлёт итоги и аппрувы
через: 💬 чат · автономия: Act (в чат)
🔎 Поиск по знаниям
retrieval по графу и вектору, отдаёт срез контекста
через: ④ знания (чтение) · автономия: Observe
📖 Заполнение вики
создаёт и обновляет страницы досье сделки
через: 📖 вики · автономия: Structure
🎙 Разбор встречи
транскрипт → решения, задачи, вопросы, риски
через: ⑤ ASR + ④ запись · автономия: Structure
✅ Ведение задач
заводит и двигает задачи по статусам
через: ✅ трекер · автономия: Structure→Act
✉️ Драфт писем
письма Заказчику, дайджесты — только черновик
через: ✉️ почта · потолок: только draft
🛰 Наблюдатель
мониторит зависшее и обещания, эскалирует
через: ④ знания · автономия: Structure→Act
🗣 Ведущий встречи
повестка и тайминг на встрече, realtime
через: 📹 конференция · автономия: Observe
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 + сборка
5
Детерминированные сервисы
Не-рассуждающие тулзы со стабильным I/O. Stateless, идемпотентны, кешируемы. Чистое разделение: сервисы = детерминированные тулзы · агенты = рассуждение · коннекторы = I/O.
in: аудио / файл / текст out: нормализованный результат (схема)
пример: типизированный детерминированный сервис
🎧 аудио
запись встречи
→
ASR + диаризация
детерминированный сервис
→
транскрипт
[{ t, sp, text }]
🎧 ASR + диаризацияаудио → транскрипт со спикерами
📄 OCRскан/PDF → текст
🔡 Embeddingsтекст → вектор
🗓 Парсинг календаря/писемraw → события
Тот же типизированный интерфейс, что у агентов и коннекторов — пайплайн зовёт их одинаково. Часть сервисов — heavy-GPU (ASR/диаризация).
6
Маршрутизатор / коннекторы
Граница I/O. Контракт = MCP (Model Context Protocol): внешняя система отдаёт resources (ingest) и tools (act). Роутер мапит абстрактное действие («создать задачу») на привязанный к сделке коннектор; нормализация в формат событий — на этой границе.
ingest: resources → события act: tools ← действия
сценарий: оркестратор + агенты ходят в мир через единый слой коннекторов — нажми ▶
чат-бот отвечает пользователю и по ходу просит агента-поисковика достать данные из вики — всё через единый слой коннекторов
📹 Конференции
resource: запись/транскрипт
💬 Мессенджеры
resource: сообщения · tool: post
✉️ Почта
resource: письма · tool: send(draft)
✅ Трекер
tool: create/update task
📖 Вики
tool: upsert page
🏢 CRM / Календарь
resource + tool
Агностик-ядро + 1–2 эталонных коннектора в пилоте; остальные — по тому же MCP-контракту. Новый инструмент = новый сервер, ядро не меняется.