Agent Platform

What makes an agent more than a prompt with memory?

Identity. Communication. Direction. Quality. Without all four, you have a chatbot that forgets. With all four, you have a team member that compounds.

The Job​

When the system needs agents that persist across sessions, coordinate across teams, receive directed work, and improve over time, help it operate agents as first-class participants — so every agent instance (Sales Dev, Content Amplifier, Orchestrator) inherits the same platform and only adds domain knowledge.

Pitch-Prompt Deck​

Five cards. Five headlines. Five pictures. The meme layer — 80 cents in the dollar.

Why This, Why Now​

Five separate PRDs described one system from five angles. Engineering would read them and ask: "Where do I start? Which one is the agent?" The answer was all of them and none of them. That's a specification problem, not an engineering problem.

One platform. Five concerns. Each concern is a section, not a separate spec.

What Already Exists​

The Agent Pattern​

Every agent in the system is an instance of a base pattern. The platform manages the lifecycle. Each instance carries domain-specific knowledge while operating within the same framework.

Base Pattern (Every Agent Has)​

Instance Examples​

Memory Lifecycle​

Working Memory (4-7 slots, loaded first each session)
  ↓ consolidation
Semantic Memory (proven facts, concepts, principles)
Procedural Memory (proven skills, steps, success rates)
  ↓ or
Decay (unrefined, not reinforced)

Episodic Memory (session records, last 10, emotional tagging)

Five Concerns​

1. Identity and Memory​

How agents persist knowledge across sessions.

The problem: Every session starts from zero. Decisions made last week are revisited this week. That's a compounding tax.

Kill signal: If agents with memory aren't measurably faster than agents without it, the memory is noise.

2. Communication​

How agents coordinate in real time.

The problem: Four agents on the same product communicate by merging code. That's archaeology, not coordination.

Kill signal: If session recovery time doesn't improve within 30 days, comms is adding overhead.

3. Dispatch and Execution​

How work gets routed to the right agent with the right plan.

The problem: Human reads priority table, opens terminal, manually starts session. Three CLIs, no coordination.

Kill signal: If spec-to-ship cycle time doesn't improve within 30 days, orchestration is ceremony.

4. VVFL Enforcement​

How the system audits itself and learns.

The problem: 5 generators, 23 templates, 17 rules, 13 skills, 16 agents. Nobody knows which are stale, broken, or unused. Quality degrades silently.

Kill signal: If after 5 audit runs, zero patterns lead to improvements, the measurement is ceremony.

5. Operational Bridge (drmg CLI)​

The cross-repo interface. Engineering agents run it to report state. Dream agents read the output to commission outcomes. The CLI is the product being dogfooded — the same operational bridge that customers use for their BOaaS operations.

Kill signal: If operators still use the old CLI paths after 30 days, the unified CLI isn't better.

The Read-Only Mesh​

Two repos. Three channels. Neither writes to the other's filesystem.

The audience for this PRD is engineering agents. They read it directly from the dream repo at /home/wik/code/drmg-mental-model/. The table order on phygital-mycelium/index.md is a live instruction set — top of table = build next. PRD commissioning tables are pass/fail criteria. This isn't a reference doc. It's the spec interface.

Three Channels​

DREAM REPO (WHY + WHAT)                    ENGINEERING REPO (HOW)
────────────────────                        ────────────────────
PRDs, priorities, commissioning             Plans, generators, code, drmg CLI
  │                                           │
  │──── READS files ──────────────────→       │  (PRDs, priorities, docs)
  │       ←──────────────────── READS files   │  (code, architecture)
  │                                           │
  │  CANNOT EDIT ───────────── x              │
  │            x ───────────── CANNOT EDIT    │
  │                                           │
  │  Channel 1: Filesystem reads              │
  │    Priority table = build order           │
  │    PRD commissioning = pass/fail          │
  │                                           │
  │  Channel 2: Convex messages               │
  │    8 typed message types                  │
  │    Async, persistent, per-channel         │
  │                                           │
  │  Channel 3: Supabase tables               │
  │    drmg CLI writes measurements           │
  │    Both repos read state                  │
  │                                           │
  ├─ Commissions independently                ├─ Ships, reports via drmg CLI

The Loop​

Dream team sets priorities (filesystem)
  → Engineering reads PRDs, composes plans
    → Engineering teams execute, report via drmg CLI (Supabase)
      → Dream team reads measurements, commissions outcomes
        → Gap between expectation and outcome drives next priority
          → Loop

The 8 message types are the vocabulary. The drmg CLI is the measurement interface. The filesystem is the spec interface. All three channels serve the same loop — the transport differs, the function is identical: close the gap between what was specified and what was shipped.

How It Gets Smarter​

The Graduation Path​

The drmg CLI is the product being dogfooded. The same agent platform that orchestrates our engineering teams is what customers use for their operations. The graduation path is three steps, each one testable, each one using the same 8 message types and the same Supabase tables. Only the transport layer changes.

Three Steps​

Message Types → A2A Mapping​

The 8 message types we use today map directly to A2A Task lifecycle states. No new vocabulary needed — just a protocol wrapper.

What Each Step Unlocks​

CLI → API: The drmg CLI becomes a thin client. Engineering agents call drmg plan active and it hits /api/planning/active instead of querying Supabase directly. Same command, same output. But now a web dashboard can call the same endpoint. The CLI and the UI share one source of truth.

API → A2A: The API endpoints get Agent Card and Task Card wrappers. An Agent Card advertises: "I can orchestrate engineering plans, run VVFL audits, manage agent profiles." External agents discover capabilities via A2A, send Task Cards, and the same pipeline processes them. The mesh opens from two repos to any participant.

The Dogfooding Proof​

Each step uses the same message types, same tables, same VVFL enforcement. If we can successfully orchestrate our own engineering and close the commissioning loop, that's a live demo of Results as a Service. The customer version is the same system pointed at their operations.

Kill signal: If the API step doesn't reduce integration friction vs direct CLI (measured by time-to-first-query for a new consumer), the abstraction layer isn't earning its keep. Ship the CLI as the product instead.

Success Criteria​

Functional​

Outcome​

Commissioning​

Identity and Memory​

Communication​

Dispatch and Execution​

VVFL Enforcement​

Unified CLI​

Build Sequence​

Phase 0: Unblock Agent Profiles (0.5 day)​

Phase 1: Unified CLI + VVFL MVP (3-4 sessions)​

Phase 2: CLI Wrappers (1-2 sessions)​

Phase 3: Communication Wiring (2 sessions)​

Phase 4: Learning Engine (2 sessions)​

Phase 5: Commission Loop (1-2 sessions)​

Phase 6: API Transport (3-4 sessions)​

Phase 7: A2A Protocol (2-3 sessions)​

Scope Control​

Risks + Kill Signal​

Kill signal: If agents on this platform aren't measurably more effective than agents without it (session recovery, cycle time, quality scores), the platform is overhead. Simplify to the 3 most useful features and drop the rest.

DB Tables (All Existing — No New Schema)​

Mycelium Capability​

The Agent Platform is the operating system for every agent in every venture. Identity, memory, communication, dispatch, and quality enforcement — composed from existing infrastructure, unified under the drmg CLI. The CLI is the product being dogfooded: the same operational bridge that orchestrates our engineering teams graduates to API routes, then to A2A protocol, then to customer-facing BOaaS operations.

Sales Dev Agent is the first instance. Content Amplifier is the second. Every future agent inherits the same platform and only adds domain knowledge. Every future customer gets the same platform pointed at their operations.

Currently Growing In: Platform — all ventures.

Context​

• Sales Dev Agent — First agent instance, proves the pattern
• Content Amplifier — Second instance, proves portability
• Intelligence Functions — Pure logic agents execute
• Data Interface — Table access agents consume
• Commissioning State Machine — Maturity automation this platform audits
• VVFL Loop — Philosophical framework made operational
• Feedback Loops — Why loops that learn are the most valuable asset
• Phygital Beings — Agent identity documentation
• Agent Protocols — MCP, A2A, ACP stack
• A2A Protocol — The graduation target for cross-repo communication
• Standards — Where VVFL patterns graduate when proven
• Phygital Mycelium — The capability catalogue