Product / How it works
The directive-to-execution pipeline.
The mechanism, in technical depth. No adjectives — this is what runs when a sentence arrives.
-
Sanitize
The raw directive — a Slack message, a voice note transcript, a one-liner — is cleaned and normalized. Noise, quoted replies, and formatting artifacts 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 sub-50ms, so triage gets faster the longer a team uses Conductor.
-
Synthesize
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. 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 judgment, not a generic one.
The typed execution graph
The product's 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: the loop is the moat thesis.
Decision memory
A record of why, not just what.
Every workspace gets its own memory store — pgvector with HNSW indexing, retrieval in under 50ms. 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, not 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 is measuring.
Guardrails
What auto-executes, and what always waits for a human.
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 organization via Gmail.
- Anything that spends or commits money.
- 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 — is logged to the audit trail. Judgment-shaped guardrails, not a single prompt hoping for the best.
Integrations
Tool-native execution, not copy-paste.
Conductor doesn't paste a summary into Linear. It creates the actual Linear 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 blind — a human approves every message that leaves the organization.
MCP-native
Built on the protocol, in plain terms.
MCP is a standard protocol that lets AI systems call tools. Conductor is built on it natively, which means two practical things.
First, adding a new tool is a protocol connection, not a custom integration — the execution plane doesn't care which system of record sits behind it. Second, other agents can call Conductor as their execution plane, with guardrails and audit trail intact.
That second point is the longer-horizon bet: if the agent ecosystem needs a trusted, governed execution plane between intent and action, Conductor is positioned to be it. Stated as a bet, not a claim, until there's usage evidence.
Want the technical diligence version of this?
Pipeline internals, memory schema, policy engine — ask directly.