The Agentic Collaboration System (ACS) is a classification framework for every operational artifact in 📝human–AI collaboration — the policies, procedures, loops, commands, roadmaps, reports, and context memos a person and their agents run on. It sorts all of them into four planes (Logic, Binding, State, Context), eleven classes, and two layers — a general, shareable core and project-specific instances — so any "thing you do" with agents has exactly one home and a 📝single source of truth. It exists to fight drift: agentic collaboration moves faster than human memory, so without a deciding heuristic and lifecycle-bound state, the same idea gets re-created under different names and stale records accumulate until nothing is clearly canonical. ACS keeps a system legible faster than memory can lose it — reusable across every project, repo, and device, and adoptable by any operator.

Quick Reference

Four planes answer four questions about any artifact — does it say what to do, trigger something, track what's happening, or orient a run to its terrain?

• Logic (say) → Policy · Procedure · Loop
• Binding (trigger) → Command · Hook · Script · Skill
• State (track) → Roadmap · Initiative · Report
• Context (orient) → Context

The Four Planes

Every operational artifact is Logic (what to do), Binding (how it's triggered), State (what a run reads and writes), or Context (what a run reads to orient). Logic, State, and Context are durable knowledge — they live in your knowledge system as the source of truth. Binding lives in the repo or agent harness as thin pointers, distributed wherever you work.

Logic — what to do

Durable instruction artifacts, honed over time.

• Policy — Prescribes. Standing rules and constraints, always in force; not steps to run.
• Procedure — Runs on demand. Ordered steps you hand work to; ends in a close-out receipt.
• Loop — Runs on a timer. Steps an agent self-triggers, finding its own work; cheap when there's nothing to do.

Binding — how it's triggered

Thin triggers that invoke Logic. They live where you work and never hold the logic themselves.

• Command — Triggers by hand. A human-invoked pointer to a Logic artifact, not the logic.
• Hook — Triggers on an event. Fired automatically by the harness on a lifecycle event.
• Script — Runs code. Deterministic, same result every run, no agent judgment.
• Skill — Loads capability. An instruction/code bundle an agent pulls in on demand.

State — what a run reads and writes

Working surfaces and records. Every State class declares a lifecycle — birth, relevance window, cull trigger, and where its relevance transitions when done — so stale state removes itself instead of piling up. The principle: hygiene rides the event (a completion, a ship), not a scheduled sweep.

• Roadmap — Tracks work. Items move Backlog → Working, per domain. A completed item leaves the roadmap — its record lives in version control — so the roadmap never accumulates a Completed pile.
• Initiative — Tracks a scoped push. Born to die; deleted and harvested on completion — the roadmap entry and the run's report are the permanent record.
• Report — Records a run. The append-only receipt that outlives the session, culled after a short window once its relevance has moved to history.

Context — what a run reads to orient

Persistent operating substrate an agent reads before working. It describes the terrain — it does not prescribe, trigger, or track work.

• Context — Describes. A repo or project's operating manual — how it's built, its services and storage, its standing shape, and a current-state snapshot — read to orient; never prescribes (rules go to a Policy), triggers, or tracks. Its content lives at the narrowest scope where it's true: a small project is one node; a large one keeps the root navigational and pushes the manual to a scope child. Persistent — updated in place, retired only when the project ends. A project's Context roots at the project's product memo and is the hub the project's artifacts point their # Parent at; its children are the project's domains (its sub-areas), and a whole class of artifact — all its loops, all its policies — is found as a tag view the hub links and itself joins.

The Heuristic

Classify anything new top-down:

1. Does it SAY what to do, TRIGGER something, TRACK what's happening, or ORIENT a run to its terrain?
   say -> LOGIC   trigger -> BINDING   track -> STATE   orient -> CONTEXT

LOGIC:    Always-in-force rules?                    -> Policy
          Steps, work handed to it on demand?       -> Procedure
          Steps, agent finds its own work on timer? -> Loop

BINDING:  Fired by a human?             -> Command
          Fired by a lifecycle event?   -> Hook
          Runs code deterministically?  -> Script
          Loaded as agent capability?   -> Skill

STATE:    Record of what happened?      -> Report
          Ongoing per-domain tracker?   -> Roadmap
          Bounded, born-to-die push?    -> Initiative

CONTEXT:  Standing manual read to orient? -> Context
          (it describes; rules that prescribe are Policy)

The Load-Bearing Rule

This is what makes one process reusable across every repo and device: the Command is a disposable pointer you sync wherever you work; the Procedure it names is the durable thing you edit once.

Two Layers — General and Instance

The same class lives at two layers. Build at the general layer by default; drop to an instance only when an artifact is genuinely bound to one repo, account, or business context — and when you do, the instance specializes the general one, it never forks it.

• General — context-free, shareable artifacts any operator could adopt: a general Policy, Procedure, Loop.
• Instance — a specific operating context (a person, a company, a product, a codebase), each its own namespace, specializing or extending the general layer.

Tags

Three tag families, composed under each artifact's namespace:

• Membership — the namespace slug: a general slug for shared artifacts, or an instance slug (e.g. #yourproject) for instance artifacts. One layer per artifact.
• Classification — #<namespace>-<class>, always the live class name: #<ns>-policy, #<ns>-procedure, #<ns>-loop, #<ns>-roadmap, #<ns>-context, and so on.
• Status — #<namespace>-active / -dormant / -deprecated, where lifecycle state varies (loops especially).

They compose: an active loop in a project is #<ns>-loop + #<ns>-active, so a two-tag search lands straight on it. These families replace ad-hoc operational tags — they don't pile on top. One refinement: a project's Context hub also carries the class tags of the collections it indexes (its loops, its policies), so the hub lists alongside the artifacts it organizes.

What's Out of Scope

This classifies how the system runs — not what your library knows. Reference content (people, companies, products, documentation) is a separate knowledge layer with its own conventions; it isn't an operational artifact and doesn't take a plane. The one sanctioned bridge: a project's Stewardship Context roots at its product/entity memo.

Why It Exists

Agentic collaboration moves faster than human memory. Without a single home for every operational artifact, the same idea gets re-created under different names, stale records pile up, and no one can reconstruct what's canonical. One root, four planes, a deciding heuristic, and lifecycle-bound state keep the system legible faster than memory can lose it.