Org rollups & dependency detection — “ENSEMBLE”
Org-wide rollup briefings, approval policies and cross-team dependency detection. The upmarket move into Ops and PMO, once decision-memory volume is real.
The spec is the pitch.
An ops lead evaluating write access to Gmail and Slack shouldn’t have to book a call to find out what Conductor can touch. The policy model, the audit record and the OAuth scopes are published below, along with what’s built, what’s planned, and in what order.
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.
A policy is a rule your workspace writes, not a prompt we tune.
“Guardrails” is a word every AI product uses. Here is what one actually looks like in Conductor. Policies are evaluated in the guardrail stage, which runs before execution — there is no code path to a tool that skips it.
A policy matches on the typed action, states what it requires, and states what it writes to the record. Nothing is inferred at runtime by a model, and nothing about a policy is a suggestion.
# external communication never fires on its own policy: external_communication matches: action.type in [gmail.send, slack.dm_external] requires: human_approval logs: actor, policy_id, decision, timestamp, directive_id # money gets a second signature above a threshold you set policy: spend_commitment matches: action.amount > 0 requires: human_approval, second_approver if amount > 5000 logs: actor, policy_id, amount, decision, timestamp, directive_id
Every action, approved or rejected, writes one row.
This is the record that spans all four tools, and it’s the thing no single vendor’s agent can produce — because producing it means being neutral about the tool the action happened in.
- directive_id
- source slack | voice | email
- action_type
- target_tool
- owner
- policy_id
- outcome auto | approved | edited | rejected
- approver
- rationale
- timestamp
The outcome field is also the scoreboard: approval rate is computed from it, per workspace, and it’s the number the eight-week design-partner phase exists to move.
What Conductor can touch.
Linear
Read + write
Issues, projects, comments. No admin, no billing.
Slack
Scoped
Reads channels it’s invited to, posts as the app. No DM history, no user-token impersonation.
Notion
Read + write
Pages in shared databases. No workspace admin.
Gmail
Compose only
Drafts only. Conductor cannot send.
Data handling. Workspace data is not used to train models. Decision embeddings are stored per workspace and are never queried across tenants.
Two answers owed before the first design-partner call
Retention period and deletion SLA are not yet stated here. They are the first two questions a 100-person company’s security review opens with, and publishing a number before it’s committed to would be worse than publishing nothing. Ask and you’ll get the current answer directly.
The pipeline that exists today.
Sanitise → triage → synthesise → guardrail → execute → learn. Unstructured intent in; typed, dependency-ordered, tool-executed actions out.
Per-workspace decision memory on pgvector with HNSW indexing. MCP-native protocol interface. Live execution in Linear, Slack, Notion and Gmail. The full mechanism is on the Product page →
Performance. Retrieval stays under 50ms at 10,000 stored decisions, so memory lookup adds no latency a user notices during triage.
Model cost runs around $0.0004 per directive. Noted for completeness; it isn’t a moat and it isn’t why anyone buys.
Seven modules on the roadmap. Four are far enough along to name.
Internal codenames included because they’ll come up in diligence — with a plain-English name and an honest status on each.
Built — core, expanding
Decision memory — internally “VAULT”
The per-workspace store of every card, outcome and rationale. Live today in the core pipeline; the expansion adds retention analytics and cross-decision pattern detection.
Planned
Planned
Pre-execution simulation — “SIMULACRA”
A dry run of a directive’s full execution plan before anything is sent — what will be created, who gets notified, in what order.
Planned
Proactive surfacing — “PRECOG”
Flags decisions that appear to be stalling — no owner confirmed, deadline slipping — before anyone has to ask.
Three further modules are in planning and deliberately unnamed here. Codenames for unbuilt software read as vaporware in diligence; these four get named because they’re sequenced and scoped.
Eight weeks first. Everything else is gated on the result.
-
Weeks 1–8 — Prove the loop
Ship the core loop into five design partners matching the ICP. Instrument approval rate and decision-memory usage, not directives processed. Exit: a one-page proof showing approval rate over time. If the curve is flat, the memory thesis is wrong. This is what the $50,000 funds.
-
Weeks 9–16 — Harden trust
Approval policies, deeper guardrail configuration, and the decision-memory expansion (VAULT). Gated on the week-eight result, and on a seed round sized to it.
-
Weeks 17–28 — Move upmarket
Org-wide rollup briefings and cross-team dependency detection (ENSEMBLE), gated on real decision-memory volume.
-
Weeks 29–40 — Anticipate
Pre-execution simulation (SIMULACRA) and proactive surfacing (PRECOG). SOC 2 and SSO are seed-stage work and sit in this window, not before it.
$50,000, and what it is not for.
$30,000
One contract engineer, eight weeks
Integration reliability and the approval-rate instrumentation. The number the whole raise is buying has to be trustworthy before it’s useful.
$12,000
Design-partner programme
Five workspaces, hands-on onboarding, weekly interviews. Free for the eight weeks; price set together afterwards.
$8,000
Infrastructure and review
Hosting, decision-memory stores, model spend, and the security review a 100-person company asks for on the first call.
Not funded by this raise: SOC 2, self-serve billing, multi-provider routing, and paid acquisition. Those are seed-round line items and they are out of scope until the curve exists.
What’s de-risked on the technical side.
Already true
- End-to-end execution in four tools: Linear, Slack, Notion, Gmail.
- Decision memory live, retrieval under 50ms at current volume.
- Guardrail stage in front of every execution path — not beside it.
- MCP-native interface: new tools are protocol connections.
Still to prove
- Decision-memory retention compounding — the moat thesis, measured in weeks 1–8.
- Seat-by-seat expansion inside a real organisation.
- Reliability at design-partner scale, not founder-demo scale.
- Enterprise requirements (SOC 2, SSO) — on the roadmap, not in hand.
Technical diligence welcome.
Schema, policy engine, protocol layer — ask for the internals.