Three layers

ASMP is often described as “one registry.” In practice, personal agent infrastructure has three layers. Conflating them causes confusion — especially the “33-service drift” myth.

The three layers

┌─────────────────────────────────────────┐
│  DISCOVERY                               │
│  "Who provides email.ingest?"            │
│  Capability query → name, endpoint, repo │
├─────────────────────────────────────────┤
│  INVENTORY                               │
│  "What's on this machine?"               │
│  46 services, health, display, sections  │
├─────────────────────────────────────────┤
│  DEPLOYMENT                              │
│  "How does the platform run it?"         │
│  entrypoint, units, venv, sockets        │
└─────────────────────────────────────────┘

Layer	Question	Typical consumer	ASMP v0.1
Discovery	Who can do X?	Agents via MCP / GET /capabilities	capabilities.provides
Inventory	What exists here?	Dashboard, registry API, humans	Full service manifest
Deployment	How is it provisioned?	Reeves daemon, launchd, Caddy	Partial — run, lifecycle

They stack. Discovery queries inventory. Deployment realizes inventory on the host.

What each layer stores

Discovery

Capability-oriented, optimized for agent queries:

capabilities:
  provides: [email.ingest, email.parse]
  requires: [postgresql]

Agents call service_find(capability="email.ingest") — not grep for port 8787.

Inventory

Machine-oriented, optimized for monitoring and audit:

name: email
description: "Email ingestion, parsing, threading"
display:
  section: reeves
  critical: true
health:
  target: http://localhost:8787/email/healthz
repo: ~/repos-personal/reeves-email

Dashboards, humans, and policy engines read this.

Deployment

Platform-oriented, optimized for supervisors:

# Today often lives in apps.yaml — not yet fully in ASMP v0.1
entrypoint: web.app:app
port: 8770
venv: .venv
units:
  auto-sync:
    kind: job
    triggers: [{ interval_seconds: 300 }]

Reeves daemon, launchd generators, and socket paths need this.

One directory, multiple views

The goal is one inventory source (~/.asmp/services/) with consumers reading what they need:

Consumer	Reads
Registry API	Full manifest + health
MCP service_find	capabilities, endpoints
Dashboard	display, health, repo
Reeves daemon	Deployment slice (future: generated view or extended schema)
Caddy	endpoints, display.url

Deployment config may remain a generated view for platform apps until ASMP schema extends — not a second handwritten registry.

Common mistake: counting files as drift

Source	Count	Scope
~/.asmp/services/	46	Full machine inventory
Dashboard services.yaml	46	Same inventory (mirror)
Reeves apps.yaml	13	Deployable platform apps only

The 33 services in inventory but not in apps.yaml are not errors. They are knox, docker, claude-find, director-daemon — infrastructure that Reeves daemon does not deploy.

Real drift is two authorities saying different things to agents, not different counts for different jobs.

See Registry drift and Deployment layer.

Design implication

Before merging registries in code:

1. Inventory → ASMP manifests (done on production hosts)
2. Discovery → require capabilities.provides on every manifest
3. Deployment → ADR: extend ASMP or generate apps.yaml from Reeves-tagged manifests

Document the model first. Wire consumers second.