← All guides

Inside a live session — what the LivePair agent actually does

When people hear 'AI copilot' they picture a chat window you type into. A LivePair live session works nothing like that. This page walks through what actually happens while a session runs — what the agent watches, what it decides on its own, and what you never have to ask for.

It watches before you ask

The moment a session starts, the agent begins observing — your screen, your camera view of the room, and the conversation audio. It doesn't wait for a prompt. It builds a running model of what you're doing: the task, the artifact on screen, the people in the conversation, and where things seem to be heading.

This is the core difference from every assistant you've used: there is no 'explain your context first' step. The context is the session itself, streamed continuously.

It drives the viewer — you don't

The second screen isn't a dumb mirror. As the session moves, the agent navigates the viewer itself: it follows the file you're editing, scrolls to the relevant code, brings up the artifact being discussed, and pins what matters. When you jump from a test failure to the implementation, the display is already there — you never touch it.

If a teammate joins the viewer link, they get a read-only seat with a derived access token — they can watch the agent's current view but can't drive it or see your controls. The link can be shared without exposing your session key.

It understands conversation, not just commands

The agent listens to the whole room, not a push-to-talk button. It distinguishes work dialogue — you and a colleague arguing about an approach — from requests actually directed at it. Talk over a problem with someone and it follows along silently; say 'LivePair, pull up the schema' and it acts.

Because it tracks the conversation as a timeline, it can answer 'what did we decide about the retry logic ten minutes ago?' without you re-explaining anything.

It detects the mode of work itself

There's no mode picker. The agent infers what kind of session it's in from evidence: screen content, speech patterns, tools on screen. Heads-down engineering with an IDE and stack traces reads differently from a slide deck with a room full of questions, which reads differently from a support call.

When the mode shifts — a debugging session turns into an impromptu demo — the agent's posture shifts with it: what it watches for, what it surfaces, when it speaks. You never tell it 'now we're presenting.'

It reacts to vague work — and flags risky calls

You don't need a well-formed question. Even when the task is vague — half an idea on screen, a design you're still circling — the agent follows along and reacts to what's actually happening, not to a clean prompt.

When a decision is about to become risky or hard to undo, it surfaces that while there's still time to act — and it remembers it. The flag stays part of the session's context, so the consequences of that call keep being tracked instead of forgotten the moment it scrolls away.

It speaks up before you have to ask

The point of a live model is proactive help: a test that just broke, a number on screen that contradicts what was said earlier, a decision about to become hard to undo. The agent surfaces these while there's still time to act — not in a summary email after the damage.

Just as important: it knows how to stay quiet. If nothing needs surfacing, it produces nothing. No filler, no 'just checking in' — silence is a valid output.

What a session costs

Live sessions are billed by time — $10/hour, purchased in 1–5 hour blocks that sit in your account until you draw them. Separate from agent chat credits; a completed purchase also grants a short trial session once. Details: pricing.