Monarch
Five planes. One accountable system.
Monarch separates the concerns that agent frameworks usually blur together: the workspace people use, the control plane that schedules, the agents that plan, the specialists that execute, and the boundary that approves. Each plane does one thing, owns its state, and talks to the others through durable records — never through back channels.
Chat, activity & approvals, connections, knowledge — served over same-origin APIs with server-side sessions.
Deterministically claims jobs, launches workers, keeps a warm pool, and reconciles runtime state.
Turns root jobs into durable plans and child tasks, then monitors progress and reviews completion.
Execute scoped work with typed tools, write durable outputs, and propose consequential actions.
Reviews every proposed action, applies policy or human sign-off, executes through governed connectors, records results.
No plane imports another's internals. State records, identity, and HTTP contracts are the only boundaries — which is why each plane can evolve, scale, and fail independently.
Separation of powers, applied to AI
The failure mode of agentic systems is concentration: one loop that plans, executes, and acts with nothing in between. Monarch distributes those powers deliberately.
Reasoning never schedules
The Orchestrator is forbidden from LLM reasoning by design. Claiming, launching, retrying, and reconciling are deterministic — so throughput and recovery behavior are predictable under load.
Planners never execute
Master creates plans and child tasks and reviews outcomes, but performs no consequential external actions itself. Supervision stays honest because the supervisor has no hands.
Executors never approve
Task workers propose actions as execution requests. Only Gatekeeper can approve, block, route, or execute them — one boundary, one policy surface, one audit stream.
The life of a job
Every pipeline run is a durable state machine, not a long-lived prompt. Here's what actually happens.
A job is born
A chat request, a schedule, or an inbound event creates a root job — recorded with tenant scope, priority, idempotency keys, and typed input. Duplicate triggers can't create duplicate work.
The Orchestrator claims it
Deterministic sweeps plus realtime wake-ups mean pending work is picked up in seconds without hot loops. Workers launch on serverless runtime, and a warm pool keeps first-token latency low.
Master plans
The supervising agent drafts a structured plan — drawing on a curated library of reusable task definitions with acceptance criteria, risk levels, and parallelism hints — and spawns child tasks. Plans persist with status and concurrence, not in anyone's context window.
Tasks execute
Bounded specialists gather context, search the web, read and write approved working files, and use typed tools that wrap deterministic services. Progress streams into an append-only event log you can watch live.
Gatekeeper clears actions
Anything consequential — an email, a CRM write, a purchase — becomes an execution request carrying provider, payload, context, and risk level. Policy auto-approves the routine; humans sign off on the rest; approved actions run through governed connectors and record their results.
Everything reconciles
Heartbeats detect stalled runs, stale claims recover automatically, and completion is reviewed — not assumed. When the job closes, its plan, events, actions, outputs, and costs remain queryable forever.
The same event stream that powers live progress in the workspace is the record you audit later — one source of truth, two uses.
Durable state as the source of truth
Monarch's rule is simple: nothing important lives in process memory or local files. The entire platform reads and writes one governed, organization-scoped data model.
The jobs graph
Jobs, runs, plans, and events form a complete execution graph — every attempt linked to its initiating user, every state change timestamped, elapsed time measured.
The knowledge system
Documents, search groups, memberships, and embedding references — retrieval configuration (chunking, models, reranking) is data you govern, not code you redeploy.
Connections & policy
Tool connections and per-action settings — approval mode, risk level, allowed roles — live as records, so governance changes take effect instantly across every pipeline.
Triggers & events
Webhook subscriptions and received events with idempotent receipt, deterministic correlation to your records, and dispatch state — so the outside world can start pipelines safely.
The usage ledger
Token counts and costs roll up into per-organization usage events and invoice snapshots — cost observability is built into the data model, not bolted on.
Notifications that bind
Targeted or organization-wide notices with read receipts and required acknowledgement — the compliance-grade messaging layer most platforms forget.
Typed agents, typed tools, no loose prompts
In Monarch, an agent is a typed runtime decision-maker with a stable identity — not a prompt pasted into a service file. That discipline is what makes the platform extensible without becoming fragile.
- Declarative agent definitions. Stable IDs, roles, system prompts, allowed tools, and strict output schemas — downstream services never have to guess what a model meant.
- Tools wrap deterministic services. Every capability an agent can invoke is a typed wrapper over tested service code, grouped by ownership domain.
- Per-organization model selection. Model choices resolve through organization settings, not hardcoded constants — swap models without touching workflow code.
- A reusable task library. Proven task definitions with input requirements, acceptance criteria, and risk levels — plans assemble from vetted parts.
Opinionated where it counts
Component boundaries, configuration purity, forward-only migrations, and file ownership conventions are written down — and enforced by an automated validation suite that runs across the repository. Architecture drift fails fast, before it reaches production.
Observable end to end
System traces, metrics, and logs flow through open telemetry standards; LLM traces, evals, and token accounting are captured per run. When something surprises you, the evidence is already collected.
See how it's governed.
The architecture is half the story — the security and approval model is the other half.