The directive-to-execution pipeline.
The mechanism, in technical depth. No adjectives — this is what runs when a sentence arrives, what it is allowed to touch, and what it will never do without you.
Decision execution infrastructure is the layer between a decision being made and the work it causes being tracked, owned, and done — with a policy check in front of every action and one record of who approved it, across every tool it touches.
What Conductor will never do without you.
For a buyer being asked to grant write access across four tools, this is the part that matters first.
Hard stops
- Send an external email. Ever. Drafts only. The Gmail scope Conductor holds cannot send.
- Commit spend, sign anything, or accept terms.
- Delete or otherwise take an action it can’t reverse.
- Touch anything your workspace has flagged as sensitive.
Everything else
Executes on approval — and every one of those decisions is logged with the policy that allowed it, the person who approved it, and the directive that caused it.
These aren’t conventions or prompt instructions. The guardrail stage is a pipeline stage that runs before execution, so there is no path to a tool that skips it. The policy model and OAuth scopes are published →
What’s live, and what isn’t.
Naming two things as not started is what makes the five LIVE labels worth reading.
Six stages. Nothing skips one.
-
Sanitise
The raw directive — a Slack message, a voice note transcript, a one-liner — is cleaned and normalised. Noise, quoted replies and formatting artefacts are stripped before anything interprets it.
-
Triage
The directive is classified against this workspace’s history: what’s being asked, which lane each part belongs in, who usually owns this kind of work. Decision memory is queried here — retrieval is under 50ms, so triage gets faster the longer a team uses Conductor.
-
Synthesise
The directive is decomposed into a typed execution graph: discrete actions with types, owners, dependencies and target systems. “Tell marketing, get the number from finance, draft the plan” becomes three linked, ordered actions — not a paragraph.
-
Guardrail
Every action passes a policy check before it can touch a tool. What can auto-execute, what needs approval, who’s allowed to approve it, and what needs a second signature. Nothing reaches an external system on hope.
-
Execute
Approved actions run directly in the tools: the Linear ticket is created with an assignee and due date, the Slack message is sent, the Notion page is written, the Gmail draft waits for its human. The work exists in the system of record.
-
Learn
Every approved, edited or rejected card is written back to decision memory with its rationale. That’s the compounding part: the system learns this team’s judgement, not a generic one.
The mechanism, drawn literally.
Hover or focus any node to trace its downstream path. Dependency ordering isn’t a metaphor here — it’s the data structure.
Defer cards park with a revisit date — deliberately no outgoing edge. Decision memory feeds the next triage: that loop is the moat thesis, stated as a thesis.
The product keeps its own score.
Every generated action is logged as approved, edited or rejected, and the rate is visible to your workspace.
If Conductor is guessing badly you’ll see it before we do — and if the rate climbs as your decision history fills, that’s the whole thesis, measured on your own data rather than asserted on this page.
Pricing
Design partners: free for eight weeks, and we set the price together at the end of it.
After that, per-seat for the people who approve — not for everyone the work lands on.
A record of why, not just what.
Every workspace gets its own memory store — pgvector with HNSW indexing, retrieval under 50ms at current volume. Every approved, edited or rejected card is written to it with its rationale: who decided, what happened, what got escalated versus auto-executed.
Two visible consequences. Triage gets more accurate over time, because routing and ownership suggestions come from this team’s history rather than a generic model. And the Morning Briefing can say not just what’s open but why the original decision was made — because the rationale was stored at the moment of execution.
This is the compounding asset the moat thesis rests on. It doesn’t transfer if a team switches tools, and it gets more valuable the longer a team stays. Whether that compounds into real retention is exactly what the design-partner phase measures.
What auto-executes, and what always waits.
Can auto-execute after approval
- Linear tickets inside your workspace — assignee, due date, dependency links.
- Slack messages to your own team’s channels and members.
- Notion pages and trackers inside your workspace.
- Internal follow-ups, reminders and revisit scheduling.
Always needs a human
- External email — anything leaving the organisation.
- Anything that spends or commits money. Above a threshold you set, a second approver.
- Anything irreversible or destructive.
- Anything the workspace’s own policy flags as sensitive.
Escalation rules are set per workspace, and every action — executed or blocked — writes one audit row. Judgement-shaped policy, not a single prompt hoping for the best.
Tool-native execution, not copy-paste.
Conductor doesn’t paste a summary into Linear. It creates the actual ticket — with assignee, due date and dependency links — that your team then works.
Linear + Slack
The core wedge. Tickets created with owners, deadlines and dependency structure. Messages sent into the right channel with the decision’s rationale attached. The Morning Briefing lands here — a 90-second summary of what happened, what’s open, and why.
Notion + Gmail
Pages and trackers created from the team’s own templates, linked back to the directive that caused them. External email is drafted, never sent — a human approves every message that leaves the organisation, and the Gmail scope Conductor holds physically cannot send.
MCP-native, in plain terms. MCP is a standard protocol that lets AI systems call tools. Adding a new tool is a protocol connection, not a custom integration — and other agents can call Conductor as their execution plane, with policy and audit trail intact.
That second point is the longer-horizon bet. It’s also honest to say the protocol cuts both ways: the openness that makes Conductor easy to adopt makes it easy to replace. The position is the claim, not the protocol.
Want the technical diligence version of this?
Pipeline internals, memory schema, policy engine. Ask directly.