Scaling a live transcription pipeline past 40 concurrent sessions
Adaptive buffering, WebSocket backpressure, and the error budget that keeps it honest.
Resources
What is an
execution agent?
The category is new enough that the term gets used loosely. Here is the definition we build against, how it differs from a meeting assistant, and why verification is the hard part.
The short definition
An execution agent is a system that carries out the work a conversation implies, rather than only recording or summarizing it. You judge a note-taker on the quality of its summary. You judge an execution agent on the work it completes.
That distinction sounds like marketing until you look at where the time actually goes. A sales call generates a proposal to send, a CRM stage to move, and a follow-up to schedule. A product meeting generates three tickets and an owner for each. The conversation is not the bottleneck, and neither is remembering it — the bottleneck is a human sitting down afterward and re-entering decisions that were already made out loud.
A meeting assistant improves the memory. An execution agent removes the re-entry.
The distinction
Note-taker vs execution agent
| Meeting note-taker | Execution agent | |
|---|---|---|
| Output | A transcript and a summary | Completed work in your tools |
| Action items | A list for a human to do | Filed, drafted or updated directly |
| Measured on | Summary accuracy | Actions completed and reverted |
| Tool access | Read, or export | Scoped write access, per action |
| Main risk | A wrong summary | A wrong action — hence verification |
| Work left over | All of it | The parts you chose to approve |
Why verification is the hard part
The moment an agent can write to your CRM or your outbox, the cost of a mistake changes shape. A bad summary wastes a minute of reading. A bad action emails the wrong number to a customer, and no amount of apologising un-sends it.
Language models are good at proposing what a conversation implies and bad at knowing when they've made something up. That asymmetry is the whole design problem. Nebula's answer is to keep the two jobs separate: a neural model proposes candidate actions, and a symbolic layer decides whether each one is allowed to run. Three checks have to pass.
Check 01
Grounded
Can this action be traced to specific words that were actually said? If the model inferred it from context with no supporting utterance, it doesn't run.
Check 02
Complete
Does the action have everything it needs to execute — a recipient, a value, a target record? A half-specified action becomes a question, not an attempt.
Check 03
Authorized
Is this action inside the autonomy tier you granted for this tool? Anything external or irreversible defaults to needing a human.
The result is an agent that fails in a specific and useful direction. When it isn't sure, it stages a draft and asks, rather than guessing and sending. That's a worse demo and a better product.
Glossary
Terms worth pinning down.
- Execution agent
- A system that carries out the work a conversation implies, rather than only recording or summarizing it. Measured on completed actions, not summary quality.
- Grounding
- The check that an action can be traced to specific words that were actually said. An ungrounded action is one the model inferred without evidence in the transcript.
- Neurosymbolic verification
- Pairing a neural model that proposes actions with symbolic rules that check them. The model handles ambiguity in language; the rules provide guarantees the model cannot.
- Autonomy tier
- The level of independence granted for a class of action, from draft-only through to automatic execution of reversible internal changes.
- Reversible action
- A change that can be undone without external consequence, such as a CRM field update. Contrasted with irreversible actions like sending an email, which leave the system.
- Local-first capture
- Recording and processing audio, screen and camera frames on the user's own machine before anything is sent to a server.
Writing next
On the list.
Longer pieces in progress. Subscribe below and we'll send them as they land — no other email.
Symbolic checks on top of a language model
What the rules layer actually asserts, and what happens when a proposed action fails one.
Why we trained our own model instead of wrapping someone else's
What a general-purpose chatbot gets wrong about turning a conversation into work.
Consent for an agent that watches your screen
Two-party-consent states, GDPR, and designing a blocklist people actually trust.
Run a discovery call that closes itself
A repeatable structure, and the template that turns every call into CRM-ready actions.
Choosing an autonomy tier per tool
Where teams start, what they loosen first, and the one setting nobody should automate.
Newsletter
Execution notes.
One email when there's something worth reading. No cadence promises we won't keep.