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.

The linked repositories are the public or community entry points for those projects. Some publish contracts, documentation, examples, and design discussion while the corresponding implementation remains private.

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, durable run state, and a separate memory subsystem. The Workflow Runtime and scheduler own structured execution state; the Memory System owns durable context, retrieval, lifecycle, and learning. 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, and specialized agents; Spec Kit toward specifications, plans, tasks, analysis, and convergence. Yet both map onto essentially the same Micrantha boundaries.

That suggests software-development methodology can remain replaceable context above the control substrate rather than being baked into identity, authority, durable state, repository truth, or evidence.

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:

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.

The broader Micrantha pattern is to pull assumptions out of the workflow and give them explicit owners.

Invokrum does that for context. Effective context can be composed, identified, and reproduced rather than being whatever happened to accumulate in a session.

Dubnium separates run state from memory. The Workflow Runtime and scheduler own structured execution state needed for resume, retry, and recovery. The Memory System handles durable context and learning: classification, summarization, scoped retrieval, lifecycle metadata, and policy-aware access.

Its Memory Steward adds an agentic curation layer. It can identify and rank memory candidates, detect conflicts and staleness, and recommend summarization, promotion, rejection, supersession, or archival. Those recommendations remain advisory: governance decides whether a candidate may be accessed or promoted, and canonical project truth still belongs in versioned artifacts.

Keylix and Anthesis do it for authority. Keylix establishes principal identity, delegation, and proof; Anthesis evaluates policy and approval. A workflow reaching an “approved” step is not itself authorization to perform an effect.

Repora does it for repository truth. Repository identity, topology, observed state, desired state, and controlled mutation come from an explicit model rather than whichever checkout an agent happens to occupy.

Sandcastle, Testule, and the capability boundary do it for execution and verification. Mutable work carries lineage, verification produces attributable evidence, and effect admission remains a separate decision.

The same distinction applies to learning: persistence is not promotion. A lesson captured from a run can become candidate guidance without silently becoming trusted project knowledge.

The recurring principle is:

context        != memory
identity       != authority
evidence       != permission
workflow intent != effect authority
persistence    != promotion

Micrantha goes further less by adding one bigger workflow than by making those boundaries independently representable and enforceable.

What Micrantha can borrow

The comparison is useful in the other direction too. BMAD and Spec Kit both have methodology-level ideas worth adopting without turning either methodology into the control substrate.

From BMAD

BMAD scales workflow depth with task size rather than forcing every change through heavyweight ceremony. Its project context is deliberately focused on things an agent cannot reliably rediscover. It also makes the worker/orchestrator split explicit: a bounded worker handles one unit, while a higher-level orchestrator decides what should happen next.

Those ideas fit Micrantha well:

proportional ceremony
      +
small, high-value context
      +
bounded worker
      +
external orchestration

BMAD’s Test Engineering Architect work is another useful layer. 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.

From Spec Kit

Spec Kit makes convergence after implementation explicit rather than assuming that implementation means completion. Its converge workflow classifies gaps between intent and implementation as missing, partial, contradicts, or unrequested, then keeps remediation traceable back to the specification.

That vocabulary is useful because it describes the relationship between intent and implementation without collapsing into severity, priority, root cause, or authorization.

Micrantha can borrow that convergence discipline while keeping the boundaries separate:

stated intent
      ↓
implemented state
      ↓
classified gap
      ↓
traceable remediation candidate
      ↓
verification + policy + authorized effect

The common lesson is that methodology should improve how work is shaped, reviewed, and converged. It should not have to become the identity provider, memory system, policy engine, repository source of truth, or effect boundary in order to do that.

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.

Replaceable methodology, governed substrate

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.