Two hours after a forty-minute review meeting ended, I opened OCTO and found the things we'd agreed on already sitting in the Loop as task briefs. One of them had a dev agent actively working on it.
Nobody took notes. Nobody wrote up action items. That's the part I want to unpack, because "meeting to task" sounds like a two-step thing and it really isn't.
The problem with meeting notes isn't the notes
We tracked open rates on our own meeting summaries. Three fates:
Someone reacts with a thumbs up, nobody opens it again.
Someone scans it, notices they got assigned three things, remembers one.
Rarely, someone actually does everything on it.
The third case is negligible. But the work still got done — just not by following the summary. Someone brought it up again, or one person happened to remember, or it got re-discussed next week and only then moved.
So the summary works fine as a record and fails completely as a driver. The notes were fine. The format was wrong for what we wanted the notes to do.
Why action items don't survive the handoff
Ask a person to "optimize the dashboard load time, next release" and they have enough to start. They know what the dashboard looks like, why it's slow, roughly when "next release" is, who wants it.
None of that is in the action item. It's in their head.
That's the whole problem. Humans fill gaps from context. Agents can't. An action item that's perfectly clear to a teammate is unusable input to an agent, because the agent doesn't know what to touch, what "done" means, or what it needs first.
We spent a while trying to make action items more detailed. Doesn't work. The concept of an action item is designed for a human reader.
What we actually built
The chain has six stages:
Capture — local real-time transcription during the meeting
Speaker separation — who said what, because tasks are owned by people
Topic segmentation — a 40-minute meeting is seven things, not one
Structuring — each thing becomes a task card
Dispatch — the card becomes a task brief in the Loop, routed to an agent
Execution and verification — the agent picks it up, works, self-verifies, delivers, a human accepts
Stages 1–3 are data movement. Stage 5–6 is plumbing. Stage 4 is where the whole thing lives or dies.
Stage 4 is the bottleneck
A task in natural language is spread across sentences. Someone says "this dashboard is slow," the tech lead says "no pagination," the PM says "next release." That's one task, and not a single sentence is a complete task description.
A brief that an agent can actually work from needs:
Goal. Optimize dashboard load time.
Constraints. Via pagination, next release. And "next release" has to resolve to a date, because agents don't understand fuzzy version numbers.
Acceptance criteria. The hard one. What counts as fast enough? If you don't pin it to something like "P95 first paint under 2 seconds," the agent finishes and you still can't tell whether it's done.
References. Which dashboard, where the logs are, whether there's prior work on this. None of that is in the meeting audio — it has to come from team context.
This is why a transcription tool can't solve it. Transcription solves recording. It doesn't solve understanding. The gap between the two is filled with your team's own context — your project structure, your stack, your definition of done.
Our rule: when in doubt, stop and ask rather than guess. An agent working toward a wrong acceptance criterion is worse than an agent that waited two minutes for clarification.
Why the task brief matters more than it looks
I think the task brief is the most underrated interface in human-agent collaboration.
Meeting summaries exist to move information between humans. Humans tolerate a lot of ambiguity — "optimize the load time next release" fills in about 70% automatically.
Agents tolerate none. No acceptance criteria and they don't know when to stop. No constraints and they pick the dumbest safe path. No references and they'll invent context.
So the field design of a task brief is really a definition of what an agent needs to know to do the job. Get it right and completion quality jumps. Get it vague and you get a pile of deliverables that look done and aren't.
The visibility part
One more thing, and it's why I noticed the tasks running two hours later.
Once a brief is in the Loop it isn't a black box. Who picked it up, what stage it's at, where it's stuck, when it'll land — all queryable state. Nobody has to schedule a follow-up meeting to find out whether the thing we agreed on is moving.
That sounds minor. It changed how our meetings feel. "Who owns this" used to be a question that got answered at the next meeting. Now it's a status field.
Where this actually stands
Honest version:
Working: capture, separation, segmentation, dispatch, execution visibility. We use these daily.
Still rough: structuring accuracy on complex tasks — the kind where a sentence has nested conditions and exceptions. Those often need a human to patch before dispatch. We're not pretending that step is solved.
Our call is that this is the right place to keep a human in the loop. Let the model handle the 90% of grunt work, keep a human on the 10% that's judgment. Chasing 100% automation gets you a pile of wrong tasks and nobody to blame.
If you're building something similar
Don't start with transcription accuracy. Start with "how do we define the acceptance criteria for a task." That's the part that decides whether the chain runs at all.
The project is open source — setup and the schema are in the repo README. Issues welcome.
Top comments (0)