Go Portal by kavioavio
Демо
OSS-FIRST · MANAGED SAAS · AGENT CONTROL PLANE

AI-агенты — с production-grade control plane как у инфраструктуры.

Go Portal — OSS-first/self-hostable core + managed SaaS слой для личных и клиентских AI-агентов: Web, Telegram и CLI поверх policy, квот, approvals, аудита и изоляции runtimes.

Web — пультPRIMARY Telegram — approvals CLI — rescue OSS core + SaaS ops
OSS-first core · managed SaaS pilot static preview · no live mutation public repo/license — after actual publication
Private pilot · static preview
go-portal · control plane
owner: sergey · policy-gated tenants
TENANT · AGENT RUNTIMESTATEQUOTA
friend sergey-core policy
RUNNING
38%
client atlas-ops
RUNNING
71%
guest m.orlova · POLICY APPROVAL
approve deny
blocked by policy: gateway-restart-prod · requires owner approval · preview only, no production mutation
client relay-eu
IDLE module off
AUDIT 09:42:18 · sergey · token.rotate → approved · logged
$ portal agents ls --owner
APPROVAL TRAIL · human-in-the-loop
Каждое prod-действие проходит policy check, явное owner approval и запись в audit log.
1
REQUEST
agent
2
POLICY
rules
OWNER APPROVAL
explicit
4
EXECUTE
runtime
request → policy check → owner approval → execute · immutable audit log
KAFKA BRIDGE · highload event flow
Событийный обмен между runtime-агентами и сервисами контроля.
agent.runtime
operator
telegram
BRIDGE
audit.sink
service.state
observability
agent.events approvals audit.log
01 · СДВИГ

Чат — это не операционная модель.

Один диалог в браузере не даёт владельцу контроля: кто получил доступ, какие лимиты, что агент сделал, где его память и файлы, как отозвать доступ. Агентам нужна та же дисциплина, что и сервисам — identity, policy, квоты, аудит и изоляция.

БЕЗ КОНТРОЛЯ
Доступ без границ

Раздача доступов «по ссылке», без квот, ролей и возможности отозвать.

БЕЗ ПАМЯТИ СИСТЕМЫ
Нет аудита и истории

Что сделал агент, какие артефакты создал, что одобрено — нигде не зафиксировано.

БЕЗ ИЗОЛЯЦИИ
Смешанные runtimes

Память, файлы и контекст разных людей в общем пространстве — без границ tenant.

02 · ТРИ ПОВЕРХНОСТИ

Одна система управления — три поверхности доступа.

Не три разных продукта — три поверхности одного backend / control plane. У каждой своя роль, и порядок намеренный.

PRIMARY
WEB / PORTAL
Основная панель управления

Полный контроль: пользователи, агенты, квоты, approvals, аудит, сервисы. Здесь живёт операционная модель продукта.

PORTAL · CONSOLE
TELEGRAM
Быстрые действия и статус

Компактная поверхность: статус агента, уведомления, approve/deny на ходу, привязка бота. Не панель управления.

⚠ approval · m.orlova
approve deny
✓ quota atlas-ops · 71%
CLI
Rescue, операции, debug

Поверхность оператора: восстановление, диагностика, аварийные действия, когда портал недоступен. Низкоуровневый контроль.

$ portal runtime restart atlas-ops
→ draining · isolating · ok
$ portal audit tail --tenant m.orlova
→ stream attached
03 · ЧТО КОНТРОЛИРУЕТ GO PORTAL

Объекты контроля, а не набор «фич».

Каждый пункт — управляемый объект control plane: со своим состоянием, политиками и записью в аудит.

Agent runtimes
Запуск, состояние и перезапуск изолированных runtimes.
Tenant / Friend isolation
Отдельная память, файлы и контекст на каждого.
Approvals
Действия в prod блокируются до явного одобрения.
Policies
Правила и роли: что агенту можно, а что нет.
Audit trail
Кто, что и когда запросил, одобрил и выполнил.
Quotas & cost
Лимиты и расход как один observability-модуль.
Runtime health
Состояние сервисов и runtimes в реальном времени.
Admin / Ops cockpit
Единая панель управления парком агентов.
Guest / Friend LK
Личный кабинет: агент, история, артефакты, квоты.
Access / VPN OPTIONAL
Опциональный модуль доступа. Не продукт.
04 · GUEST / FRIEND — ЛИЧНЫЙ КАБИНЕТ

У каждого друга и клиента — свой агент, изолированный runtime.

Своя память, файлы, история и квоты. Доступ выдаёт владелец, и его можно отозвать.

Свой агент / чат
персональный runtime
История / архив
диалоги и сессии
Артефакты / файлы
результаты работы
Telegram-бот
привязка аккаунта
Использование / квоты
прозрачные лимиты
Профиль / безопасность
сессии и устройства
Поддержка / анонсы
от владельца
VPN / access MODULE
опционально, не продукт
portal · friend · sergey-core ● running
Чат История Артефакты Квоты Telegram Профиль VPN модуль
Собери дайджест по новым задачам и сохрани в артефакты.
Готово. Создал digest-0618.md → Артефакты.
quota · 38% / месяц tg bound ✓
05 · ADMIN / OPS — COCKPIT ВЛАДЕЛЬЦА

Владелец управляет всем парком агентов из одной панели.

Пользователи, runtimes, квоты, approvals, аудит, сервисы и аварийные действия — операторская плотность там, где она нужна.

ops.goportal — control plane
services 9/91 pendingowner: sergey
Users / Invites 12 Agents / Runtimes 8 Quotas / Routing Approvals 1 Audit log Service health Telegram bindings Relay / access Support / broadcasts Emergency / rescue
ACTIVE RUNTIMES
7
QUOTA USED
62%
APPROVALS
1
SERVICES
9/9
USERAGENT RUNTIMEQUOTASTATETG
sergey (owner)sergey-core38%● runningbound
atlas (client)atlas-ops71%● runningbound
m.orlova (guest)orlova-01● approvalapprove
relay-eu (module)access-relayidle● module
06 · BACKEND CONTROL PLANE — КАРТА СИСТЕМЫ

Что внутри: поверхности, control plane, изолированные runtimes.

Конкретные модули, а не абстрактные «возможности платформы».

SURFACES
Web / Portal
основная панель
Telegram
действия / статус
CLI
rescue / debug
CONTROL PLANE
IDENTITY
кто есть кто, инвайты
POLICY
правила и роли
QUOTAS
лимиты, routing
APPROVALS
запросы доступа
AUDIT
журнал действий
ARTIFACTS
история, файлы
ORCHESTRATION
runtime state
TELEGRAM
интеграция
SERVICE STATE
live
health сервисов
ACCESS / VPN
опц. модуль
ISOLATED TENANT RUNTIMES
sergey-core
memory · files
quota · profile
atlas-ops
memory · files
quota · profile
orlova-01
memory · files
quota · profile
+ tenant
изоляция по
умолчанию
07 · ПОЧЕМУ KAVIOAVIO

Control plane строит инженер, который строил distributed-системы.

Go Portal — это не «AI-обёртка». Это контроль над агентами по тем же принципам, что и production-инфраструктура: event-driven архитектуры, распределённая обработка данных, backend control planes, observability.

Built from production architecture, event-driven systems, Kafka/highload patterns and infrastructure operations experience — поэтому агенты здесь управляются как workloads, а не как разрозненные чаты.

01
Event-driven & distributed systems
Проектирование потоков, согласованность состояния, отказоустойчивость.
02
Backend control planes & observability
Identity, policy, quotas, audit, диагностика сервисов.
03
Infrastructure & networking
Изоляция runtimes, relay/access, эксплуатация под нагрузкой.
Kafka Kubernetes PostgreSQL Python Java Redis ClickHouse proof of competence
08 · СЦЕНАРИИ ПИЛОТА

С чего начинают.

КРУГ ДОВЕРИЯ
Агенты для друзей и близких

Дать каждому свой агент с изоляцией, квотами и понятным контролем доступа со стороны владельца.

КЛИЕНТСКИЕ АГЕНТЫ
Агенты под клиентов

Отдельные runtimes на клиента, прозрачные лимиты, аудит и approvals владельца.

ОПЕРАЦИИ
Контролируемый парк агентов

Единый cockpit для health, квот, аудита и аварийного восстановления через CLI.

Запустим пилот control plane для ваших агентов.

Покажем Web-портал, Ops cockpit и карту MVP. Обсудим изоляцию, квоты и интеграции под ваш сценарий.

Запрос сформирован в почтовом клиенте — демо-подтверждение, без отправки на сервер.