Open for new projects
Insights · AI meetings

How to brief a live meeting copilot so it helps in the interview, not after it

Most people brief a meeting copilot about themselves. The copilot then produces cards about them, which is not what an interview or a sales call needs. The five lines a brief should contain, a worked example, and three changes we made to Loquelle because of what weak briefs do.

How to brief a live meeting copilot so it helps in the interview, not after it

By ·

Every week we read a sample of Loquelle calls that members report as "the recap was great but the live cards were generic". The pattern behind almost all of them is the same, and it is not in the model. It is in the brief typed before the call.

A copilot has three things to work from during a live call: the transcript as it arrives, the document you attached, and the brief. The transcript is the other side's words. The document is your past. The brief is the only place where you tell it what this call is for, and it anchors on the first thing you write. Write a paragraph about your situation and you get cards about your situation.

A brief about yourself produces cards about yourself

Take an invented but typical example. A candidate types: I have an interview for a senior developer role, my current contract is ending and the company is in trouble, I am looking for something stable, help me in the interview. Then the interviewer spends two minutes explaining that the company trains small language models and wants someone to build the pipelines and demo applications around them.

What can the copilot do with that? It knows nothing about the company, nothing about what the interviewer wants, nothing about which two or three things the candidate wants to land, and nothing about what to keep out. So the cards are the only kind it can write: "ask about the tech stack", "ask what success looks like in six months", and a pitch assembled from the CV that offers skills the interviewer never asked about. None of them is wrong. None of them helps. And the one specific thing in the brief, the trouble at the current job, is exactly the story the candidate then tells unprompted, because it was loaded in their head as well.

A copilot does not fix a brief. It amplifies it.

What a brief should contain

Five lines, in this order, because the first line is what the copilot anchors on.

Who you are talking to and what they want. The need, not the company name. "A company training language models of all sizes, building a small on-site team; they want a full-stack engineer who can build pipelines, evaluation tooling and demo apps next to the data scientists." Every card from then on is matched against that sentence.

Your two or three stories, with numbers. "Built the on-premise inference layer that lets regulated customers run the product on their own servers. Own the evaluation harness that lifted measured model quality 20% over baseline." Stories with numbers become answers; a list of skills becomes a recital.

The questions you want to ask. When the interviewer says "any questions for me?", the copilot should hand you one about something they said in this call, not "tell me about the tech stack". Write three in advance and it picks the one that fits the moment.

What not to raise. "Do not mention my current employer's situation. If asked why I am moving, the project is winding down and the timing works." This is the line most people never write, and it is the one that saves the two minutes above.

Your constraints, if the other side cares. Start date, relocation, notice period. If the interviewer stresses on-site twice, a brief that says "I will relocate and can start in January" lets the copilot put that sentence in front of you the moment they do.

The same five lines work for a sales call (who they are and what they are trying to fix; two customer stories with numbers; the three discovery questions; the discount you will not offer; your delivery dates) and for a client review (what they asked for last time; what shipped, with numbers; what you need from them; the topic you are not reopening; the next milestone).

Three things we changed because of weak briefs

The copilot now has a rule that an answer must respond to the need the other side just described, naming their topic in its first sentence and matching one of your strengths to it. A recital of your background, or a pitch for skills nobody asked about, is rejected. An interviewer who said "we train language models" hears about your model and pipeline work, not your mobile apps.

Pressing "Say now" twice on the same ground used to produce a card that read "already suggested above". That is a note to a developer, not something a person can use mid-sentence. Now the copilot tries once more for a genuinely different angle, anchored on the last minute of the transcript, and if it still has nothing new it says nothing at all.

The nudge that tells you to press the screen-reading hotkey used to fire on ordinary phrases like "looking at your background". It now fires only in a technical call, or when the words are unmistakably about a problem on the screen. And the brief box itself now says what to put in it, in the web workspace, the Chrome extension and the Windows app.

The honest limit

None of this makes a copilot a substitute for preparation. What it does is turn preparation into something you can use while you are talking, which is the moment preparation usually deserts people. Write the five lines, attach the CV or the deck, tick Technical mode if code or design may come up, and press Prep me before the call so the likely questions are already answered in your own words. Then the cards during the call are specific, because you made them specific.

Want this built for your business?

Scope it with Mark