Agent Resource

Когда несколько моих проектов начали использовать ИИ-агентов, основная сложность оказалась не в создании новых ролей. Проблема возникала при повторном использовании.

Полезный процесс начинался как промпт или Markdown-файл, затем адаптировался под конкретный проект, обрастал локальными правилами и постепенно расходился с оригиналом. Становилось непонятно, какая версия актуальна, что можно безопасно перенести и как обновить один проект, не перезаписав его решения или приватные данные.

Agent Resource появился как способ сделать процессы агентов переносимыми, проверяемыми и управляемыми.

Проект стартовал в мае 2026 года как Ops Hub, операционный слой вокруг Portfolio Site.

Первые версии включали Business Analyst, Backlog Operator, Log Keeper, Librarian, интеграцию с Todoist и правила сохранения проектной истории.

Во время работы сформировалась первая важная модель:

Agent Resource хранил общую модель роли. Конкретный проект получал локального агента, который наследовал основное поведение, но имел собственный scope, пути, данные и ограничения.

Portfolio и Powermap стали первыми testing grounds. Полезные решения из реальных проектов возвращались в Agent Resource и улучшали общие архетипы.

Так Ops Hub постепенно стал библиотекой многоразовых ролей агентов.

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

В июне backlog был перенесен в Markdown.

Каждый work item стал отдельным долговечным файлом. Зависимости превратились в типизированные отношения, а Kanban и другие views стали проекциями канонических данных. Todoist runtime и локальный секрет были удалены, но исторические записи сохранились как доказательства миграции.

В тот же период проект получил имя Agent Resource. Оно точнее описывало фактическую функцию: хранить и распространять повторно используемые возможности для проектов с агентами.

К августу Agent Resource содержал множество ролей, моделей, spawn packets и правил. Но все это оставалось набором документов.

Архетип можно было скопировать, однако у него не было собственной версии, конфигурационной схемы, установщика, автоматической проверки, regression tests, migration contract и безопасного процесса обновления.

Git показывал, какие файлы изменились, но не отвечал на более важные вопросы:

Это привело к главному архитектурному повороту проекта.

Agent Resource перестал считать отдельную роль или Markdown-архетип законченной переносимой возможностью.

Основной единицей стал независимо версионируемый пакет:

Версии были сознательно разделены:

Пакет может развиваться независимо. Проект устанавливает конкретную версию, фиксирует local overrides и не получает автоматические обновления.

Даже существующий проект нельзя мигрировать простым копированием файлов. Сначала проводится read-only compatibility audit, затем создается migration proposal, и только после подтверждения изменяется local instance.

Agent Resource перестал быть cross-project command center. Он больше не определяет назначение, приоритеты и продуктовые решения других проектов. Он отвечает за многоразовые возможности и безопасный способ их установки.

Backlog package был создан через сравнение рабочих систем в Agent Resource, Holding, Wiki Articles, Portfolio Site, MilSim, LifeGraph и SQVL-MESH.

У проектов обнаружился общий фундамент:

Конкретные статусы, типы, отношения и структуры документов отличались. Поэтому пакет не стал копией одного якобы идеального проекта.

backlog@0.1.0 получил configurable lifecycle, machine-readable Markdown work items, типизированные локальные и внешние отношения, поиск дубликатов и висячих ссылок, сгенерированный JSON index, Kanban, type и review views, archive и supersession contracts, опционального Backlog Operator, dependency-free tooling и regression fixtures.

Во время собственной установки Agent Resource мигрировал 14 исторических work items и 62 отношения, не потеряв их содержание и прежние доказательства миграции из Todoist.

Проектный log постепенно накопил слишком много обязанностей. История разработки, текущий операционный контекст, состояние backlog и Git-level details оказались смешаны в одном артефакте.

Работа над несколькими проектами помогла разделить эти слои:

development-log@0.1.0 связал один канонический VERSION, одну осмысленную запись Development Log и один Git commit в проверяемый change set.

Версия 0.2.0 добавила multi-product repositories. Теперь один репозиторий может содержать несколько независимо версионируемых продуктов со своими version files, Development Logs, Git tag namespaces, file scopes и application bindings.

Если изменение затрагивает общую область, validation требует обновить все связанные version streams. Файлы без определенного владельца блокируют commit вместо того, чтобы заставлять систему угадывать ответственность.

Design System стал четвертым многоразовым пакетом.

Он вырос из production lessons Portfolio Site и объединил работу Design System Architect, условного Visual Designer и Design System Builder. Обязанности прежнего Crawler вошли в Architect, а Essence Writer стал частью Builder.

Каждый элемент Design System получает один канонический Markdown Essence:

design-system@0.2.0 поддерживает типизированный доменный граф, source coverage, проверку границ компонентов и соответствия Preview реальному использованию в продукте.

Проектные особенности не были объявлены универсальными. Documentation registry, generated media delivery и отдельный Design System release stream остаются опциональными профилями и включаются только там, где они действительно нужны.

OpCon Graph вырос из двух реальных реализаций.

LifeGraph доказал жизнеспособность большой приватной базы знаний. SQVL-MESH добавил более строгую модель операционного контекста и обязательную lineage от каждой структурированной записи к raw evidence.

Сравнительный аудит создал opcon-graph@0.1.0 с фактами, событиями, сущностями, темами, решениями, raw-source lineage, типизированными отношениями, границами приватности, machine-readable projections, validation и synthetic tests.

Следующим вопросом стало хранилище. Может ли PostgreSQL дать ИИ-агентам более быстрый и компактный доступ к большому контексту, сохранив естественный ввод, доказательства, историю и возможность восстановления?

Версия 0.2.0 добавила PostgreSQL schema, authenticated low-privilege API, atomic writes, optimistic concurrency, revision history, idempotent retries, bounded retrieval, backup и restore tooling.

Версия 0.3.0 добавила reviewed legacy import, явное сохранение исторической неопределенности и lossless SQL-to-Markdown recovery.

Технических fixtures было недостаточно, поэтому пакет прошел реальный pilot на LifeGraph.

Перед миграцией были сохранены исходные данные, encrypted backups и reference baseline. Затем в изолированную PostgreSQL database были импортированы:

После reconciliation SQL стал единственным writer на время ограниченного pilot. Один реальный пользовательский ввод создал raw record, новые derived records и revisioned updates существующего знания.

Проверки подтвердили точный импорт, отсутствие duplicate writes при повторных запросах, сохранение revision history, восстановление encrypted SQL backup, экспорт текущего SQL-состояния обратно в Markdown и сохранение отношений и исторических версий.

С технической точки зрения эксперимент прошел успешно.

Продуктовая гипотеза не подтвердилась.

В выбранных реальных retrieval cases эффективное чтение известных Markdown-файлов занимало примерно 0.4-0.8 ms, тогда как remote SQL full-context retrieval требовал около 18-50 ms. SQL envelopes также оказались примерно в 2.5-2.9 раза больше.

Полное время генерации ответа ИИ и billed token usage измерить не удалось, поэтому заявлять экономию токенов или общее ускорение нельзя. Независимой оценки улучшения качества ответов также не было.

Поэтому PostgreSQL был отклонен для активной реализации LifeGraph, которая вернулась к сохраненному исходному Markdown dataset. Экспериментальные SQL-only изменения были осознанно исключены, а не выданы за перенесенные знания.

Перед возвратом были сохранены доказательства эксперимента и code snapshots, проверены encrypted off-host backups, восстановлены и провалидированы исходные 1 572 Markdown records, подтверждены все 845 доменных связей, удалены выделенные LifeGraph SQL services и credentials, а reusable PostgreSQL capability осталась внутри пакета OpCon Graph.

Это стало одним из наиболее важных результатов Agent Resource.

Успешная реализация еще не означает, что технология подходит пользователю. Способность безопасно отказаться от решения может быть не менее важной, чем способность его построить.

Первой сложностью было отделить reusable behavior от project-specific context. Пакет должен переносить контракт, но не приватные данные, credentials, branding или product decisions.

Второй было сохранение legacy history без ее переписывания. Если у старой записи неизвестна дата, автор или lineage, миграция должна сохранить эту неопределенность, а не придумать чистые значения ради новой схемы.

Третьей было не превратить Agent Resource в центрального владельца других проектов. Пакет предоставляет возможность, а target project сохраняет локальное управление.

Четвертой было различать техническую корректность и реальную ценность. PostgreSQL pilot прошел integrity и recovery checks, но не доказал улучшение пользовательского результата.

Пятой было проектировать rollback до начала миграции. Git branch не восстанавливает ignored private data или database writes. Настоящее восстановление должно учитывать source snapshots, последующие записи, credentials, services, backups и recovery validation.

На текущем snapshot Agent Resource находится на версии 1.8.3 и содержит четыре независимо развивающихся пакета:

Это не marketplace и не SaaS-платформа. Здесь нет автоматического обновления всех проектов или единого управляющего интерфейса.

Это Git-backed репозиторий пакетов, где доказавшие себя процессы агентов превращаются в возможности с версиями, контрактами, тестами, границами установки и путями восстановления.

Проект начался с идеи повторно использовать агентов. Практическая работа показала, что reusable agent является слишком маленькой единицей.

Настоящая переносимая возможность ИИ требует не только роли или промпта. Ей нужны данные и их границы, конфигурация, validation, version history, migration policy, recovery и доказательство того, что она работает вне исходного проекта.

Agent Resource больше не является проектом о количестве собранных агентов. Он отвечает на вопрос, можно ли доверять системам, которые используют эти агенты.

Иногда самым сильным доказательством зрелости становится не успешная миграция, а способность честно проверить гипотезу, отказаться от нее и безопасно вернуться назад.