You are on a call working through an idea, and somebody raises competition. Nobody on the call has researched it. So either somebody drops out of the conversation to go look, or the question turns into an action item and gets answered well after the discussion that needed the answer has ended.
What I want is an agent sitting on that call, taking actions live off the transcript. I do not know whether tools exist in the shape I am describing.
Delegating From Inside the Call
In the version I am imagining, the agent is listening to the call. Mid-conversation you tell it to go find out who else is doing this, and it goes. It comes back one of two ways: a summary dropped into the chat while everyone is still talking, or an actual interruption through a live voice interface. Either way, nobody leaves the conversation.
Research is just the easy example. A working call spins off action items nobody writes down, questions nobody chases, and sometimes a code change everyone agrees on and then forgets to start. Most of that work does not need someone who is currently in the conversation. An agent that can spawn those in the background means the discussion does not have to stop for the work it produces.
The Incident Call Version
I think this could be good on an incident call. Everyone is on the bridge, one person is narrating what they see in the logs, someone else is guessing at a cause, and the actual debugging is happening in one person’s terminal while everyone else watches. An agent on that call could be running the queries as they get proposed, pulling the deploy history somebody just asked about, and posting what it found, with nobody dropping out to type it.
I tried AgentCall. It was cool but clunky, and I have it filed as something to look at again.
The Night Shift
The extension of this is a whole engineering day reorganized around it. Picture engineers in a conference room for maybe four hours, whiteboarding what the product should be and where the interfaces should sit. Call it an architecture review, and record the whole session. Then the night shift takes over, and agents build out prototypes and PRs overnight against the recording.
The engineers come back in the morning, spend an hour or two reviewing the code, running initial tests, and merging. Then they go back into the room for another three-hour design discussion, and it happens again that night. It is kind of like having a dev team that builds the whole sprint overnight.
I have not run a day like this, and I would expect the first few attempts to be rough. Recorded whiteboard sessions would be messy input, and a lot of what gets decided in a room gets decided in a diagram and a shrug rather than a sentence.
What Gets Scarce
The constraint in a day like that is the four hours in the room. That is the synchronous, high-bandwidth part, where the architecture decisions and the trade-off calls actually get made, and it is the input you cannot easily get more of. Most of what comes out of that room is execution, and execution is the part you hand off, whether it spins off live in the middle of the call or runs on the night shift.
A day built this way is mostly meetings, which is normally the complaint about a day. If the work is already running in the background off the transcript, the meeting stops being the thing that delays the work and starts being the thing that dispatches it.