Metis — Vision

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

The Five Documents

This PRD is split across five pages — read the overview here, then pick whichever layer is relevant to your work.

What Metis Is

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.

Metis exists because we believe software delivery is about to be reshaped by AI agents, and the teams that win will be the ones that treat agent work the way they treat every other serious engineering input: with structure, observability, and earned trust. Not as magic, not as a toy, and not as a replacement for human judgment — but as a capable contributor inside a system that knows when to ask a person and when to proceed on its own.

What Metis Is For

Metis is for organizations that want to move the human effort in software delivery toward the decisions that matter most: defining intent, approving requirements, reviewing architectural boundaries, judging risk, authorizing releases, and improving the system over time. It pushes the repetitive, mechanical, and well-specified work down into structured workflows where AI agents can operate inside defined roles, with the right tools, against the right guardrails.

The target audience is every project inside our organization that wants a repeatable, observable, traceable path from idea to release — without each team having to reinvent the harness.

What Metis Is Not For

• Metis is not a general-purpose automation platform. It is specifically focused on governed software development.
• Metis is not a replacement for human accountability. Human approval, ownership, and oversight remain central, especially for product intent, architectural direction, security-sensitive decisions, complex tradeoffs, and production release authority.
• Metis is not a single-user productivity tool. It is explicitly a team platform, designed for human-agent collaboration at an organization’s scale.
• Metis is not an experiment in AI autonomy. Autonomy is earned through evidence, never assumed, and the system is designed to make the earning visible.

What We Believe

Six beliefs shape every design decision. They are elaborated in 02-principles.md, but every reader of this document should leave knowing these:

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 a piece of institutional memory. Workflows are where determinism, tooling, guardrails, and agents meet.
2. Hard walls, not soft rules. Rules files describe intent; deterministic checks enforce it. The platform sits between the agent and the code, injecting only the right tools in the right environments, and re-guiding agents back to constraint when they drift.
3. Humans gate intent and release; AI drafts the middle. The boundaries of a piece of work — what it is, when it ships — are human decisions, surfaced at explicit gates. The middle, where most of the mechanical effort lives, is where agents earn their keep.
4. AI earns automation through evidence. Trust is not declared, it is observed. 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, and injected into the right workers at the right time. Every project should start from the best of what every other project has learned.
6. Consistency and autonomy pull against each other, and the platform holds that tension. Some capabilities belong to everyone, everywhere. Some belong to a single project. A healthy platform lets both exist without picking a side; it makes the seams visible, the defaults sensible, and the overrides traceable.

How These Documents Are Organized

This is the first of five files that together describe the history, principles, current state, and intended direction of Metis. Each file stands alone; you do not need to read them in order, and they do not link to each other. If a fact matters, it has been written in wherever it is needed.

• 00-overview.md (this document). The durable north-star. What Metis is, who it is for, what we believe, and a guide to the rest of the set.
• 01-history-and-inspirations.md. The narrative journey. How I arrived at the current vision, what I was originally trying to build (ADS), why I forked Archon rather than building from scratch, and what obra/superpowers, taskmaster-ai, hamster, and a personal experiment using Codex to review Claude each taught me about what Metis needs to be.
• 02-principles.md. The operating tenets. Twelve principles grouped into five clusters, each credited to the source that shaped it, with what it looks like in Metis today and what we are still building toward.
• 03-current-state.md. The capability snapshot. What Metis can do today, where the boundaries are, and the shape of the deployment. Refreshed as the platform evolves; not a history of how it got here.
• 04-future-direction.md. The gap analysis. Twelve named problems between today’s Metis and the vision, with ideal-state descriptions and examples of each shape from other platforms that have solved adjacent versions of the problem.

Reading Paths

Which files to read in which order depends on why you are here.

• New engineer joining the project. Read 00-overview.md, then 01-history-and-inspirations.md for context on why the platform exists the way it does, then 03-current-state.md for what you will actually be working on. Return to 02-principles.md and 04-future-direction.md when you need to make a design call.
• Stakeholder assessing the direction. Read 00-overview.md and 04-future-direction.md. They together describe where we are aiming and what we do not yet have.
• Technical lead making an architecture decision. Read 02-principles.md first for the decision framework, then 03-current-state.md for the current boundaries, then 04-future-direction.md to see where the capability you are touching is headed.
• Future steward returning after context loss. Read in order: 00, 02, 04, 01, 03. The north-star and the principles remind you what the platform is for; the future doc reminds you where it was pointed; the history grounds why those calls were made; the current state catches you up on the present.

A Small Glossary

The inspirations and predecessors behind Metis use different vocabulary for similar concepts. This glossary maps terms as they appear in the sources this document set draws from, so the rest of the docs can use whichever reading fits the context.

Terms used throughout the set without formal glossing — workflow, node, run, conversation, codebase, worktree, isolation environment, BYOK, event bus, worker — carry the meaning they have in the current Metis implementation. Where a future-direction document uses a term from ADS or hamster, it is doing so deliberately, because that source’s shape is the nearest published analog to what the platform will need.