—Investor FAQ

The hard questions, answered directly.

Every claim below is labelled proven, not measured yet, or not proven. If a question isn’t answered here, ask it — hello@min15x.com. Diligence questions get same-day answers.

The raise

$50,000

A bridge priced to buy evidence, not runway. Eight weeks, five design partners, one curve.

The deliverable

One page, week eight

Approval rate over time across five real workspaces. If the curve is flat, the memory thesis is wrong and I’ll say so.

The buyer

Ops & eng leads

20–150 person companies running Linear/Jira + Slack. Per-seat for approvers, not for everyone.

01Questions

Thirteen questions, in the order they get asked.

What is decision execution infrastructure?

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.

Conductor is that layer. It takes an unstructured directive, decomposes it into typed, owned, dependency-ordered actions, applies policy, executes in the tools the team already runs, and remembers why — so the next decision routes faster.

What happens when Linear or Notion ships this?

They already did, partly. Linear Asks turns a Slack thread into a tracked, owned issue. Notion Custom Agents read Slack and write to Notion databases. Single-tool decision-to-work is solved, inside the tool, free.

That closes off the version of this company that was just a better intake form, and it’s why the ICP and the positioning both moved this year.

What neither can do is govern an action in a tool they compete with. Linear will not gate a Gmail send behind your policy; Notion will not own your engineering tickets. The neutral position is structurally unavailable to both of them, and that’s the whole company.

The honest risk: if a team standardises entirely on one vendor and accepts that vendor’s agent everywhere, there is no gap for Conductor to sit in. That’s the bet, and design partners are how I find out whether mixed stacks care enough to pay.

Isn't this just a wrapper around an LLM and MCP?

A wrapper is a single prompt hoping for the best. Conductor is a pipeline: sanitise → triage → synthesise → guardrail → execute → learn. Nothing reaches a tool without passing a policy check, and every approved or rejected card is recorded in per-workspace decision memory.

Being MCP-native is table stakes and it cuts both ways — the protocol that makes Conductor easy to adopt makes it easy to replace. The claim isn’t the pipeline. It’s the position: the only layer in the stack with no reason to prefer one vendor’s tool.

Honest version: the moat is a thesis being tested, not a proven barrier. The test is whether decision-memory retention compounds across real design-partner usage. That measurement is the point of the next eight weeks.

Motion, Lindy and the meeting-notes tools already do a version of this. How is Conductor different?

They draft; Conductor executes. Those tools schedule your tasks, summarise your meetings, or suggest next steps for an individual. Conductor’s guardrail pipeline creates the Linear ticket, sends the Slack message, and closes the loop — across the team’s tools, with a record of who decided what and what happened.

The buyer is different too. Those are individual-seat sales. Conductor sells to an operations or engineering function with coordination overhead — a buyer with real budget and a seat-expansion path. The full tool-by-tool map is on the Compare page →

Isn't this just Zapier with an LLM?

Zapier executes deterministic rules on structured triggers: when X happens in this app, do Y in that one. Conductor interprets unstructured intent — a sentence a human wrote — applies judgement-shaped policy, and decomposes it into typed, dependency-ordered, owned actions.

Different job to be done. Zapier automates the predictable. Conductor handles the judgement calls, which is where coordination budget actually goes.

What's stopping Microsoft or Atlassian from building this?

Nothing, inside their own tools — they will build governed AI features there, and that threat is real. It should be named, not dismissed.

What they can’t do is be neutral. Atlassian governing an action in Linear, or Microsoft gating a send in Slack, is a product decision their business model forbids. Conductor’s differentiation is that position plus the decision-memory data asset — not a permanent technical barrier, and the pitch doesn’t pretend otherwise.

Is this a feature or a company?

It’s a feature if the wedge stays “founder productivity.” As decision execution infrastructure sold to ops and engineering functions, there is an existing budget line (workflow and automation spend), organic seat-by-seat expansion, and a per-workspace data asset that compounds with usage.

Said plainly: this is unproven until design-partner usage data exists. The raise exists to produce that proof.

Why isn't this for founders anymore?

Because founders are a weak buyer for this product. Small budgets, no seat expansion — a solo founder never buys a second seat — and the most crowded category in AI tooling.

The pain Conductor solves best — “who owns this, did it actually happen, and who approved the part that left the building” — is felt hardest by operations and engineering leads at 20–150 person companies running Linear and Slack. That buyer already budgets for coordination tooling, and expands naturally as teammates start receiving Delegate cards.

What's proven versus not, right now?

Proven

  • End-to-end execution in four tools: Linear, Slack, Notion, Gmail. One directive in, owned work out.
  • Zero external sends, payments or irreversible actions without human approval — by construction, not by policy document.
  • Per-workspace decision memory live, retrieval under 50ms at current volume.

Unit economics are not a constraint at this stage; cost per directive is a footnote on the architecture page, not a selling point.

Not measured yet

  • Approval rate, and whether it climbs as decision memory fills. That is the week-eight deliverable.
  • What this saves a team. We don’t yet know what this costs your team — that’s question one for design partners, and I’d rather leave the slot empty than model it.

Not proven

  • Product-market fit. Conductor hasn’t been in front of design partners matching the new ICP. Recruiting five is the highest-priority item in the company.
Why now?

Two things changed. First, structured output from frontier models crossed a usability threshold in roughly the last twelve months — unstructured human intent can now reliably become typed, executable structure. That wasn’t true when the current category leaders were built. It is also commodity, and that’s the premise rather than the moat.

Second, and more important: in the last year every major tool shipped an agent that creates and acts inside its own product, and not one of them can govern an action in a competitor’s tool. The scarce layer moved from execution to oversight.

How does Conductor make money?

There’s no pricing page yet, deliberately. The direction is per-seat for the people who approve, not for everyone the work lands on — so price tracks the value driver and the expansion mechanic at the same time.

Design partners are free for eight weeks and the price gets set together at the end of it, against usage data rather than a guess.

What does the raise fund, and why is it this size?

The raise is $50,000: $30K for one contract engineer for eight weeks on integration reliability and approval-rate instrumentation, $12K for the five-workspace design-partner programme, $8K for infrastructure, model spend and the security review a 100-person company asks for on the first call.

This is a bridge priced to buy evidence, not runway. Eight weeks, five design partners, one curve. If the approval rate doesn’t climb as decision memory fills, the memory thesis is wrong and the right outcome is that I don’t raise a seed.

What it doesn’t buy: SOC 2, self-serve billing, paid acquisition. Those are seed-round line items, and pairing a small ask with big-round language would be a credibility gap this raise is structured to avoid.

What are the biggest risks?

Four, named plainly:

  • Solo-founder execution capacity. One contract engineer is the first use of funds.
  • Single-vendor consolidation. If teams standardise on one vendor’s agent everywhere, the neutral position has no gap to sit in.
  • Unproven product-market fit. No design partners against the new ICP yet.
  • Incumbent platforms. Microsoft and Atlassian will build adjacent features inside their own tools.

The next eight weeks are built to attack the first three directly.

—Next step

Anything not answered here?

The fastest way to diligence this is a direct conversation. No forms, no funnel.