BMAD and Micrantha: Workflow Discipline on a Governed Substrate

I recently reviewed BMAD Method against the agentic software-delivery architecture I have been building across Micrantha.

The interesting result is not just that they overlap. Micrantha’s components appear to accommodate BMAD coherently despite never being designed around it.

BMAD emphasizes structured planning, bounded implementation units, durable handoffs, specialized agents, verification, and explicit workflow state. Its unattended build model is particularly sensible: one worker handles one bounded unit and reports a terminal result, while an orchestrator decides what happens next.

That is close to the model I have arrived at for long-running agent work:

Run = Goal + Context + Policy + State + Evidence + Budget

A graph, ticket tree, workflow, or state machine may organize a particular run, but none is the first-class abstraction. They are possible projections of context and current state.

The major difference is where those responsibilities live.

Similar mechanics, different boundaries

BMAD is increasingly more than prompt convention. Its unattended tooling includes deterministic orchestration, resumable state, bounded retries and gates, and workspace isolation.

Micrantha goes one level lower by separating those concerns into independently owned components and sources of truth.

Conceptually:

BMAD can contribute methodology, decomposition, and development context that tell an agent what work makes sense next. That does not mean the workflow itself automatically becomes the identity, authority, source of truth, or execution boundary for everything that follows.

The accidental fit is the interesting part

None of this was designed around BMAD.

Invokrum emerged because effective context composition needed deterministic identity. Keylix emerged because actors, delegated authority, and protected effects need authenticated identity rather than self-asserted role metadata. Anthesis emerged because authenticated identity still does not imply that an effect is authorized.

Dubnium grew into the runtime around supervision, model access, capability mediation, scheduling, recovery, and durable state through the Memory API. Repora emerged because repositories themselves needed an explicit model: identity, topology, canonical endpoints, observed state, desired state, plans, reconciliation, and controlled mutation.

Sandcastle addresses mutable execution state and lineage. Testule addresses portable verification requirements and evidence.

Only afterward did I place BMAD beside the architecture and notice how cleanly the responsibilities lined up.

independently motivated components
              ↓
      explicit responsibility boundaries
              ↓
 third-party workflow happens to fit
              ↓
 evidence that the abstractions may compose

That is more interesting than deliberate compatibility.

It suggests the boundaries may be at roughly the right level: BMAD fits because the abstractions are general, not because Micrantha contains BMAD-specific knowledge.

That is not proof that the architecture is correct, but it is a useful architectural signal.

A second accidental fit strengthens the signal

Reviewing GitHub Spec Kit afterward made that signal stronger.

BMAD and Spec Kit organize software delivery differently. BMAD leans toward roles, workflows, bounded stories, handoffs, and specialized engineering agents. Spec Kit leans toward specifications, plans, tasks, artifact analysis, and convergence.

Yet both can map onto essentially the same Micrantha boundaries.

BMAD                              Spec Kit
roles / stories / workflows       specs / plans / tasks
TEA / review                      analyze / converge
              \                  /
               development intent
                       ↓
                   Invokrum
                       ↓
               Dubnium Supervisor
                       ↓
              governed capabilities
                       ↓
               Keylix + Anthesis
                       ↓
         Repora / Sandcastle / Testule

That matters because the architecture is no longer merely compatible with one external methodology. Two independently designed approaches to agentic software development can occupy the methodology layer without requiring the underlying identity, authority, state, repository, or evidence models to change.

The stronger hypothesis is therefore that software-development methodology is replaceable context above the control substrate.

Micrantha has a native methodology stack too

That does not mean Micrantha has no methodology of its own.

Its native comparable stack is deliberately smaller than BMAD or Spec Kit: RFCs, QART, and ADRs.

• RFCs make a proposed architecture explicit enough to challenge before it quietly becomes infrastructure.
• QART makes the consequential choice explicit: Questions, Alternatives, Recommendation, and Trade-offs.
• ADRs preserve the architectural decision that was actually taken, including its rationale and consequences.

They are related, but not a mandatory linear workflow. QART can appear inside an RFC, before one, or during review. An ADR normally records a decision after the relevant design space has been explored.

Conceptually:

BMAD                   Spec Kit                Micrantha-native
roles / stories        specs / plans           RFCs
workflows              tasks                   QART
TEA / review           analyze / converge      ADRs
       \                    |                    /
                  development intent
                           ↓
                       Invokrum
                exact effective context

I keep wishing more of the early AI systems, agent frameworks, and tool architectures had started as RFCs.

Maybe RFCs are a relic of an earlier Internet culture. If so, I want the relic back. They force assumptions, alternatives, risks, and unresolved questions into the open before a proposal quietly becomes infrastructure; ADRs preserve what was actually decided and why.

That matters even more in AI, where a prompt format can become a protocol, a tool declaration an execution model, or an agent role an identity and authority boundary before anyone has really named the decision.

The distinctions matter:

proposal
   !=
decision
   !=
implementation
   !=
evidence
   !=
authority

Code can show what survived. RFCs, QART analysis, and ADRs preserve why the system took that shape in the first place.

That gives Micrantha a small native design-and-decision discipline without making it the control plane. RFCs, QARTs, ADRs, BMAD, and Spec Kit can all contribute intent. Invokrum still determines the exact effective context, and none of those artifacts can grant themselves execution authority.

Where Micrantha goes further

Some of BMAD’s current design discussions touch exactly the class of problems Micrantha tries to make explicit: attributable resumed and parallel runs, explicit repository targeting, visible and approval-aware persistent customization, and reliable memory persistence.

These are not uniquely BMAD problems. They are symptoms of the transition from an agent that suggests work to a system that performs consequential work.

Repora is a good example. The problem is not simply choosing the correct working directory before running Git. The stronger model is:

project / repository topology
          ↓
authoritative repository identity
          ↓
exact observed state
          ↓
desired state
          ↓
deterministic plan
          ↓
fresh precondition check
          ↓
controlled effect
          ↓
verified resulting state

Repora is therefore not just a safer Git wrapper. It is intended to be a source of truth for repository relationships and repository-control state, with mutation derived from that model rather than inferred from whatever checkout an agent happens to occupy.

Authorization follows the same pattern.

A model claiming to be an approved worker is not enough. The principal must be authenticated and delegation constrained through Keylix, and the requested effect must still satisfy Anthesis policy and approval.

claimed actor / role
        ↓
Keylix identity + delegation
        ↓
exact requested effect
        ↓
Anthesis policy + approval
        ↓
authorized capability

The same distinction applies to workflow declarations themselves. A project file may declare a command, hook, validation step, or required workflow transition. That declaration can be legitimate development intent, but it does not by itself grant permission to perform the effect.

workflow says "run X"
         ≠
authority to run X

The declaration can inform the Supervisor. Capability and effect admission still belong to the runtime and governance boundary.

Persistent guidance is similarly not simply written and subsequently trusted. Persistence is not promotion. Identity is not authority. Evidence is not authority. And runtime state is not whatever the model currently remembers.

BMAD still has patterns worth borrowing

There are BMAD ideas worth carrying back into Micrantha.

Workflow depth scales with task size rather than forcing every change through heavyweight ceremony. Project context is deliberately focused on things agents cannot reliably rediscover. Worker/orchestrator separation is explicit.

BMAD’s Test Engineering Architect work is especially interesting. TEA focuses on testing strategy, risk, traceability, NFR assessment, and quality gates, while Testule is developing a lower-level portable requirement and evidence substrate.

A plausible composition is:

BMAD TEA
  decides what should be tested
            ↓
        Testule
  represents requirements
            ↓
native test / analysis tools
            ↓
normalized Evidence

That is complementary rather than competitive.

Spec Kit adds another useful methodology-layer idea: make convergence explicit. Its converge command uses a compact vocabulary for differences between stated intent and implementation: missing, partial, contradicts, and unrequested.

That classification is useful precisely because it does not have to decide severity, root cause, priority, or authorization. It describes the relationship between intent and implementation; the rest of the system still decides what that difference means and what, if anything, is allowed to happen next.

BMAD as a workload

The stronger experiment is therefore not replacing Micrantha with BMAD.

It is running BMAD through Micrantha.

If that works, BMAD supplies software-development methodology and context without needing to become the trusted identity, authorization, repository-control, state-management, or verification substrate.

That also means BMAD does not need to absorb all of Micrantha to benefit from it.

BMAD starts from software-development workflow and increasingly adds the deterministic machinery needed to make autonomous development practical.

Micrantha starts from context, explicit sources of truth, authenticated identity, bounded authority, durable state, provenance, reproducibility, and failure containment, then allows different workflows to operate across them.

The convergence is real, but so is the distinction.

BMAD is building a better autonomous development workflow.

Micrantha is increasingly building a substrate on which BMAD, Spec Kit, and future autonomous-development methodologies can be treated as replaceable clients rather than trusted control planes.

The design target is not a particular workflow graph or agent methodology. Those can change.

The target is an autonomous software-delivery system in which goal, context, identity, authority, durable memory, repository truth, execution, and evidence remain independently identifiable and governable even when the reasoning and workflow are probabilistic.