DEV Community: neha chinnasani

We spend a lot of time thinking about what an AI agent should do next.

neha chinnasani — Mon, 12 Oct 2026 02:43:47 +0000

neha chinnasani

Oct 12

When Should an AI Agent Stop?

#ai #programming #webdev #javascript

3 min read

When Should an AI Agent Stop?

neha chinnasani — Mon, 12 Oct 2026 02:41:56 +0000

We spend a lot of time thinking about what an AI agent should do next.

Which tool should it call?

What information should it retrieve?

Should it ask another agent?

Should it retry?

But one of the hardest decisions is much simpler:

When should the agent stop?

An agent that stops too early may miss important evidence.

An agent that keeps going too long may waste time, increase cost, repeat the same work, or even make a good answer worse.

Imagine an incident investigation agent. It checks the latest deployment, service dependencies, known issues, historical incidents, and the current runbook.

At some point, it already has enough evidence to make a reasonable recommendation.

But if the agent keeps searching, it may find older incidents with similar symptoms, deprecated documentation, or unrelated edge cases. More information does not always improve the decision.

Sometimes it creates more confusion.

That means stopping should be part of the agent design, not an afterthought.

A simple approach is to use a maximum number of steps. For example, the agent can make at most eight tool calls before it must return a result.

That protects against infinite loops, but it does not answer the deeper question.

What if the correct answer is clear after three steps?

What if eight steps are not enough?

A better stopping condition is based on evidence sufficiency.

The agent should stop when it has enough reliable information to answer the question, when additional actions are unlikely to change the decision, or when the remaining uncertainty requires a human instead of more tool calls.

For example, if the agent finds that a deployment happened five minutes before an incident, the affected service depends on the changed component, a known issue matches the symptoms, and the current runbook recommends rollback, continuing to search may add very little value.

The system can stop and return its recommendation.

The opposite situation is just as important.

Suppose the agent checks deployments, dependencies, and monitoring data, but the evidence remains incomplete and conflicting.

The agent should not continue calling tools forever hoping that certainty will eventually appear.

At some point, the correct action is:

“I do not have enough evidence. Human investigation is required.”

That is also a successful stopping condition.

Repeated actions are another useful signal.

If an agent keeps calling the same search tool with slightly different queries and receives nearly identical results, the workflow may be stuck.

The application can detect repeated tool calls, unchanged results, or lack of progress and stop the loop.

This is where traditional software engineering becomes important.

The model may decide what action makes sense next, but application code should still enforce limits such as maximum steps, timeouts, repeated-action detection, cost budgets, and human escalation rules.

In other words, the model can reason about when it is done, but the surrounding system should make sure it actually stops.

I think this is an underrated part of agentic system design.

Autonomy is not only about giving an agent the ability to keep acting.

It is also about giving it a reliable way to know when further action is no longer useful.

A good AI agent should not just know what to do next.

It should also know when there should be no next step.

Check this

neha chinnasani — Mon, 12 Oct 2026 02:38:52 +0000

neha chinnasani

Oct 12

Your AI Agent Works in a Demo. But Is It Reliable?

#ai #webdev #programming #productivity

2 min read

Your AI Agent Works in a Demo. But Is It Reliable?

neha chinnasani — Mon, 12 Oct 2026 02:33:18 +0000

AI agents are easy to demo. You give the agent a task, it calls a tool, gets some data, and gives you an answer. Everything looks good. But one successful demo does not tell you whether the agent is actually reliable.

The harder question is what happens when the data is incomplete, outdated, conflicting, or simply wrong. That is where evaluation becomes much more important.

Imagine an incident investigation agent. A user asks, “Why did checkout latency increase after the latest deployment?” The agent checks recent deployments, service dependencies, known issues, and runbooks, then concludes that PaymentService v4 caused the latency increase.

The answer might be correct, but that alone is not enough. What if the agent ignored the actual deployment evidence and guessed based on an old incident that looked similar? The final answer is right, but the reasoning path is weak. The next incident may look similar while having a completely different root cause.

This is why I think agent evaluation should look beyond the final response. We need to understand whether the agent selected the right tools, retrieved the right evidence, used information that was current and relevant, and stopped when the available evidence was not strong enough.

Tool usage itself can tell us a lot. Two agents may produce exactly the same answer, but one might reach it with five relevant tool calls while another makes twelve unnecessary calls, repeats searches, and relies on weak evidence. Both technically completed the task, but I would trust the first system much more.

Another behavior I think we should explicitly test is whether an agent knows when not to answer. Suppose there was no recent deployment, traffic was normal, monitoring data was incomplete, and there were no similar historical incidents. A confident root-cause prediction would actually be a bad result.

A better agent might say that the current evidence is insufficient to determine the root cause reliably and recommend the next investigation step. In that situation, saying “I don’t know yet” is not a weakness. It is part of being reliable.

Evaluations can also expose architectural problems that prompt changes alone will not fix. If outdated documents repeatedly cause bad decisions, the system may need freshness metadata. If the agent keeps using information from the wrong software version, version should probably become part of retrieval. If the model keeps guessing when evidence is missing, the workflow may need an explicit INSUFFICIENT_EVIDENCE state.

That is why I have started thinking about agent reliability differently. The question is not only, “Can the agent complete the task?”

The more important question is:

Can I trust how the agent behaves when the situation is messy?

For me, that is where serious agent engineering starts.

The Engineering Behind AI Agents Is More Interesting Than the Hype

neha chinnasani — Thu, 01 Oct 2026 04:42:25 +0000

Hello DEV 👋

I’m Neha, a Software Engineer with 5+ years of experience building software and cloud systems.

More recently, my work and interests have moved deeper into AI agents, LLM-powered applications, and agentic systems.
What fascinates me most isn't just what an LLM can generate. It's the engineering behind making these systems actually work: tools, context, orchestration, multi-agent workflows, reliability, and the traditional software engineering underneath it all.
I created this space to share practical technical content and break these concepts down from a software engineer’s perspective.
I’ll be writing about AI agents, Agentic AI, LLMs, context engineering, RAG, multi-agent systems, and production AI engineering.
If you're a software engineer trying to understand how these systems actually work beyond the buzzwords, you’ll probably enjoy what’s coming.

Let’s build and understand AI systems one layer at a time.

AI #AIAgents #AgenticAI #SoftwareEngineering