Agent Resource

When several of my projects began using AI agents, the main difficulty was not creating new roles. The problem was reuse.

A useful process would begin as a prompt or Markdown file, then be adapted to one project, acquire local rules, and gradually drift away from the original. It became difficult to know which version was current, what could be transferred safely, and how to update one project without overwriting its decisions or private data.

Agent Resource emerged as a way to make agent workflows portable, testable, and governable.

The project began in May 2026 as Ops Hub, an operational layer around Portfolio Site.

Early versions included a Business Analyst, Backlog Operator, Log Keeper, Librarian, Todoist integration, and rules for preserving project history.

The first useful model appeared during that work:

Agent Resource held the common role model. A specific project received a local agent that inherited the core behavior while keeping its own scope, paths, data, and constraints.

Portfolio and Powermap became the first proving grounds. Useful decisions from working projects could return to Agent Resource and improve the shared archetypes.

Ops Hub gradually became a library of reusable agent roles.

The first architecture depended heavily on Todoist. It helped start the work quickly, but eventually added unnecessary infrastructure:

In June, the backlog moved into Markdown.

Each work item became a durable file. Dependencies became typed relationships, while Kanban and other views became projections of canonical data. The Todoist runtime and local secret were removed, but the historical records were preserved as migration evidence.

The project was renamed Agent Resource during the same period. The new name described its actual function more accurately: preserving and distributing reusable capabilities for agent-assisted projects.

By August, Agent Resource contained many roles, models, spawn packets, and operating rules. They were still only a collection of documents.

An archetype could be copied, but it did not have:

Git showed which files had changed, but it did not answer the more important questions:

These questions led to the project's main architectural shift.

Agent Resource stopped treating an individual role or Markdown archetype as a complete transferable capability.

The primary unit became an independently versioned package:

The version streams are deliberately separate:

A package can evolve independently. A project installs a specific version, records its local overrides, and does not receive automatic updates.

Even an existing project cannot be migrated by simply copying files. Installation begins with a read-only compatibility audit, continues with a migration proposal, and changes the local instance only after explicit approval.

Agent Resource also stopped acting as a cross-project command center. It does not decide the purpose, priorities, or product direction of other projects. It owns reusable capabilities and the safe process for installing them.

The Backlog package was created by comparing working systems in Agent Resource, Holding, Wiki Articles, Portfolio Site, MilSim, LifeGraph, and SQVL-MESH.

The projects shared a durable foundation:

Their exact statuses, types, relationships, and document structures still differed. The package therefore did not become a copy of one supposedly ideal project.

backlog@0.1.0 provides configurable lifecycle, machine-readable Markdown work items, typed local and external relationships, duplicate and dangling-reference detection, a generated JSON index, generated Kanban, type and review views, archive and supersession contracts, an optional Backlog Operator, dependency-free tooling, and regression fixtures.

During its own installation, Agent Resource migrated 14 historical work items and 62 relationships without losing their content or earlier Todoist migration evidence.

The project log gradually accumulated too many responsibilities. Development history, current operational context, backlog state, and Git-level details were mixed into one artifact.

Work across several projects revealed a clearer division:

development-log@0.1.0 connected one canonical VERSION, one meaningful Development Log entry, and one Git commit into a verifiable change set.

Version 0.2.0 added support for multi-product repositories. One repository can now contain independently versioned products with separate version files, Development Logs, Git tag namespaces, file scopes, and application bindings.

When a change touches shared scope, validation requires every affected version stream to advance. A file with no defined owner blocks the commit instead of making the system guess responsibility.

Design System became the fourth reusable package.

It grew from production lessons in Portfolio Site and combines the work of three roles: Design System Architect, a conditional Visual Designer, and Design System Builder. The previous Crawler responsibilities moved into Architect, while Essence Writer became part of Builder.

Each design-system item receives one canonical Markdown Essence:

design-system@0.2.0 supports a typed domain graph, source coverage, component-boundary validation, and checks between component previews and real product usage.

Project-specific behavior was not declared universal. Documentation registry, generated media delivery, and an independent Design System release stream remain optional profiles, enabled only when a product actually needs them.

OpCon Graph grew from two real implementations.

LifeGraph demonstrated a large private knowledge graph in active use. SQVL-MESH contributed a stricter operational-context model and mandatory lineage from every structured record to raw evidence.

The comparison produced opcon-graph@0.1.0 with facts, events, entities, topics, decisions, raw-source lineage, typed relationships, privacy boundaries, machine-readable projections, validation, and synthetic tests.

The next question concerned storage. Could PostgreSQL give AI agents faster and more compact access to a large context while preserving natural input, evidence, history, and recovery?

Version 0.2.0 added a PostgreSQL schema, authenticated low-privilege API, atomic writes, optimistic concurrency, revision history, idempotent retries, bounded retrieval, backup, and restore tooling.

Version 0.3.0 added reviewed legacy import, explicit preservation of historical uncertainty, and lossless SQL-to-Markdown recovery.

Technical fixtures were not sufficient, so the package entered a real pilot in LifeGraph.

Before migration, the source data, encrypted backups, and a reference baseline were preserved. An isolated PostgreSQL database then received:

After reconciliation, SQL became the only writer during a bounded pilot. One real user intake created a raw record, new derived records, and revisioned updates to existing knowledge.

The checks confirmed:

Technically, the experiment succeeded.

The product hypothesis did not.

In the selected real retrieval cases, efficient reads of known Markdown files took approximately 0.4-0.8 ms, while remote SQL full-context retrieval took around 18-50 ms. SQL envelopes were also approximately 2.5-2.9 times larger.

Total AI response time and billed token usage could not be measured, so the project could not claim token savings or overall acceleration. There was also no independent evaluation showing better answer quality.

PostgreSQL was therefore rejected for the active LifeGraph implementation, which returned to the preserved source Markdown dataset. SQL-only experimental changes were deliberately excluded instead of being represented as migrated knowledge.

Before the return:

This became one of Agent Resource's most important results.

A successful implementation does not prove that a technology serves the user. The ability to reject it safely can be as important as the ability to build it.

The first challenge was separating reusable behavior from project-specific context. A package must transfer a contract without transferring private data, credentials, branding, or product decisions.

The second was preserving legacy history without rewriting it. If an old record has no known date, author, or lineage, migration must retain that uncertainty instead of inventing clean values for a new schema.

The third was preventing Agent Resource from becoming the central owner of other projects. A package provides a capability, while the target project keeps local governance.

The fourth was distinguishing technical correctness from real value. The PostgreSQL pilot passed integrity and recovery checks but did not demonstrate an improved user outcome.

The fifth was designing rollback before migration began. A Git branch cannot restore ignored private data or database writes. Real recovery must account for source snapshots, later writes, credentials, services, backups, and recovery validation.

At the current snapshot, Agent Resource is at version 1.8.3 and contains four independently evolving packages:

It is not a marketplace or SaaS platform. It has no automatic update system for every project and no central management interface.

It is a Git-backed package repository where proven agent workflows become capabilities with versions, contracts, tests, installation boundaries, and recovery paths.

The project began with the goal of reusing agents. Practical work showed that a reusable agent was too small a unit.

A genuinely transferable AI capability needs more than a role or prompt. It needs:

Agent Resource is no longer a project about how many agents can be collected. It is about whether the systems those agents use can be trusted.

Sometimes the strongest evidence of maturity is not a successful migration. It is the ability to test a hypothesis honestly, reject it, and return safely.