Agent Resource
Agent infrastructure Project systems
Agent Resource is a Git-backed source project for reusable agent roles, project setup packets, and operating rules.
It exists because agentic work does not stay clean by itself. Once several projects start using agents, the same questions repeat: which roles are needed, where decisions live, how project-local agents inherit shared behavior, how lessons move between projects, and how one project asks another for work without taking over its backlog.
Context gap
Raw project intent is not enough to create a reliable agentic workspace.
A user can say "build this project" or "set up agents for this goal", but the real work starts after that: scope, ownership, backlog, roles, logs, communication, Git boundaries, approval gates, and reusable rules all need a place to live.
Without a shared resource layer, every project invents this structure again. Some roles drift. Some logs disappear. Some cross-project messages become unclear. Some useful lessons remain trapped inside one project instead of becoming reusable.
Agent Resource exists to reduce that repeated setup cost.
System concept
Agent Resource is not a finished commercial platform and not an autonomous controller for all projects.
It is a repo-based workshop and library. It stores reusable agent passports, archetypes, project setup packets, communication protocols, backlog models, inheritance rules, logs, inventories, and archives.
The central distinction is master vs local.
Agent Resource stores reusable patterns. Each target project keeps its own local agents, local backlog, local source of truth, and local implementation authority.
Architecture
The current structure includes:
- agents/ for reusable master agent passports and Agent Resource local agents
- artifacts/ for archetypes, models, protocols, logs, inventories, and setup guidance
- backlog/ for Agent Resource local work items and views
- communication/ for inbox, outbox, archive, and message templates
- archive/ for retired aliases, old role dossiers, ledgers, and historical material
This gives the project a source-of-truth structure for reusable operating knowledge instead of scattering agent rules across conversations.
Operating loop
The practical loop is:
raw project goal or lesson
-> boundary check
-> default operating pack
-> domain agents when needed
-> reusable archetype or new master role
-> project-local agent instance
-> local backlog, log, and communication setup
-> target project execution
-> approved lesson promotion back to Agent ResourceThe loop protects local ownership. Agent Resource can staff, seed, and guide, but the target project still owns its own work.
Reusable artifacts
Agent Resource has several reusable artifact families:
- project agent spawn packet
- agent inheritance model
- agent seeding and propagation rules
- project communication archetype
- Markdown backlog model
- article source and presentation contract
- Markdown knowledge model
- design-system agent archetypes
- agent archetype inventory matrix
These artifacts turn repeated project setup into reusable operating knowledge.
Agent roles
The default operating pack includes roles such as Business Analyst, Backlog Operator, Backlog, Log Keeper, Librarian, and GitHub Operator.
Other role families cover owner and user separation, Markdown knowledge work, article writing, design-system work, deployment, portfolio management, and advisory work.
Old names and obsolete roles are not deleted casually. Agent Resource archives them so history remains visible while the active naming model stays clean.
Example outcomes
Agent Resource repositioned itself from an older Planner/Ops Hub framing into the current Agent Resource model.
It migrated away from routine Todoist dependence into local Markdown backlogs.
It helped Wiki Articles become a Git-backed article source project with local roles, logs, backlog, communication folders, article structure, and Portfolio export folders.
It defined the article source-to-presentation contract between Wiki Articles and Portfolio, which later became the basis for public note snapshots.
It helped Portfolio, Holding, MilSim, LifeGraph, and other projects absorb reusable lessons around local roles, backlog structure, communication boundaries, design-system roles, and knowledge-model setup.
It also archived old accounting and usage-ledger routines when they stopped helping the workflow.
Boundaries
Agent Resource does not automatically synchronize every project.
It does not rewrite another project's backlog without local acceptance. It does not make local project lessons global without explicit promotion. It does not expose private owner material as public proof. It does not claim that every project agent is perfectly synchronized at all times.
Those limits are part of the system. They keep Agent Resource useful without turning it into a vague control layer.
Generalization
The pattern applies anywhere several agent-assisted projects need shared operating conventions.
Reusable roles, source-of-truth rules, backlog models, communication protocols, and inheritance boundaries become infrastructure. Each project can remain local and specific while still starting from a tested operating model.
Portfolio relevance
This project demonstrates:
- reusable agent role design
- project staffing from raw intent
- master-to-local inheritance
- Markdown backlog conventions
- cross-project communication protocol
- source-of-truth governance
- archive-first cleanup
- explicit boundaries between reusable rules and local project ownership
Agent Resource is the infrastructure layer behind several other Portfolio use-cases. It shows how agentic work can become more repeatable without pretending every project should be controlled from one place.