The most expensive bug in agent content workflows

Here's the bug I see most often when teams integrate VeracityAPI into agent workflows: the unbounded revise loop. It's the most expensive bug in agent content systems and almost everyone hits it at least once.

The setup is innocent. You wire VeracityAPI into your content pipeline. The agent generates a draft, you score it, the gate returns 'revise,' you pass the evidence array back to the rewrite agent, the rewrite agent produces a revised draft, you score again. So far so good — this is exactly the pattern the API is designed to support.

The problem is the loop's exit condition. If you don't explicitly cap the number of revise cycles, you can run indefinitely on a single document. The rewrite agent will happily try again. The scoring gate will happily say 'revise' again. Both systems are doing their jobs correctly. Neither has any way of knowing the loop has become economically irrational.

I've seen teams burn through $200, $300, $500 on a single document before they noticed the pattern. The economics seem fine at the per-call level — $0.005 per scoring call, a few cents per rewrite — but the multiplication is brutal. Five rewrites per page, 100 pages in the queue, three documents that get stuck in an infinite loop: suddenly you're looking at a four-figure surprise on next month's bill.

The fix is four lines of code and one configuration decision.

The four lines: track a counter on the state object. Increment it every time you re-enter the score node. If the counter exceeds your max-attempts threshold, route to escalate instead of rewrite. That's it.

The configuration decision: what's the right max-attempts value? My recommendation is three. Here's the reasoning:

On the first rewrite cycle, the rewrite agent has the full evidence array and can usually address it. Most drafts that fail on first scoring pass within one rewrite — call it 70%+ in healthy steady state.

On the second cycle, the agent has the evidence from both the original AND the first rewrite. If it still can't fix the document, the problem usually isn't a writing problem — it's a structural problem (the document is making a claim that can't be specifically supported, or the topic is one the generation prompt isn't suited for). Another 20% land here.

By the third cycle, you're paying real money to discover what's already true: this document needs a human. Escalate, log the evidence trail for the editor, and move on.

Above three attempts, you're not getting better content — you're getting the same evidence categories paraphrased into different generic alternatives. The cost-benefit curve goes negative fast.

There's a related anti-pattern worth flagging: scoring on a moving threshold. Some teams set up the gate to use a probability score (content_trust_score) as the routing decision instead of recommended_action. That works until the underlying model recalibrates in a version bump, at which point your 0.65 threshold no longer means what it used to mean and your gate is quietly letting through drafts that previously would have been caught (or vice versa).

The recommendation is to branch on recommended_action exclusively. The action labels stay stable across versions because they're tied to the decision the response is designed for. The score is for your telemetry; the action is for your code.

Both patterns — the unbounded loop and the score-threshold drift — share a root cause. Agent content workflows are easy to write but hard to operate. Every loop, every threshold, every edge case becomes part of the runtime surface area you're maintaining. The reason the API ships with recommended_action as the primary integration field, and the reason this post exists, is that I'd rather your agent workflow run cheaply and stably than save you the four lines of counter code.

If you're integrating VeracityAPI into a LangGraph workflow specifically, the integration page at /integrations/langgraph has the full pattern with the bounded-loop implementation. The same pattern applies to OpenAI Actions, Claude tool_use, or any other agent framework — the framework changes, the failure mode doesn't.

Required caveat: VeracityAPI is a workflow-routing API, not forensic authorship proof. See /methodology for what we claim and don't claim.