Agent Platform

What makes an agent more than a prompt with memory?

Problem​

A problem well-stated is a problem 80% solved

Situation: Five PRDs described one system from five angles. Engineering asked "where do I start?" Three CLIs, 23 templates, 16 agents — no coordination. Agents spend 5-10 minutes re-exploring what happened last session before doing any work.

Intention: One platform where every agent inherits identity, memory, comms, dispatch, and quality — so engineering builds domain knowledge, not infrastructure, and the system audits itself.

Obstacle: 4.3% flow efficiency. 130 minutes of work in 1-4 days of wait time. Dispatch is manual. Context recovery starts from zero. Communication is archaeology, not messages.

Hardest Thing: 48% of capabilities don't exist yet. But this platform must orchestrate its own engineering — the tool builds itself.

Priorities​

The Tight Five questions to unlock progress.

1. What makes an agent more than a prompt with memory?
2. Where does time die in the agent session lifecycle?
3. What unifies three CLIs, 23 templates, and 16 agents?
4. How does the platform graduate from CLI to open mesh?
5. Who coordinates — and what verifies the work?

Features​

Phase 0: Unblock Agent Profiles (0.5 day)​

• Add --path flag to agent-etl-cli (~20 lines, unblocks all future agents)

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

• Extract shared DB context from plan-cli pattern
• Build thin router (drmg dispatches to handlers)
• Seed context graph from filesystem
• Build 8-dimension auditors (one per enforcement dimension)
• Wire audit command with --dry-run flag

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

• Plan wrapper (delegate to plan-cli handlers)
• Agent module (absorb agent-etl + add status/recall/list)
• Data wrapper (delegate to data-interface-cli)
• Priority scorer (weighted formula from commissioning)

Phase 3: Communication Wiring (2 sessions)​

• Priority dispatch (priority table change → Convex message to meta channel)
• Session bootstrap from messages (startup hook loads team context)
• Session recovery (load recent messages on crash/restart)

Phase 4: Learning Engine (2 sessions)​

• Pattern extractor (cross-run trend detection)
• Memory writer (patterns → semantic, runs → episodic)
• Agent recall of VVFL patterns (shared semantic memory query)
• Action generator (critical findings → plan issues)

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

• Virtue auditor (read commissioning from dream repo)
• Commissioning dispatch (dream agent walks deployed URL, captures evidence)
• Report in L0-L4 format (VVFL speaks commissioning language)

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

• API route per drmg module (REST endpoints wrapping CLI handlers)
• CLI as thin client (drmg calls API routes instead of direct DB)
• Auth + rate limiting (API keys, per-agent rate limits)
• Web dashboard consumption (same endpoints serve UI and CLI)

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

• Agent Card definition (advertise capabilities per agent type)
• Task Card wrapper (map 8 message types to A2A Task lifecycle)
• A2A discovery endpoint (/.well-known/agent.json serves capabilities)
• External agent handoff (accept Task Cards from agents outside the mesh)

Progress​

• Purpose
• Pictures

Scorecard​

Priority Score: 600 (Pain 4 x Demand 5 x Edge 3 x Trend 5 x Conversion 2) — full evidence

Blocked by: Identity & Access (production auth). Kill date: none — mandatory infrastructure.

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

Blocks: All agent instances (Sales Dev, Content Amplifier, future ventures).

Ledger