Can Apollo turn a sales call into a spec and a pull request?

A customer asks, on a call, whether the product can export to their format by Friday. The room nods. The call ends. Then the requirement begins its slow death: it lives in one person’s memory until they type it into a doc, the doc waits for someone to read it, the reading turns into a ticket, the ticket waits for a sprint, and somewhere in those handoffs the “by Friday” quietly becomes “next quarter.” Nobody decided that. It just leaked out at every seam.

Here is the strange part. By the time the call ended, the hard part was already done. The customer had stated the requirement out loud, in their own words, with an owner implied and a date attached. Everything after that was transcription, routing, and waiting, clerical work dressed up as a process.

That’s the whole idea, and the rest of this post is the mechanism. The transcript already contains the requirement; the rest, the task, the spec, the branch, the draft PR, is a pipeline, not a meeting. The work between “they said it” and “an engineer can review a fix for it” is plumbing. And plumbing is something an operating system runs, so a person doesn’t have to.

First, what actually leaks

Walk the naive path, the one almost every company runs today, and count the handoffs.

The call happens. A salesperson, if they’re diligent, types a summary afterward. The summary goes to a channel or a doc. A product person reads it, eventually, and decides it’s worth doing. They write a ticket. The ticket gets groomed, estimated, prioritized. An engineer picks it up, reads the ticket, and discovers the ticket lost the nuance the salesperson lost from the call, so they ask a clarifying question, which routes back through two of those people, who half-remember.

Each arrow in that chain is a place the requirement can stall, shrink, or vanish.

It feels like rigor. It’s mostly latency. The information didn’t get better as it traveled through five people and four tools, it got worse, because every handoff is a lossy copy made by someone with their own inbox on fire. The customer’s exact words, the part that mattered, are sitting in a recording nobody will open again.

So the question isn’t “can AI write code.” Everyone can see that it can. The question is whether the messy, human, multi-tool gap between the call and the code can be run as a pipeline. Because that gap is where the work actually dies.

Extraction: the transcript is structured data wearing a costume

The naive way to capture a call is a summary. A paragraph a human writes from memory, hours later, optimized for looking thorough in a channel.

Summaries fail in a specific way: they keep the vibe and drop the commitments. “Great call, lots of interest, they want some export stuff” is a sentence that has survived a thousand pipelines and built nothing. The owner is gone. The verb is gone. The date is gone. What’s left can’t be acted on, only re-discussed.

The transcript doesn’t have that problem, because it never editorialized. It’s a record of who said what. And buried in it are exactly the three fields any task needs: an owner (who’s accountable), an ask (what specifically), and a due (by when). “Can you have the CSV export by Friday?” is not a vibe. It’s a row in a table that happens to be wearing the costume of a sentence.

The first move, then, isn’t to summarize the call. It’s to read it the way a parser reads a log, and pull the commitments out as structured fields. Owner, ask, due. The transcript already contains the requirement; extraction is just refusing to let it stay trapped in prose.

This is the step that makes everything downstream possible. A summary is a dead end, a human has to re-read it to act on it. A structured task is a live wire: it can be assigned, scheduled, and handed to the next stage without a person standing in the middle re-typing.

From task to spec: naming what “done” means before anyone builds

Here’s where most automation dreams crash. You have a task, “build CSV export by Friday”, and the temptation is to throw it straight at a code generator and hope.

That fails, and it fails the same way every time. A task says what someone wants. It doesn’t say what done looks like. Does “export” mean every field or the visible ones? Which format exactly, their dialect of CSV, with their delimiter, their date format? What happens to the row that has a comma in it? A model handed a vague task will confidently produce a vague answer, and you’ll have automated the production of work that has to be redone.

So the task becomes a spec first. Not a novel, a short, testable statement of the requirement and its acceptance criteria. The columns that must appear. The format, named precisely. The edge case that has to not break. The spec is the contract between “what they asked for” and “what gets built,” and it exists so the thing that gets built can be checked, not just hoped at.

A spec is also the natural place for a human to intervene cheaply. Catching a misunderstanding here costs a one-line edit. Catching it after the code is written costs a rewrite. The spec is the last place a wrong assumption is still free.

The transcript already contains the requirement. The spec is just that requirement, written down precisely enough that a machine, or a new hire, could build against it and a reviewer could grade it.

The runner: a sandbox that proposes, never imposes

Now the part everyone wants to skip to: the code. The naive fantasy is the agent that reads the task and pushes the fix to production while you sleep.

Don’t build that. An agent that can merge its own work to the main branch is not an employee, it’s an unsupervised intern with commit access, and the first time it confidently ships the wrong CSV dialect to every customer, you’ll understand why no sane company lets even its best engineers push to production without review.

The right shape is narrower and much safer. A sandboxed runner, an isolated workspace, walled off from anything live, picks up the spec, opens its own branch, and does the work there. When it’s finished, it doesn’t deploy anything. It opens a draft pull request: a proposed change, sitting next to the code, with the diff visible, the spec linked, and a human’s name in the reviewer slot.

A draft PR is the load-bearing trust gate, and it’s worth being exact about why. It is visible, the change is a diff a person can read line by line, not a black box. It is reversible, nothing is live, so nothing is at risk. And it is stopped by default, it goes precisely as far as “here’s what I’d do” and no further. The runner’s authority ends at “proposed.” A human’s begins at “merge.”

So the answer to the title is yes, with one deliberate edge. A call can become a task, a task a spec, a spec a branch, and a branch a draft PR, automatically, while the office is dark. But it stops there, at the edge of the irreversible, and waits for a person. The transcript already contains the requirement; the rest is a pipeline, right up to the one gate that should never be automatic.

Why the gate is the point, not the limitation

It’s tempting to read the draft-PR stop as the unfinished part, the place we haven’t automated yet. It’s the opposite. It’s the part we automated on purpose to be manual.

Trust isn’t a switch you flip on day one. It’s a level a system climbs, one verified result at a time. A pipeline that opens draft PRs lets you watch it work without betting the company on it. You read its first hundred proposals. The ones that are right, you merge in seconds, which is a hundred times faster than writing them. The ones that are wrong, you send back, and the wrongness was caught at a diff, where it’s cheap, instead of in production, where it isn’t. Over time, for the narrow, well-specified things it has gotten right again and again, the leash can lengthen. But it lengthens because it was earned, not because it was assumed.

That’s the difference between a pipeline you’d actually run and a demo you’d never trust. The demo auto-merges and looks magical for a week. The pipeline proposes, gets reviewed, and is still running a year later, because every dangerous step has a human standing at it, and every safe step has been handed to the machine.

The turn: the meeting was never the work

Step back from the plumbing and look at what changed for the people.

The salesperson’s job stops being “remember to write up the call” and goes back to being “have a good call.” The product person stops being a router for things other people said and starts deciding which of the now-captured requirements are actually worth building. The engineer stops reading lossy tickets and starts reviewing concrete proposals, reading a diff and saying yes or no, which is the part of their judgment that was always the valuable part. Nobody got replaced. The clerical layer between them did.

That’s the quiet promise. Not that software writes your code, but that the distance between a customer’s words and a reviewable change collapses from weeks of handoffs into a pipeline that runs itself and then politely stops, holding the door open for a human to walk through and decide. The transcript already contained the requirement. It always did. The only thing that ever stood between it and a fix was the meeting we kept holding to move it by hand.

---

We’re building this at Apollo Space, an operating system that treats the gap between what a customer said and what a reviewer can approve as plumbing, not as someone’s afternoon. If the most exhausting part of your week is ferrying requirements from one tool to the next, that work was never the work. It’s time you got to do the part that was.