AI Agents in Production: The Hardest Part Isn't the Model

Viansh — Fri, 17 Apr 2026 18:08:36 +0000

Everyone's talking about AI Agents. But most teams I speak to are still figuring out where to even begin — and the ones that have started are hitting walls they didn't anticipate.

I've spent the last several months building and debugging agentic workflows in production. Here's the honest truth I wish someone had told me earlier.

The hardest part isn't the model

When engineers first hear "AI Agents," the mental model is usually: pick a powerful LLM, give it some tools, and let it run. The model does the heavy lifting, right?

Wrong.

The hardest part is the glue — the orchestration layer, the state management, the retry logic, the error handling, and the observability. The LLM is the easy part. Everything around it is where production systems live or die.

Where agents actually fail

Here's what I've seen break in real systems:

Infinite loops — An agent hits a wall, retries the same tool call, gets the same error, and loops indefinitely. Without explicit loop detection or max-step limits, you're burning tokens and time with zero output.

Silent failures — The agent "succeeds" but the result is wrong. No exception was raised, no alert was fired. Without structured output validation and logging, you won't even know.

Context blowout — Long-running agents accumulate context fast. Past a certain point, the model starts ignoring early instructions or losing track of the task entirely. Managing what goes in and out of context is an active engineering problem, not an afterthought.

Three things that actually worked

After many painful debugging sessions, here's what moved the needle for us:

1. Explicit state machines
Stop treating agents as black boxes. Model your agent as a state machine — define valid states, transitions, and terminal conditions. When something breaks, you know exactly where it broke.

2. Human-in-the-loop checkpoints
Not every action needs to be autonomous. For irreversible or high-stakes actions (sending emails, writing to databases, calling external APIs), add a confirmation step. The 2-second pause is worth it.

3. Observability from day one
Log every tool call, every LLM response, every state transition. Use something like LangSmith, Weights & Biases, or even just structured JSON logs. If you can't replay what your agent did and why, you can't debug it — and you can't improve it.

Where we actually are

Let's be real: most "agentic" systems in production today are sophisticated prompt chains with some tool-use bolted on. That's not a criticism — it's genuinely useful. But it's not the autonomous reasoning loop the demos suggest.

And that's fine. Start simple. Build reliability before you build autonomy. A deterministic, debuggable agent that does one thing well is infinitely more valuable than a flashy agent that occasionally does everything and frequently does nothing.

What's next

The field is moving fast — multi-agent coordination, memory architectures, and better tool-use APIs are all maturing. But the foundational engineering discipline of building reliable systems? That never changes.

Master the boring stuff first. The exciting stuff will follow.

What's the biggest challenge you've hit building agents in production? I'd love to hear what's broken for your team — drop it in the comments.

I Switched Jobs Twice in One Year. Here's What Nobody Tells You About Growing Fast in Tech

Viansh — Sat, 07 Mar 2026 17:41:36 +0000

# I Switched Jobs Twice in One Year. Here's What Nobody Tells You About Growing Fast in Tech.

Posted by Jwala Chaubey · 6 min read

Let me be upfront: this isn't a feel-good story about "following your passion."

This is about being honest with yourself, making uncomfortable moves, and refusing to let your salary stay behind while your skills grow forward.

Where It Started — TCS

Like a lot of engineers in India, my first job was at a big IT services company. TCS. The brand name felt safe. The onboarding was smooth. The work was... fine.

But "fine" is a dangerous word in tech.

I was doing Java development. Decent projects, decent team. But I started noticing something early: the gap between what I was learning and what the market was actually paying for was growing. Cloud. DevOps. Serverless. Infrastructure as Code. These were the words showing up everywhere — in job posts, in LinkedIn DMs, in the salary discussions I was quietly having with people outside my company.

Inside TCS, I was comfortable. And comfort, I realized, was the trap.

The First Jump — Infosys

I moved to Infosys. From the outside, it looked lateral — another big services company. People questioned it.

But I had a specific reason: the project I was moving into gave me real exposure to cloud-native work. AWS. Event-driven architectures. Things that were actually moving.

Was the jump scary? Yes. Did the salary bump justify it alone? Honestly, partly. But the bigger thing was the signal I was sending to myself — that I wasn't going to wait for a company to hand me growth. I was going to engineer it.

At Infosys, I got my hands dirty. Lambda functions. CI/CD pipelines. Infrastructure that actually mattered. The work was harder and the pace was faster. That was the point.

The Second Jump — Cognizant (Where I Am Now)

Within a year, I moved again. This time to Cognizant's Cloud, Infrastructure & Security team as an Infra Technology Specialist.

Two switches in roughly a year. By then I had people telling me it "looks unstable" on a resume. I heard it. I disagreed.

Here's what actually happened: my compensation grew significantly with each move. My skills compounded. And my title shifted from "developer" to "specialist" — which is a different conversation entirely when you're sitting across from a hiring manager.

At Cognizant, I work with Terraform, TypeScript, AWS Lambda, Step Functions, Amazon Q Developer — building scalable, serverless systems. Real architecture. Real production impact.

What I Actually Learned

1. Loyalty to a company that isn't growing you is just fear with a nicer name.

Nobody tells you this early enough. Your employer is not your family. They have targets. You have a career. Both things can be true without malice — but don't confuse one for the other.

2. The market rewards demonstrated skills, not tenure.

I didn't get paid more because I waited longer. I got paid more because I could show real, hands-on work with technologies that companies actually need. Build things. Break things. Put them on GitHub. Write about them. That portfolio compounds faster than years on a resume.

3. Every jump should buy you something — skills, money, or both.

I never moved just for a title. Each switch had a clear trade: more cloud exposure, better pay, stronger stack. If you can't articulate what a move buys you, it's probably not the right move yet.

4. Discomfort is directional if you point it right.

Switching companies is uncomfortable. Learning Terraform from scratch while shipping production code is uncomfortable. Preparing for interviews while holding a full-time job is uncomfortable. But discomfort that builds something is completely different from discomfort that just grinds you down. Learn to tell the difference.

Where I'm Headed

I'm not done moving.

Right now I'm actively building toward MLOps and Platform Engineering — because that's where the technical depth and the compensation are both heading. AI/ML infrastructure, Kubeflow, MLflow, scalable model pipelines. That's the next frontier and I intend to be there before it becomes crowded.

I'm also starting to write. Not because I've figured everything out — but because putting things down forces clarity, and clarity is rare in this industry.

If You're Sitting in That "Fine" Job Right Now

Audit yourself. Not your company — yourself.

Are your skills growing? Is your compensation reflecting your growth? Do you know what you want to be in 2 years and does your current role get you there?

If the answers make you uncomfortable, that's information.

Use it.

I'm Viansh — Infra Tech Specialist at Cognizant, focused on AWS, Terraform, DevOps, and moving into MLOps. If this resonated, follow along — I'll be writing more about cloud architecture, career moves, and building in public.

Connect with me on LinkedIn | GitHub

Tags: career devops aws beginners career-switch

DEV Community: Viansh