Agentic Workflows: What are AI Practitioners opinions ?

Akash Kamerkar, a senior data scientist at ABB, made a point that many practitioners quietly acknowledge but rarely quantify: development cycles that once took months can now be compressed into days, thanks to agentic capabilities and AI-assisted coding. That is a significant claim, and it is worth sitting with.

But Kamerkar also pushed back on the assumption that this automatically translates into ROI. He pointed to the ongoing infrastructure and API costs that come with running LLM-based workflows at scale. Speed gains are real. Cost neutrality is not guaranteed.

For business leaders, this is a critical distinction. Faster development does not mean cheaper development, particularly during early scaling phases. Any ROI model needs to account for inference costs, infrastructure investment, and the time required to build proper guardrails before anything meaningful reaches production.

Should You Replace Employees with AI Agents or Retrain Them?

One of the more candid moments in the conversation with GeekyAnts conference came when the question of organizational restructuring arose. Kamerkar did not sidestep the obvious tension: yes, agentic tools are being cited in layoff announcements. Yes, companies are replacing headcount with AI infrastructure spend.

His view, offered plainly, was that this framing misses an opportunity. Training developers to work alongside agentic systems, rather than replacing them outright, tends to produce better and faster products. Efficiency gains compound when skilled humans direct and oversee capable systems. They do not compound in the same way when institutional knowledge walks out the door.

This is not a soft, feel-good argument. It is a practical one. Agentic systems fail in unexpected ways. The people who understand your domain, your edge cases, and your failure modes are not easily replaced by a system prompt.

How Do You Deploy Agentic Workflows Without Breaking Things in Production?

Do you need a kill switch?

Both practitioners were consistent on one point that often gets treated as a legal footnote rather than an engineering requirement: human oversight is not optional.

Kamerkar was specific about what this means operationally. Before any agentic workflow reaches production, you need kill switches. You need staged rollouts, starting with a limited production subset rather than a full deployment. You need feedback loops that allow humans to catch and correct unexpected behavior.

Can you ever fully remove humans from the loop?

"You can reduce the human intervention," Kamerkar said. "You cannot neglect the human intervention."

That framing matters. Many teams treat human oversight as a transitional phase, something to be engineered out as the system matures. The more durable view, supported by real deployment experience, is that oversight scales down in volume but never disappears in principle.

Where Should a Company Actually Start Its AI Transformation?

Should you build a custom agent or use what already exists?

Pallavi, whose talk at the same event focused on frontier firms and AI transformation strategy, raised a concern that applies to a large portion of enterprise AI initiatives: organizations are building agents because they feel they need to be building agents, not because they have a clear transformation plan.

Her framing of a more structured approach was useful. It starts with what is already available off the shelf, including low-code and no-code solutions that can be deployed quickly. It distinguishes between use cases that benefit from rapid, lightweight deployment versus those that require more sophisticated, custom-built approaches.

Is low-code really enough for enterprise use cases?

The estimate she cited, that the majority of agents built by 2027 will use low-code or no-code platforms, is worth interrogating rather than accepting at face value. But the underlying point holds: not every AI initiative requires deep custom engineering. Knowing the difference is a strategic advantage, and getting that call wrong in either direction is expensive.

What Happens to Your AI System When Your Data Is a Mess?

Perhaps the most underemphasized point in either conversation came from Pallavi's comments on data architecture. Siloed data does not just slow down AI initiatives. It actively undermines the quality of the intelligence those systems can produce.

Integrated data, she argued, is what allows agents to deliver consistent, trustworthy responses across contexts. And closely tied to that is security, which she positioned not as a compliance checkbox but as a foundational design requirement. Agentic systems, because they operate with greater autonomy and access, introduce new attack surfaces. Security has to be built in from the start, not patched on afterward.

So What Should You Actually Do?

Neither of these practitioners was selling a vision. They were describing constraints and tradeoffs from direct experience.

The practical takeaways are straightforward: start with proof of concept before production, build kill switches before you need them, keep humans in the loop as a design principle rather than a fallback, address data siloes before they become intelligence siloes, and resist the temptation to restructure your organization around AI displacement before you understand what your AI can actually do reliably. That is not a particularly glamorous framework. But it is a more honest one than most of what circulates in this space.