Огляд

Історичний проєкт: згадки запланованого LightRAG та графового сховища нижче скасовані рішенням AGNT2-303. Зараз знання використовують пошук словами й векторами; старі згадки не є інструкцією з реалізації чи розгортання. Knowledge.

Технічний вхід в архітектуру. Та сама історія простою мовою — Як це працює; ця сторінка називає самі рішення та частини, а далі веде на сторінки з деталями.

Одне рішення визначає все

Агент — це дані, а не процес. Його конфіг, пам'ять, чати та знання — рядки й файли у сховищі. Поки з ним ніхто не говорить, нічого не запущено й нічого не коштує.

Решта архітектури — наслідки цього одного рішення:

1. Мозок ефемерний. Жодного «сервера агента» немає. api завантажує дані агента, стає цим агентом на один турн — LLM-цикл крутиться тут — і відпускає. Тисячі агентів, нуль вартості в простої.
2. Руки ефемерні. Коли турну потрібен справжній комп'ютер (bash, файли, браузер), мозок піднімає worker — ізольований k8s Job, який виконує задачу і зникає. Всередині немає LLM, пам'яті, секретів.
3. Увесь стан живе поза compute. Postgres, Redis, object storage і LightRAG тримають усе; будь-який запуск мозку чи worker'а продовжує рівно з того місця, де зупинився попередній.
4. Здатності підключаються по MCP. Інструменти, знання та пам'ять приєднуються до мозку через один стандартний роз'єм — мозок лишається маленьким, а те, що агент вміє, — це конфігурація, а не код.

Картина цілком

Читайте знизу вгору: нижній рядок і є агент; два блоки над ним — одноразовий compute, який ненадовго його оживляє.

Один образ, дві ролі

api — одна кодова база й один образ NestJS у двох ролях:

• Core — постійно працюючий control plane: HTTP API, auth, команди, білінг, адмінка.
• Мозок — той самий образ, що виконує турн агента («рантайм» у цих доках = api, запущений ефемерно, на турн).

Один образ — бо турн торкається того самого домену, яким володіє Core: агенти, чати, пам'ять, квоти, білінг. Розділення означало б дублювати цей домен у двох сервісах; натомість роль визначається способом виклику, і є рівно одна річ, яку збирають, версіонують і деплоять.

Що деплоїться

Частина	Роль	Життєвий цикл
api	Core control plane + мозок агента (один образ)	завжди працює; робота мозку — на турн
worker	руки — пісочниця (bash · fs · browser), ефемерний MCP-сервер	на задачу, зупиняється по простою
app / admin	кабінет клієнта / адмін-панель (Nuxt)	завжди працюють
Postgres · Redis · object storage · LightRAG	увесь стан: агенти й чати, черга й події, артефакти, знання	завжди на місці

Репозиторій

Один монорепо — github.com/Agentfy/agentfy — тримає всю платформу:

agentfy/
├── api/          NestJS — Core + мозок (один образ); slices/ = 8 шарів-груп
├── worker/       руки — образ-пісочниця (bash · fs · browser)
├── app/          Nuxt — кабінет клієнта
├── admin/        Nuxt — адмін-панель
├── k8s/          Helm-чарти + ArgoCD app-of-apps (GitOps)
├── terraform/    кластер і хмарна інфра (IaC)
└── docs/         цей сайт документації (VitePress)

Хребтовий інваріант

Усередині api код — це вертикальні слайси CleanSlice у 8 суворо впорядкованих групах — infra → setup → system → user → admin → runtime → agent → billing — і залежності йдуть лише вниз, без циклів. orchestrator (цикл мозку) сидить у групі agent і тягнеться вниз до механізмів; догори не тягнеться ніхто. Це одне правило тримає бекенд розплутаним у міру зростання.

→ Глибше: Шари-слайси (групи і правило) · Розбір слайсів (усі підслайси) · Модель рантайму (турн від і до).

Партнерські платформи (пропозиція)

Організації, серверний provisioning і консолідовані рахунки реселера описані в Agentfy для платформ. Це пропозиція; вона не змінює описану вище поточну поведінку.