Spec-driven development · Outcome ops
The living spec your team builds from.
Turn outcomes and features into living specs — the shared contract for what you're building and what “done” means. Product sets the intent, engineering builds against it, and AI agents keep the spec and reality in sync, proposing the updates you approve. The source of truth your work runs on — not another status dashboard.
Spec-driven · Bring your own agent · You approve every change
The problem
Your spec and your build drift apart.
You write the spec — the PRD, the acceptance criteria, the definition of done. Engineering builds. Then reality moves: a metric misses, scope shifts, an edge case shows up — and the spec quietly stops matching what's actually true.
So “is it done?” becomes a debate, “is it working?” becomes a guess, and nobody owns keeping intent, delivery, and reality in sync.
Lamdis closes the gap. The spec is living: agents reconcile the real signals against what you intended and bring you evidence-backed updates; you approve. Product, engineering, and operations finally read from the same honest source.
One spec, three teams
Where product, engineering, and operations finally agree.
Product says what good looks like. Engineering builds it and throws off the signals. Operations has to know if it's actually working. Today that's three tools and three meetings to stitch together — Lamdis makes it one living spec, and agents do the stitching.
Product
BringsWrites the spec — the intent and the acceptance criteria.
GetsA spec that never goes stale, and proof it’s landing.
Engineering
BringsBuilds against it; ships the releases, metrics, and tickets.
GetsThe build reports itself — credit without the write-up.
Operations
BringsOwns the question: is the outcome actually being met?
GetsA live, evidence-backed answer with an audit trail.
How it works
From spec to reconciled — on a loop.
Write the spec
Capture an outcome or feature: what you’re building, the acceptance criteria, what “done” means.
Build against it
Your team and agents work toward the spec; agents pull the real signals — releases, metrics, tickets — and check them against it.
Agents propose, you approve
When reality diverges from the spec, agents file a proposal: an updated verdict, a missing criterion, fresh evidence. You decide what’s true.
The spec stays true
Approved changes update the living spec and log the decision. The contract everyone builds from reflects reality.
See it work
Ask your agent. Approve the truth.
Claude reads the living spec over MCP, checks the real metrics against the goal, and files a proposal — then you approve it in Lamdis and the spec reconciles itself. Same loop with any MCP agent.
The review queue
Agents propose. You approve.
Nothing material changes without you. Each agent suggestion — a verdict change, a new acceptance criterion, an evidence note, even reshaping your product catalog — lands here as a proposal. Approve and it applies to the living spec and logs a decision; reject and nothing moves.
Living specs
The spec, next to reality.
Open any spec and you see the whole story: what you set out to build, how you'll know it's done, where the numbers actually are, and the current call — with the evidence, the proposed updates, and the owners across product and engineering.
Acceptance criteria
Verdicts per criterion, kept current.
Metrics & health
Baseline, current, target — at a glance.
Evidence trail
Every observation an agent attached.
Decision log
What changed, when, and why.
Bring your own agent
Connect your agent in one command.
Lamdis ships a Model Context Protocol server, so the coding agent you already use — Claude, Codex, Cursor, or any MCP client — can read your outcomes, gather evidence, and file proposals, governed entirely by the scopes on the key you hand it.
It's already wired
Start writes the connector for you. Or run it anytime:
# wire your agent — one command (lamdis start already ran it)
$ npx lamdis connect
Lamdis · connect
✓ scoped key minted · MCP config written
→ restart your agent, then ask: “review my outcomes and propose updates”
Works with Claude Code, Codex, Cursor, Windsurf — any MCP client. Propose-only by default; grant approval scope only if you want the agent to act on its own.
What the agent can do
Each tool is gated by the key's scopes:
Self-host
Yours to run. One command.
Lamdis is built to self-host. With Docker and Node installed, you're one command from a running instance — database, auth, and your agent connected. No clone, no build.
# from anywhere — pulls prebuilt images, no clone needed
$ npx lamdis start
Lamdis · start
✓ ports picked · database up · secrets generated
✓ agent connector wired
→ ready at http://localhost:4470 — open it and create your workspace
One command, no clone
npx lamdis start picks free ports, generates secrets, pulls the images, and wires your agent. Open the link and go.
Your data stays yours
Runs on your machine in Docker — your own Postgres, your own secrets. Nothing leaves unless you send it.
Many workspaces
Run your product and your side project side by side, and switch between them in a click.
Don't want to run it yourself? Lamdis Cloud — we host it, you get the same product managed. hello@lamdis.ai →
Build from a spec that stays true.
Self-host it in a minute, or book a walkthrough and we'll run the loop on your own specs — product, engineering, and operations on one source of truth.
Or say hello — hello@lamdis.ai