The triage desk that reads the meetings
A warehouse can unify every number in a business and still leave the operation running on memory. Here is the AI layer that turns meeting transcripts and Slack chatter into approved, filed tasks, and why the one human click in the middle of it is the whole design.
The data was unified. The operation still ran on memory.
By the time this layer was built, the hard part looked done. 12+ revenue systems fed one Postgres warehouse. Executives queried it in plain English through a read-only MCP server. Every sale traced back to the conversation that produced it.
And yet the day-to-day still leaked. Commitments made in meetings and Slack died there. Nobody knew which sales calls were actually being recorded. Executives asked for numbers instead of receiving them.
None of that is a data problem. It is the gap between saying and doing. A commitment lives exactly as long as the meeting it was made in, unless something carries it out of the room. In most companies that something is a person with a notebook, and the notebook is the single point of failure.
Read, extract, propose, file
The triage desk is that person, minus the notebook. It reads meeting transcripts and Slack. It extracts committed action items, meaning the moments where someone said they would do a specific thing. It posts each one for one-click human approval. Approved items are filed into the task system, with an owner, and nothing else happens until a person clicks.
Transcripts and Slack are the two inputs because they are the two places commitments get made. Meetings are where people commit out loud, in front of others, and then move to the next agenda item. Slack is where people commit in passing, three messages deep in a thread about something else. Both are also the two places commitments go to die, for the same reason: the medium moves on and the promise does not move with it.
There is one shortcut. Tagging the bot in Slack files a task in about one second. No approval step, because the person tagging it has already made the decision. The desk only asks a human to decide when the decision has not been made yet.
Why the approval click is the whole design
The tempting version of this system has no gate. The model reads the transcript, decides what was committed, and files it. It is faster, and it demos beautifully. It is also the version that gets switched off within a month.
A model reading a transcript is good at finding sentences that sound like commitments. Whether a sentence was a commitment is a different question. "I could look at that" and "I will have that by Thursday" read alike to a machine and mean opposite things to the people in the room. Context the transcript does not carry, like who reports to whom and what was decided last week, settles it. A person has that context. A model does not.
File one task nobody agreed to and the board loses a little trust. File ten and people stop looking at the board. A task system nobody trusts is worse than no task system, because it gives the appearance of control without the substance.
The opposite design fails just as reliably. A person reading every transcript and every thread, pulling out the commitments by hand, is the job that never gets done. It is tedious, it is nobody's actual role, and it is exactly how the operation ended up running on memory in the first place. Removing the human from the reading is not a compromise. It is the only way the reading happens at all.
So the click does three jobs at once. It is a correctness gate, catching the false commitments before they cost anyone anything. It is an ownership transfer, because the person who clicks now stands behind the fact that this task exists. And it is feedback, because watching what gets rejected tells you exactly what the desk is over-extracting.
The rule is simple: keep the human where the judgment is, and remove the human everywhere the work is typing. Reading a two-hour transcript, pulling out the twelve sentences that matter, writing them as tasks, assigning them, and filing them is typing. Deciding whether they are real is judgment. The desk does all of the first and none of the second.
The same layer took over the reporting
Once the desk existed, the same pattern fit everything else that used to depend on someone remembering. A daily scorecard posts itself to Slack every afternoon. A weekly summary posts every Monday. A live executive dashboard splits return on ad spend into cash collected versus contracted revenue, because those are different questions and a founder needs both answers on the same screen.
The split matters more than it looks. Contracted revenue tells you what the team closed. Cash collected tells you what the business can actually spend. Return on ad spend computed against one number looks very different from the same ratio computed against the other, and a founder who only ever sees one of them will make the wrong call on next month's budget. Putting both on one screen ends a recurring argument before it starts.
Error alerts and a daily health check watch the whole system. That last piece is unglamorous and it is what makes the rest trustworthy. Reporting that arrives unattended is only valuable if you find out the moment it stops arriving.
788 calls, and the number nobody could prove
The same layer pulls call recordings in automatically, with coverage views that show exactly which reps record and which do not. 788 sales calls were ingested and coverage-scored.
The result surfaced something everyone suspected and no one could prove: nearly half of all sales calls were never being recorded. That is not a tooling problem. It is a people problem, and until the coverage view existed it was an argument. Afterwards it was a number, per rep, and the argument ended.
Coverage is a per-rep question, so the view is per rep. An aggregate hides exactly the thing you need to see, because a team average of "about half" could mean everyone records half the time or half the team records nothing. Those are different problems with different conversations attached, and only the per-rep view tells you which one you have.
This is the quiet value of an operations layer. It does not fix behaviour. It makes behaviour undeniable, which is the step the fix was waiting on.
What the layer did not do
It did not make a single decision. Every task on the board was approved by a person. Every rejected item vanished without a trace, which is the point.
It did not fix the recording gap. It proved it. Closing it is a management conversation, and no amount of automation substitutes for having it.
It did not run itself without care. When a production incident hit, it was diagnosed and resolved the same day, and the fix left the core pipeline 30x faster, 638 seconds down to 21. Same-day was possible because the error alerts and the daily health check said exactly where to look. Unattended does not mean unwatched.
What changed
788 sales calls scored for coverage, with a per-rep answer to a question nobody could answer before. Executive reporting that arrives unattended, every afternoon and every Monday. Commitments that survive the meeting they were made in, each one approved by a human in one click and filed by a machine in about one second.
One person built and runs it, on top of a warehouse one person built. That is the shape of the work now: the machine reads and files, the person decides, and the operation stops running on memory.
Want your operation to stop running on memory? Get in touch.