i.Context
Agents that know what you're building
Every agent reads from one shared model: the research, the specs, the codebase, the production signals. No re-briefing. No context loss between stages. The work compounds instead of resetting.
§00The whole
Marshalling every phase of AI-augmented software development.
Intent, planning, code, verification, execution, and audit, under one governed runtime. Speeding up a single phase doesn't make the system faster; marshalling the whole does. No context leakage between handoffs. No coordination tax between tools. Engineers ship with leverage. Leaders ship with proof.
01The three Cs
Three reasons the governed runtime makes agent output dramatically better.
ii.Control
Guardrails your team defines
Set the guardrails once — the conventions to follow, the tests every change must pass, the budget a run can spend — and every build runs inside them. You steer. Agents execute.
iii.Coverage
One workspace, end to end
Research, design, build, tracking, operations — five modes, one data model, one audit trail. The work flows through; nothing gets dropped at the seams.
02The handoffs are the bug
Most software lifecycles aren't lifecycles. They're relay races with dropped batons.
The pain
The research doc never makes it into the Figma frame. The Figma frame never quite matches the spec. The spec drifts from the implementation. The production alert can't be traced back to the design decision that caused it.
Every handoff is a place where context evaporates, intent gets re-interpreted, and the why gets lost.
Now multiply that by every agent your team adds. Each one starts cold, asks for the same context again, and produces work the next stage has to re-translate.
The fix
Majordomo replaces the handoffs with one continuous flow. A research insight in Library becomes a brief in Studio. A Studio spec drives a Factory pipeline. A signal in Pulse links back to the brief that started it.
Same data model. Same audit trail. Same context, all the way through.
Agents don't restart at every stage. Neither does your team.
The handoffs are the bug. Majordomo is the fix.
03Across every phase
From the first research question to production signals — one governed runtime.
Library, Studio, Factory, Tasks, and Pulse cover every phase from intent to audit — five modes most teams stitch together from five (or seven) separate tools, with team channels running alongside them. Each shares one data model with the next, so work moves forward instead of starting over, and every step stays traceable.
i.
Research
librarySources, briefs, evidence
ii.
Design
studioSpecs, roadmap, OKRs
iii.
Build
factoryRuns, sandboxes, provenance
iv.
Track
tasksThe work in flight
v.
Operate
pulseSignals, feedback, audit
Every artifact traceable to every other.
04Inside the modes
A closer look at each stage — same data, five perspectives.
Below: what each mode does, what it produces, and how it hands off to the next inside the same governed runtime — no translation, no re-briefing, no losing the why.
library
Understand the problem before you solve it.
Bring your sources into one place — docs, notes, prior research. Library indexes them, surfaces the connections as a searchable, fully-cited graph, and keeps that context in the same workspace as the specs and roadmap it informs — so nothing has to be re-explained.
- 01Knowledge graphIndex your sources and explore them as a connected, searchable graph — every entity and connection traceable to the document it came from.
- 02Cited by defaultNothing is asserted without a source. Every node in the graph links back to the exact place it was found.
- 03Semantic searchSearch everything you've captured by meaning, entities, and symbols — not just keywords.
- 04One workspace with StudioYour research lives in the same workspace as the specs and roadmap it informs. No separate tool, no re-keying.
studio
From brief to buildable.
Studio is where intent gets specific, in two halves: Product — roadmap, story maps, and OKRs — and Feature — a searchable spec editor and visual design. It shares one workspace with Library and Factory — no re-creation, no translation. The output is a spec Factory can build from and a roadmap your team can ship against.
- 01Roadmap & story mapsVisual sequencing across roadmap and story maps. Designs and timing live together so the what and the when never drift apart.
- 02Objectives & key resultsSet OKRs beside the roadmap they drive, so strategy and delivery share one surface.
- 03Feature editorSearch any recorded feature and edit its spec in place — what it does, who it's for, how you'll know it worked. Factory reads the same spec.
- 04Visual designDescribe what you want in natural language and generate real, device-aware screens — with variants side by side on an infinite canvas.
factory
Agents build. Legacy or greenfield.
Factory turns a Studio spec, written requirements, or an existing codebase into a reviewed pull request. It runs the coding agent inside a clone of your repo, verifies against tests, and retries intelligently when a gate fails — same source of truth, no re-interpretation, every run recorded and inspectable.
- 01Runs you can watchWatch each build run live — every step, decision, and gate as it happens, with the full transcript to inspect. No black box.
- 02Codebase-awareWorks inside a clone of your repo — reading its structure and conventions — so changes fit your codebase instead of fighting it.
- 03Run historyEvery run recorded and inspectable — attempts, gates, diffs, and transcript. Come back to any run and see exactly what happened and why.
- 04Guardrails, enforcedNo build reaches a pull request without passing its tests, inside a bounded retry-and-token budget — and a reward-guard holds suspicious green runs for human review.
tasks
The work in flight, linked to why.
Tasks is the ledger between a spec and a shipped change. Each one carries a public id, an owner, and a line back to the feature it delivers — so a question about any piece of work has an answer, not an archaeology project.
- 01Work with an identityEvery task carries a short public id you can say out loud and paste anywhere — not a uuid.
- 02Linked to the specA task points at the feature it delivers, so the requirement, the work, and the run that built it stay connected.
- 03Status, priority, ownerThe fields a team actually runs on, on one surface — assignees resolved from your workspace roster, not a free-text field.
- 04Where signals landTriage a signal in Pulse and it becomes a tracked task here, still linked to the evidence that prompted it.
pulse
Every voice. One signal. Closed loop.
The moment you ship, the feedback starts coming in. Pulse brings feedback, observations, AI-spend anomalies, and the access trail into one place — and turns the ones that matter into tracked work, so the next cycle starts from evidence instead of a blank page. The loop closes here.
- 01Feedback as signalsCapture feedback and observations in the same workspace as the work they're about — each one filed as a signal you can triage.
- 02Spend anomalies, caughtSpikes in AI spend surface automatically as signals — the one thing that really does watch itself.
- 03Spend & usage, liveA live dashboard of AI spend, model mix, and open signals across the workspace.
- 04The access trailA merged, filterable audit of who read and changed what, across both backends — exportable, with its own retention policy.
05Decision provenance
“Why is this in production?”Get the whole answer in one view.
Because every artifact in Majordomo lives under one data model, the links are already there — a shipped feature to the Factory run that produced it, the Studio spec it implemented, and the Pulse signal that prompted it. The trail exists by construction, not by reconstruction after the fact.
For your auditors, your board, and the engineer who joined last week.
Trace
A build passed a gate it never ran.
Shipped to main. Every subsequent run inherits the fence — and the signal that started it stays attached to the change that closed it.
Reward guard unioned in the hardened diff-path parser: git C-style-quoted headers were invisible to every PROTECTED rule, so one accented character in a filename bypassed the guard entirely.
The bug the guard was built to catch was hiding in the guard itself.
A run may only report pass over paths its recipe can actually verify. Paths outside gate coverage are fenced: the run stops and asks, rather than scoring itself green.
- Untestable paths fence the run instead of passing it
- PROTECTED rules cover toolchain and gate-config files
- Path parsing survives non-ASCII filenames
Polyglot runs are reporting pass on diffs the recipe has no gate for. A run that touches code it cannot verify is being scored as a success — the number is green and it means nothing.
Filed from run telemetry, not a bug report. Nobody had to notice it by hand.
Every hop is a real record, linked at write time — not a report assembled afterwards.
Three changes that really shipped in Majordomo’s own repository — pull request, commit, and diffstat are as merged.
§06For Enterprise
Built for the way enterprises actually ship.
Roll out Majordomo across your organization with the provenance, cost controls, and support your teams — and your auditors — need.
01
Decision provenance, end to end
Every artifact shares one data model, so the links between a shipped feature, the run that built it, the spec it implemented, and the signal that prompted it are there by construction.
02
Append-only history
Every change to every artifact is recorded — who, what, and when — in an append-only log that can't be silently rewritten. The audit trail is a property of the system, not a report you assemble later.
03
AI cost controls
Real-time spend visibility per workspace, and a hard token-and-time budget enforced on every build run. Stop AI costs from being a quarterly surprise.
04
Gated by default
No build reaches a pull request without passing its tests and clearing a review gate — and a reward-guard holds suspicious green runs for a second look.
05
Workspace-scoped access
Every workspace is isolated — only the people you invite see its research, specs, builds, and signals. SSO and role-based permissions are on the roadmap.
06
Dedicated support
Priority onboarding, custom integrations, and a direct line to the engineering team.