How It Works¶
Agentic Beacon is built around two components — the warehouse and the beacon — plus a small set of commands that move artifacts between them.
Mental Model¶
Agentic Beacon has two halves: a warehouse (a shared git repo of artifacts) and a beacon (per-project config that declares which artifacts this project needs). abc sync reads the project's declaration, follows the dependency graph through the warehouse, and creates per-file symlinks under .agentic-beacon/artifacts/ pointing into the warehouse clone.
| Concept | What it is |
|---|---|
| Warehouse | Shared git repo of contexts, skills, knowledge, and agents |
beacon.yaml |
Per-project file declaring the artifacts this project needs |
.agentic-beacon/artifacts/ |
Per-project symlink tree into the warehouse — gitignored, regenerated by abc sync |
abc sync |
Resolves the declared artifacts, follows their dependencies, creates the symlinks |
The warehouse is the single source of truth on a machine. Symlinks (not copies) mean every consuming project sees the same content with no drift.
The Warehouse¶
A warehouse is a plain git repository. It stores your team's shared agent artifacts in four directories:
my-org-warehouse/
├── contexts/ # boot instruction files
├── knowledge/ # decisions, lessons, facts
├── skills/ # reusable agent workflows
├── agents/ # global sub-agent definitions
└── docs/ # warehouse documentation
The four top-level directories are part of Beacon's schema — abc warehouse init creates them and abc warehouse lint enforces a minimal shape inside each:
contexts/— fully free-form. Use any subdirectory layout you like.skills/— each skill lives atskills/<name>/SKILL.mdwith required YAML frontmatter (name,description).knowledge/— leaf directories must be one of three taxonomies:decisions/,lessons/,facts/. The path shape isknowledge/[<topic>/]<type>/<name>.md; the optional topic prefix (e.g.python-standards/,infrastructure/) is yours to design.agents/— entries registered inagents/agents.yaml; each agent.mdhas required frontmatter.
Within those rules you have full freedom over topic grouping, subdirectory depth, and naming. The warehouse lives on any git host (GitHub, GitLab, Bitbucket); team members clone it locally.
The Beacon¶
Each project that consumes warehouse artifacts has a .agentic-beacon/ directory:
my-project/
└── .agentic-beacon/
├── beacon.yaml ← committed: declares which artifacts this project needs
├── config.toml ← gitignored: local warehouse path
├── pending.yaml ← gitignored: artifacts authored but not yet wired
├── .last-adopt ← gitignored: timestamp of last abc adopt commit
└── artifacts/ ← gitignored: symlink tree into warehouse
beacon.yaml declares three artifact types — contexts, skills, agents:
artifacts:
contexts:
- contexts/global.md
skills:
- skills/code-review/
agents:
- agents/spec-planner.md
Knowledge files are not declared — abc sync auto-derives them by scanning your adopted contexts and skills for markdown links into knowledge/.
pending.yaml and .last-adopt are working-state files managed by abc adopt — see Pending & Adoption for the full lifecycle.
The Sync Flow¶
abc sync does four things in one pass:
- Resolve — reads
beacon.yaml, follows skillrequires:frontmatter and agent declarations, then walks markdown links from contexts and skills intoknowledge/to auto-derive every transitive dependency. - Symlink — creates per-file symlinks under
.agentic-beacon/artifacts/pointing into the warehouse clone. - Wire — installs skills and agents into your detected AI tools (Claude Code, OpenCode), and appends adopted contexts to your tool's config file (
CLAUDE.md,opencode.json). Beacon is idempotent and non-destructive: re-running never duplicates entries, and only its own references are added or removed. - Prune — removes symlinks and config references for artifacts no longer declared.
For the full pipeline, flags, and edge cases, see the Adopting Artifacts guide. For per-type details (what wiring each artifact gets), see Artifact Types.
Symlink Model¶
abc sync creates symlinks, not copies. .agentic-beacon/artifacts/ is a tree of symlinks pointing into the warehouse clone. This means:
- One physical file per machine. No duplicate copies to drift out of sync.
- Edits go directly to the warehouse. Editing a symlinked file edits the warehouse working tree — no separate "push my changes back" step before contributing.
- Cross-project visibility. If two projects share the same artifact, editing it in Project A makes the change visible in Project B immediately.
This is what makes the contribution loop tight: there is no copy step, so the agent's edit is the warehouse edit.
The Contribution Loop¶
The workflow is bidirectional, and most edits happen inside an agent session. The agent either edits symlinked warehouse files directly, or uses one of the bundled authoring skills (record-knowledge, record-skill) — these write to the warehouse and append a wiring entry to pending.yaml. abc adopt then promotes pending entries into beacon.yaml, and abc sync refreshes symlinks so the new artifact is immediately usable. To push the warehouse changes upstream, invoke the /contribute-warehouse bundled skill — it lints, scans for duplicates, splits the changes into cohesive commits, and atomically pushes once.
abc adopt and abc sync both run on each side of the loop — abc adopt to wire your own pending entries (from authoring skills you ran), abc sync to refresh symlinks against the current warehouse HEAD.
Next: Artifact Types¶
Each artifact type has distinct behavior around installation, scope, and contribution. → Artifact Types