Metis — AI-Native Delivery Platform

Andi Lamprecht ·2026-05-11· 9 min read· Draft

1. Executive summary

Metis is a hosted, team-scoped platform for governed human–AI software delivery. It is the place where product intent becomes a brief, a brief becomes a plan, a plan becomes work, and work becomes a release — with humans directing the decisions that matter, AI drafting and executing in structured workflows, and every artifact in that chain preserving context, accountability, and evidence.

This proposal brings Metis under the May 2026 umbrella as the AI-native workflow substrate for process modernization (Primary Outcome 6) and as a concrete anchor for demonstrability (Primary Outcome 5). The scope is deliberately narrow for May: stand up Metis on staging, migrate the May 2026 PRDs and scoring process onto it, and run at least three governed workflows end-to-end — intent → plan → run → PR → retrospective — with full traceability. Production bring-up is out of scope.

2. Why this belongs under the May 2026 umbrella

The umbrella PRD commits to six outcomes. Metis contributes directly to three:

• Modernization (M) — primary. Metis makes “AI-native by default” structural rather than cultural. Canonical ADRs, machine-readable requirements and verifications, AI-legible workflows, and AI-assisted board tooling all gain a single platform of record rather than being stitched together across Confluence, GitHub, Jira, and chat.
• Demonstrability (D) — secondary. The golden-path demo is itself a workflow. A Metis workflow that exercises the full Uncrew flow — authentication → mission plan → UTM authorization → takeoff → telemetry → contingency → landing → audit — runs on every trunk merge, produces a durable, linked artifact, and blocks merge on failure.
• Unification (U) — tertiary. Every scattered delivery-process tool (ADRs in Confluence, plans in repo markdown, reviews in PRs, retrospectives in Fellow, board minutes in Slack threads) collapses into one platform with one context graph.

Metis does not replace Jira, GitHub, or any of the engineering tooling. It sits above them as the governed-delivery harness that binds intent to release.

3. Target state (what Metis looks like when we are done, not this month)

Six beliefs that shape every design decision

1. Workflows are the delivery vehicle for every capability. If a capability matters, it becomes a workflow — not a one-off script, not a human ritual, not institutional memory.
2. Hard walls, not soft rules. Rules files describe intent; deterministic checks enforce it. The platform sits between the agent and the code.
3. Humans gate intent and release; AI drafts the middle. The boundaries of a piece of work are human decisions at explicit gates.
4. AI earns automation through evidence. Trust is observed, not declared. The platform measures, records, and surfaces agent performance so automation can be extended where it works and constrained where it does not.
5. Reusability and centralization are first-class. Skills, commands, MCP configurations, scripts, and workflows are shared organizational assets, managed in one place, versioned, injected into the right workers at the right time.
6. Consistency and autonomy pull against each other; the platform holds the tension. Some capabilities belong to everyone; some to one project. The platform makes both possible, makes the seams visible, and makes overrides traceable.

Capabilities Metis has today (staging)

• Identity and access — GitHub OAuth, organization-scoped, audit-logged ownership/visibility/admin actions.
• First-class resources — workflows, commands, scripts, skills, and MCP configurations as DB-backed, team-shared, version-history-tracked assets with a three-layer precedence (project > platform > bundled).
• Bring-your-own-key credentials — personal Anthropic/OpenAI keys in a secret store; enterprise fallback configured by admin.
• GitHub-integrated codebase registration — via GitHub App, installation-token clones, per-codebase env vars.
• Queue-backed workflow execution — isolated git worktrees, durable execution snapshots, one-shot workers, artifact persistence.
• Observability through the event stream — structured events, audit log, SSE-streamed UI, correlatable logs.
• Workflow authoring — YAML in .metis/workflows/ or a form-driven builder UI.
• Ownership locks — heartbeat-based active-use locks on conversations and isolation environments (in final validation).

Capabilities Metis explicitly does not have yet

• First-class intent/brief artifact with approval gate.
• Requirements decomposition with a collaborative gate between “drafted” and “implementation begins.”
• Indexed, queryable context graph across artifacts.
• Multi-agent critique as a bundled node type.
• Work queue with WIP limits.
• Webhook-driven intake (GitHub Issues, Slack, Linear → Metis brief).
• Reusable project blueprints at the team level.
• Visual DAG workflow editor.
• Persistent worker pools, warm container caches, cross-run checkpoint resume.
• Two-way integration with external work trackers.
• Trust-calibration model converting evidence into progressive automation.
• Cross-project analytics dashboards.
• First-class governance artifacts produced by the platform (ADRs, retrospectives, change records).
• CLI surface backed by the shared execution model.

These are named in §6 as candidate follow-ups, not May-2026 commitments.

4. Regulatory & compliance

• Metis staging is not in scope for Part 135 certificate configuration control.
• No PII, PHI, or flight-operations data lives in Metis; artifacts are engineering-process artifacts (briefs, plans, runs, retrospectives).
• BYOK credentials live in the secret store, never the application DB; keys are never echoed back after save.
• All ownership and visibility changes write audit log entries; administrator overrides are logged.

5. May 2026 scope

5.1 In scope

1. Metis on staging. Stand up (or promote) the hosted staging deployment as the canonical Metis instance for the organization. Named admins; GitHub App installed; enterprise API-key fallback configured.
2. PRD-0002 lives on Metis. The May 2026 umbrella PRD, the rubric, the scoring table, and every proposal PRD are registered as Metis artifacts with explicit owners, visibility, and version history. The scoring survey feeds the scoring table through a Metis workflow, not a Google Form.
3. Three governed workflows delivered end-to-end. At least three of the following run from approved intent to merged PR with full traceability, selected based on early value:
   • Intent capture. A first-class “brief” artifact with a human approval gate, replacing ad-hoc conversation drafts for all May 2026 work.
   • Plan critique. A critique → reconcile bundled workflow pattern, applied to every plan authored under PRD-0002.
   • Golden-path demo as workflow. The Uncrew end-to-end demo from PRD-0002 §5 runs as a Metis workflow on every trunk merge, producing a durable artifact and blocking merge on failure.
   • Retrospective-as-workflow. After each of the three workflows above runs to completion, a retrospective workflow produces a structured artifact linked back through the context graph to the originating brief.
4. Canonical ADR home. ADRs migrate from Confluence and per-repo folders into Metis, produced by a workflow and linked to the intent that authorized them. An “Accepted” ADR without a linked implementation is a visible, triage-able lint.
5. Dogfood telemetry. Baseline metrics published: workflow success rate, human-override rate, cost per successful outcome, time-to-approval-gate. These are the inputs to the future trust-calibration model.

5.2 Out of scope for May 2026

• Production bring-up of Metis (deferred until staging is shaken out).
• Webhook-driven intake from GitHub Issues, Slack, Linear, or email.
• Visual DAG workflow editor.
• Persistent worker pools, warm containers, checkpoint resume, large-repo optimization.
• Two-way sync with Jira/Linear.
• The full context graph UI (in-platform queryability is enough; a navigable cross-artifact graph UI is a follow-up).
• Trust-calibration model converting evidence into progressive automation (we collect the telemetry; we do not yet close the loop).
• Rebuilt CLI surface.
• First-class “blueprint” concept for reusable project patterns.

6. Technical specifications

• Deployment shape. Stateless web/API service; one-shot workers in isolated containers; managed Postgres; private object storage; secret store; dispatch queue; event bus. Production is GCP-native; local dev uses Docker Compose emulators.
• Isolation model. Workflow work runs in a git worktree so a runaway agent cannot damage the live checkout.
• Resource precedence. Project (.metis/ in target repo) > platform (DB-backed) > bundled (image-embedded). Workers materialize the merged set on each run.
• Event bus. SSE-streamed events to the web UI; Pino-backed structured logs correlated end-to-end.
• BYOK + enterprise fallback. Per-user keys resolved first, enterprise key second, fail-fast on absence.
• Audit log. Every ownership transfer, visibility flip, admin action logged and visible through the admin UI.
• Three environments. Local dev; hosted staging (May 2026 target); hosted production (deferred).

7. Risks & phased rollout

Risks

• Adoption drag. Teams already run on Confluence/Jira/GitHub and will resist a new surface. Mitigation: Metis does not replace any of those; it sits above them. First uses are delivery-process artifacts (briefs, plans, retrospectives) that have no incumbent home, not PR review or issue tracking.
• Agent runaway cost. BYOK caps per-user exposure; enterprise fallback is admin-gated. Mitigation: Telemetry on cost-per-successful-outcome from day one; budget caps surfaced in §5.1 dogfood telemetry.
• Workflow-engine drift from reality. A workflow that does not match how the team actually works becomes shelfware. Mitigation: The three May-2026 workflows are chosen because they are already how we work — we are making the existing process governable, not inventing a new one.
• Cross-product platform risk. Metis is hosted separately from Uncrew/ATOMx and could become a distraction. Mitigation: Staging-only in May; production bring-up gated behind evidence from dogfooding.

Phased rollout

1. Week 1: Staging deployment promoted to canonical; GitHub App installed; bundled workflows and skills seeded; admins named.
2. Week 2: PRD-0002 artifacts registered; scoring workflow replaces the Google-Form-equivalent survey.
3. Weeks 2–3: First governed workflow (intent capture) live; all new May 2026 PRDs authored through it.
4. Weeks 3–4: Second and third workflows (plan critique, golden-path demo) live.
5. Week 4: Retrospective workflow runs against the first two; baseline dogfood telemetry published.
6. End of May: Decision point on production bring-up, based on staging evidence.

8. Estimation input

9. Open questions

• Does Metis staging share Okta integration with the rest of the DroneUp platform, or remain GitHub-OAuth-only until production bring-up?
• Where do ADRs physically live after migration — in a Metis-owned store surfaced back to this docs site, or in this docs site with Metis as the lifecycle manager?
• Which two of the three candidate workflows (plan critique, golden-path demo, retrospective) should be cut if we only land two?
• What is the minimum cost telemetry we need before we will trust any progressive-automation claim in a follow-up cycle?

10. References

• Metis — Vision Overview (00-overview.md, internal)
• Metis — Operating Principles (02-principles.md, internal)
• Metis — Current State (03-current-state.md, internal)
• Metis — Future Direction (04-future-direction.md, internal)
• PRD-0002 May 2026 Unification, Simplification, Stabilization