The run loop is swappable. Which engine you pick is a question about where the loop runs, not a feature checklist.

Six engines ship today, in two kinds. A native engine runs the agent loop in your process, so it reuses the full Night Owls governance plane verbatim. An adapter fronts a loop that runs on a remote product you don't own — which is genuinely useful, but means the pre-generation veto, the tool gate, and cost caps cannot reach inside it. That is not a maturity gap to be closed; it is where the loop physically executes. This guide is how to choose, and where durability actually comes from.

Governance in Night Owls is enforced around the generation call — a cost cap checked before the next step, a fail-closed tool gate that can refuse a call, a pre-generation veto, secret injection scoped to the run. All of that only works if the loop is in your process, where the framework sits between the model and the tools. A native engine is exactly that: the loop runs in-process, so the governance plane wraps it unchanged. An adapter hands the loop to a remote runtime (an A2A endpoint, a deployed Trigger chat.agent Session, a Vercel Eve session); the framework can relay a request and observe results, but it cannot step between the remote model and the remote tools. Reduced governance on an adapter is structural, not a second-class implementation.

This is the same descriptor data the home page and the Studio UI read, rendered here so you can choose from one table. Every engine publishes an honest capability descriptor; the UI gates on it, so a surface an adapter can't support is disabled rather than silently degraded.

All six are on npm now. Native means the loop executes in your process with the full Night Owls governance plane. Adapter means the loop fronts a remote runtime with reduced governance and coarser events; each descriptor states exactly what it cannot enforce.

Answer two questions in order — do I need the full governance plane? and does the loop already run somewhere else? — and the engine falls out.

import { defineSwarm } from "@nightowlsdev/core";

// 1) The default. Omit `engine` entirely and you get the built-in Mastra engine, byte-identical —
//    full delegation, workflows, the whole governance plane, tier-3 events, durable resume.
const swarm = defineSwarm({ /* … model, agents, tools … */ });

// 2) A different NATIVE loop, same full governance in-process. You still own the loop, so cost caps,
//    the fail-closed tool gate, the pre-generation veto, and secrets all still apply.
import { aiSdkEngine } from "@nightowlsdev/engine-ai-sdk";
const onAiSdk = defineSwarm({ engine: aiSdkEngine({ /* … */ }), /* … */ });

// 3) An ADAPTER — you are fronting a loop that runs on a remote product. The descriptor says, in code,
//    exactly what governance it cannot enforce, and the Studio UI gates on that descriptor.
import { a2aEngine } from "@nightowlsdev/engine-a2a";
const overRemote = defineSwarm({ engine: a2aEngine({ endpoint: "https://…/a2a" }), /* … */ });

The most common confusion in the matrix is reading the durable resume column as an engine ranking. It isn't. "Can this run park on a human for days and survive the process dying?" is answered by the runner, not the engine. The interactive runner streams the loop to the browser and dies with the request; the background runner (@nightowlsdev/runner-background) parks a run with zero compute and resumes it later — and crucially, it parks a native engine, so you keep the entire governance plane while durable.

// "I want a run that can park on a human for days and survive a restart" is a DIFFERENT question
// from "which engine". Durability is not an engine feature — it is a RUNNER. The first-class,
// fully-governed durable path is a NATIVE engine bundled into @nightowlsdev/runner-background:
import { createBackgroundRunner, createTriggerBackend } from "@nightowlsdev/runner-background";
import { SwarmEngine } from "@nightowlsdev/core"; // the native Mastra engine

const runner = createBackgroundRunner({
  engine: new SwarmEngine({ /* … */ }), // ← native ⇒ FULL governance, even while durable
  storage,                               // cross-process Postgres snapshot to resume from
  backend: createTriggerBackend(swarmRun), // Trigger v4 durable tasks + wait tokens (GA)
});

// This is the answer to "I need Trigger durability." It is NOT @nightowlsdev/engine-trigger-chat.
// engine-trigger-chat is an ADAPTER that fronts a deployed Trigger chat.agent Session (reduced
// governance, the loop runs on Trigger). runner-background parks a NATIVE loop on Trigger's durable
// PRIMITIVES (tasks + wait tokens) — you keep the whole governance plane AND get durability.