How Genesis Works

Genesis is a multi-agent software-delivery orchestrator. You describe an outcome in plain language; Genesis plans the work, breaks it into tasks, dispatches AI coding agents to do it, runs governance and review gates, tracks every dollar of model spend, and surfaces the whole pipeline to humans through a dashboard, a REST API, and a large catalog of MCP tools. It is multi-tenant: one deployment hosts many isolated customer tenants, each with its own projects, missions, agents, conversations, costs, and compliance posture.

This page is the map. It explains the big pieces and how they fit together, then points to a dedicated page for each subsystem. Every subsystem page is written from two angles: the operator / product surface (what it does and how you drive it — MCP tools, REST controllers, dashboard pages) and the internal architecture (the services, data model, and execution internals).

The shape of the system

Genesis is organized as a hierarchy of intent that narrows from strategy to execution:

• Tenant — the top-level isolation boundary (a customer). The control-plane database holds the tenant registry, environments, and all shared catalogs (LLM providers / presets / routing, system workflows, the compliance requirement/control catalog, constitutional rules, fleet profiles). Each tenant then has its own operational data (missions, tasks, agents, conversations, costs, reviews, knowledge) in a tenant database. Tenancy is implicit via the per-tenant database — there is no TenantId column (ADR-008).
• Project — a unit of work inside a tenant, typically bound to one or more Git repositories. Projects group missions, hold a registered file/module tree, carry a boundary policy, and are the scope for costs, knowledge, and fleet configuration.
• Charter → Matter → Mission → Task — the work hierarchy. A Charter is a strategic initiative (it carries a Vision and acceptance criteria). A Matter is a strategic epic under a Charter. A Mission is a concrete piece of deliverable work that gets decomposed into Tasks, the atomic units agents actually execute.
• Track — every mission and conversation runs in one of four tracks that frame the kind of work: Governance (policy), Research (strategy / investigation), Planning (command / decomposition), and Build (execution). (Older code persists this under a legacy field name; it always denotes the Track.)

The two cornerstones

Two subsystems are the heart of Genesis and have their own deep-dive guides.

• Agents — the autonomous workers. A native Strategic Orchestration Agent (and a standing Compliance agent) run on an event-sourced core (agent_instances + agent_event_queue) and are self-pacing: a background AgentDispatcher ticks every Active instance, the agent reads its event log, plans through one provenance-recorded LLM call, then takes typed, governed actions. Mission-type agents (Feature, Research, Review, onboarding, etc.) wrap that core to drive a specific mission to completion. Coding work is delegated to coders — containerized CLI tools (Claude, Copilot, Codex, Gemini, Aider, Octofriend) spawned per task. See the Agents guide for the full lifecycle, event model, budgets, and dispatch internals.
• Workflows — a reusable, versioned graph of typed steps (stored as GraphJson, with a Draft → Published lifecycle and a content checksum). Invoking a published workflow compiles the graph into a mission whose tasks carry the step wiring; gate steps become pending approval decisions that humans resolve, and the mission records workflowId@version + checksum as compliance provenance. Workflows can embed compliance controls from a versioned catalog (with per-run waivers). See the Workflows guide for the node/pin model, the compiler, gates, controls, triggers, and run internals.

The cross-cutting layers

Three layers run underneath everything above:

• Dialogue — strategic conversations with the model that can propose missions for human approval (the main on-ramp from idea to work).
• The LLM routing layer — every model call is attributed to a named call site (e.g. Missions:Decomposition, ReviewEngine:Architecture). A preset attached to that site resolves the provider, model, routing chain (with fallbacks), tool policy, sampling / limits, and prompt overlay at dispatch time. Modes apply a whole bundle of site attachments atomically. See LLM Configuration & Prompt Overlays.
• Costs & governance — every call writes a cost record (tokens, cache, batch pricing, estimated USD) attributed to its mission / task / project; budgets, quotas, constitutional rules, and compliance gates constrain what agents may do. See Costs & Budgets.

Subsystem guide