BMAD and Micrantha: Workflow Discipline on a Governed Substrate

I have been aware of BMAD Method and GitHub Spec Kit for some time. I recently went back and reviewed them against the agentic software-delivery architecture I have been building across Micrantha.

They line up surprisingly well even though Micrantha was not designed around either one.

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

That maps closely to how I think about 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 main 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.

Why BMAD fits

None of this was designed around BMAD, but the fit is not magic and it was not injected later by AI. The component boundaries were already there.

Micrantha’s agentic work started with a practical question: if an AI can take actions, how are those actions governed? That pushed identity, authority, approval, evidence, attribution, bypass resistance, and the exact requested effect into the architecture early. Anthesis came from that problem; it is a control surface for governed agentic effects, not an agent framework.

Micrantha was also designed around Unix-style composability. Its CLI interoperability standard favors narrow interfaces, structured machine output, useful exit semantics, explicit mutation boundaries, and contracts that work for people, scripts, and supervisors.

That matters here. The tools are meant to work together without becoming one monolith, and to remain replaceable where their contracts allow it.

The rest of the split followed from specific needs. Invokrum owns effective context. Keylix handles identity, delegation, and proof. Dubnium owns runtime supervision, execution state, and memory. Repora models repository truth. Sandcastle handles mutable workspace state and lineage. Testule represents portable verification requirements and evidence.

I had known about BMAD while Micrantha was evolving, but it was not the template for these boundaries. Revisiting BMAD against the current architecture made the fit much easier to see. There is no BMAD-specific compatibility layer hiding in Micrantha; BMAD can fit because the existing interfaces give a workflow somewhere sensible to plug in without also making it the identity provider, policy engine, memory system, repository authority, or effect boundary.

That does not prove the architecture is right. It does show that an independently designed workflow can use the boundaries without those boundaries being rewritten around it.

Spec Kit fits too

I revisited Spec Kit in the same pass. It organizes delivery differently: BMAD leans toward roles, workflows, bounded stories, and specialized agents; Spec Kit toward specifications, plans, tasks, analysis, and convergence.

Both still fit above the same Micrantha boundaries. That is the useful part: software-development methodology can remain replaceable context above the control substrate instead of being baked into identity, authority, durable state, repository truth, or evidence.

Micrantha has a native methodology stack too

Micrantha still has a smaller native design discipline: 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 in AI because a prompt format can become a protocol, a tool declaration an execution model, or an agent role an authority boundary before the decision has really been named.

I want those distinctions to stay visible:

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

Code shows what survived. RFCs, QART analysis, and ADRs preserve why.

RFCs, QARTs, ADRs, BMAD, and Spec Kit can all contribute intent. Invokrum still determines the effective context, and none of those artifacts can grant themselves execution authority.

Where Micrantha goes further

Some of BMAD’s current design discussions touch problems Micrantha also cares about: attributable resumed and parallel runs, explicit repository targeting, visible and approval-aware persistent customization, and reliable memory persistence.

These become harder once an agent moves from suggesting work to performing it.

Micrantha’s approach is to keep several boundaries separate. Dubnium’s Workflow Runtime owns resumable execution state; its Memory System owns durable context and learning. Keylix establishes identity and delegation while Anthesis decides whether an effect is authorized. Repora models repository identity, topology, observed state, desired state, and controlled mutation instead of trusting the checkout an agent happens to occupy. Sandcastle keeps mutable workspace state and lineage explicit, and Testule keeps verification evidence separate from authority.

The distinctions are deliberate:

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

Micrantha is not trying to solve those problems by making one larger workflow. It gives them separate owners and contracts.

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 a clean division of responsibility.

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 also deciding severity, priority, root cause, or authorization. Micrantha can borrow that convergence discipline while keeping those decisions elsewhere.

BMAD as a workload

The experiment I want to try is running BMAD through Micrantha rather than replacing Micrantha with it.

In that arrangement BMAD supplies methodology and development context. It does not need to own identity, authorization, repository control, runtime state, or verification.

Replaceable methodology, governed substrate

BMAD starts with software-development workflow. Micrantha’s agentic work started with a different question: how do I govern what an AI is allowed to do?

That difference explains much of the architecture. Micrantha keeps context, identity, authority, state, repository truth, execution, and evidence behind separate, interoperable contracts. BMAD or Spec Kit can provide methodology without becoming the control plane.

That is the result I care about: the workflow can change without requiring the governance and execution boundaries to change with it.