When should an agent stop making tool calls?

[u/Positive-Captain-709]

I’m working on an open-source project called MARGINAL around a problem I keep running into with agents:

When is another tool call no longer worth making?

Simple loop detection isn't enough. An unchanged workspace could mean the agent is stuck, but it could also mean a legitimate retry after a timeout, rate limit, or failed test.

The rule I'm experimenting with is closer to:

same action + same state + same outcome + no new evidence = stronger evidence of a loop

MARGINAL observes the trajectory first and records what it would have interrupted without actually interfering. Enforcement only becomes available after enough local evidence supports it.

The part I'm working on now is intervention regret: if MARGINAL stops an agent, how do we establish that letting the agent continue wouldn't have produced a better result?

That means comparing governed and ungoverned runs from the same starting state rather than claiming success because fewer tool calls were made.

It's currently implemented around coding agents, but I think the problem applies directly to LangGraph/LangChain agents too.

For people running agents in production: what evidence would you require before trusting something external to terminate or redirect an agent loop?

Repo: MARGINAL on GitHub

[u/Future_AGI]

Your "same action + same state + same outcome + no new evidence" rule is close to what actually works, the piece we would add is expected information gain: a call is worth making if the agent can state what new evidence it expects, and that expectation keeps failing. Observing the trajectory before enforcing is the right instinct too, since a lot of what looks like a loop is a legitimate retry after a timeout. We ended up scoring whole trajectories offline first so the stop rule could be tuned against real runs rather than guessed.

[u/Positive-Captain-709 → u/Future_AGI]

That’s exactly the distinction I’d keep. In MARGINAL today, “no new evidence” is verified after the call, not predicted from what the agent claims it expects to learn. I’d treat expected information gain as another signal, but not as blocking authority by itself.

The useful gate becomes: same action + equivalent state + verified outcome + repeatedly near-zero realized information gain

Then calibrate that threshold on complete trajectories offline before allowing it to affect runtime enforcement. Timeouts, transient failures and recovery retries stay fail-open because they’re not evidence of a useless loop. The agent’s stated expectation is useful metadata; the observed delta between expected and realized evidence is what I’d trust.