Agent Platform
One platform, every agent.
1Principles
ValuesBeliefsControls
One platform, every agent.
- Five PRDs described one system from five angles — engineering asked "where do I start?"
- The answer: one platform with five concerns, not five separate specs
- Every agent inherits identity, memory, comms, dispatch, quality
- Domain knowledge is the only variable — infrastructure is shared
| Problem | Question | Decision |
|---|---|---|
| 5 specs, 1 system | Where does engineering start? | One platform: 5 concerns as sections |
Split screen: five PRD titles on the left converge into one platform blueprint on the right. Below: the same base pattern cloned three times with different domain labels.
2Performance
ValuesBeliefsControls
Ten minutes lost each session.
| Metric | Current | Target |
|---|---|---|
| Session recovery | 5-10 min | <30 sec |
| Flow efficiency | 4.3% | >15% |
| Spec-to-ship cycle | 1-4 days | 2x faster |
| VVFL findings resolved | 0% | >50% |
| Problem | Question | Decision |
|---|---|---|
| Agent starts from zero every session | How much does forgotten context cost? | Memory + messages = 80% recovery reduction |
Timeline showing 130 minutes of work stretched across 4 days of wait time. Red zones at dispatch and commissioning gaps.
3Platform
ValuesBeliefsControls
Everything built, nothing unified.
| Exists | Wire | Build |
|---|---|---|
| Plan CLI (2842 lines) | Shared DB context | Thin router |
| Agent ETL (3 loaded) | Agent module wrapper | VVFL 8 auditors |
| Comms CLI (8 types) | Data module wrapper | Priority scorer |
| Problem | Question | Decision |
|---|---|---|
| 3 CLIs, 23 templates, 16 agents | What unifies them? | drmg thin router: one entry, same handlers |
Three CLI terminals side by side, each with different commands. Arrows converge into a single 'drmg' terminal with one entry point.
4Protocols
ValuesBeliefsControls
CLI today, protocol tomorrow.
CLI (now) → API (next) → A2A (then)
Same 8 message types through all three steps
| Step | Transport | What Stays |
|---|---|---|
| CLI | Direct DB | Message types, tables, VVFL |
| API | HTTP routes | Same commands, same output |
| A2A | Task Cards | Same pipeline, standard protocol |
| Problem | Question | Decision |
|---|---|---|
| Agents trapped on one machine | What opens the mesh? | Same messages, A2A wrapper |
Three-step graduation diagram: CLI box connected to API box connected to A2A mesh. Same message types flow through all three.
5Players
ValuesBeliefsControls
Agents coordinate by merging code.
| Channel | Transport | Direction |
|---|---|---|
| Filesystem | Local FS | Both read, neither writes |
| Convex | DB messages | 8 typed message types |
| Supabase | drmg CLI | Engineering writes, both read |
| They Say | They Mean |
|---|---|
| "We need better tooling" | "I waste time figuring out what happened last session" |
| "Agents can't coordinate" | "Communication is archaeology, not messages" |
| Problem | Question | Decision |
|---|---|---|
| Four agents, same product, code merges | What replaces archaeology? | Structured messages on typed channels |
Before: four agents digging through git archaeology. After: structured messages flowing through typed channels between dream repo and engineering repo.
1 / 5
Five Questions
- What makes an agent more than a prompt with memory?
- Where does time die in the agent session lifecycle?
- What unifies three CLIs, 23 templates, and 16 agents?
- How does the platform graduate from CLI to open mesh?
- Who coordinates — and what verifies the work?