Live agent logs as a QA tool: what to read, what to ignore, what to intervene on

Watching a run scroll by is not QA. Squinting at every line, waiting for something to feel off, will burn your afternoon and teach you nothing. The point of a live agent log is that you can see the work happening in enough detail to catch a bad run early, then step away and trust the loop for the rest.

The trick is knowing which lines are signal and which are just the agents talking to themselves.

What the log is actually showing you

A run passes through three agents before it hits your approval gate: research, writer, editor. Each one narrates what it is doing as it goes. The research agent lists sites it is reading, keywords it is weighing, angles it is discarding. The writer agent shows section-level progress, cites which brand voice rules and writing rules it is applying, and flags moments where a source contradicts itself. The editor agent surfaces the specific edits it is making and why.

None of this is decorative. Every line is a choice point the agent has just made, and every choice point is a place a run can quietly go wrong. Reading logs well is really reading a decision trace.

Research agent: the signals worth watching

The research phase is where most bad posts get born. If the topic angle is wrong here, no amount of good drafting will save it downstream.

Watch for these:

• Repeated pivots on search intent. If the agent circles back to redefine what a query means more than twice, the topic is ambiguous and the run will produce a draft that hedges. Interrupt, sharpen the brief, restart.
• Competitor coverage that leans on one source. A healthy research trace pulls from four or five distinct places. If eight sequential lines all pull from the same domain, the eventual draft will read like a rewrite of that site. Redirect the agent to broaden.
• A cornerstone framing collapsing into a listicle. You told the run to produce a cornerstone piece, and the log starts naming out top-ten style headings. That is drift. Stop it before the writer inherits the wrong shape.
• Silent gaps in the questionnaire. When the agent notes a missing answer and moves on, that is fine. When it moves on and then invents around it, you will see phrases like "assuming the standard approach" or "based on typical implementations." Every instance of that language is a place the final post will have a soft claim you cannot verify.

What to ignore in the research log: the noisy exploration at the start. The agent will read a lot of things it does not use. It is supposed to. Do not flinch at the first three off-topic sources; flinch when the fourth one is off-topic too.

Writer agent: catching voice drift in flight

Voice drift is subtle. A draft can be technically correct, on-topic, well-structured, and still sound like it was written by nobody in particular. The writer's log is where you catch this before the whole post is stamped in the wrong tone.

Look for:

• Rule citations dropping off. Early in a section the writer will name the brand voice rules and writing rules it is applying. If those citations thin out after the first two headings, the writer is coasting. The later sections tend to be where generic phrasing leaks in.
• Banned word near-misses. A good writer log flags when it caught and rejected a banned phrase. Seeing a handful of those per run is healthy: the guardrail is working. Seeing zero across a 1500 word run means either the writer never came close, which is unusual, or the check is not being applied. Worth a spot check on the draft.
• Section length ballooning. If the log shows a section running four or five times longer than the outline slot allowed, the writer is padding. That is where the reader loses the thread.
• Repeated re-openings of the same paragraph. One or two in-flight revisions are normal. Six is the writer failing to land the point. Kill it and rewrite the outline slot yourself.

What to ignore: log lines where the writer is quoting the outline back to itself. That is orientation, not output. Also ignore the timestamps unless a single section stalls for more than a minute or two, which almost never happens.

Editor agent: looping and thrashing

The editor takes conversational change requests. Most of the time it applies them cleanly and moves on. When it does not, the log tells you exactly what is going wrong.

Warning signs:

• The same edit being re-applied to the same paragraph. The editor took your instruction, applied it, then read the result and applied it again in a different form. If you see this three times, the instruction is ambiguous. Rephrase it.
• Edits that undo the previous edit. You asked for a tighter intro, and then a warmer intro. The editor is now oscillating between two competing goals. Pick one and lock it in.
• Rule violations reported inside the editor pass. The writer produced clean copy, then your revision request pushed the editor into breaking a writing rule. The log will say so. Do not fight it: the rule wins.
• Comments piling up without a matching edit. The editor is deferring the change and annotating instead. That is a hint your instruction is not actionable in text, it is a scope change. Take it back to the outline.

What to ignore: minor stylistic touch-ups the editor makes without being asked, as long as they are not touching rule-governed language. A comma here, a rephrased transition there, that is craft. Let it happen.

The lines that look scary but are not

Some log patterns look bad on first read and are actually the loop working as designed.

• The research agent throwing out a topic idea after ten seconds of investigation. That is triage, not failure.
• The writer agent noting a source contradiction and picking one side. It is supposed to pick.
• The editor agent refusing an instruction because it would violate a rule you set. That is the human approval structure working before the human even shows up.
• Long silent stretches between narrated steps. The agents are not idle; they are composing.

If you find yourself watching for something to happen, you have already left the useful part of the log. Close the tab and come back at the approval gate.

When to intervene, and when to let it run

The rule of thumb: intervene when the log shows a decision you would have to reverse, not when it shows a decision you would have made differently.

Reversing means the draft goes back to an earlier phase. Reversing means post budget spent twice on one piece. That is the cost you are trying to avoid. If you can see, in the research log, that the topic is going to produce a draft you will reject, stopping now saves a full writer pass. If you can see in the writer log that the voice is drifting, stopping now saves an editor pass and a rewrite.

Different is cheaper. If the agent picks an angle you would not have picked but the angle still meets the brief, let it finish. You can edit at the gate. That is what the gate is for.

The gate also gives you the honest test: would you have caught this problem by only reading the final draft? If yes, live log intervention was not the right move; you were being anxious. If no, the log did its job.

How to intervene without making it worse

When you do step in, be specific. A vague redirect ("make it less generic") sends the editor into the loop pattern described above. A concrete redirect ("cut the intro paragraph, start with the second heading") lands cleanly and shows up in the log as one edit, not a thread of them.

Reference the run's own vocabulary. If the log has been using "cornerstone" and "cluster," use those words back. If it flagged a banned phrase, name that phrase when explaining what you want instead. Agents are better at applying your intent when your intent uses the language they are already tracking.

And when a run is truly off, kill it and restart with a sharper brief. A restarted run against a clean prompt almost always costs less post budget than three rounds of editor patches on a bad draft. The post-based unit rewards decisiveness.

The habit worth building

Skim the research log. Read the first two sections of the writer log carefully, then skim. Read every line of the editor log during an active revision, then close it when the pass is done. Trust the approval gate for the rest.

That is the whole practice. The live agent log is not there so you can babysit; it is there so you know, at any moment, whether the run is worth continuing. Most of the time it is. The value of the log is that on the runs where it is not, you find out in minutes instead of at the end.