6 min read

Hello World - Starting a New Chapter

After 15 years of building software that millions depend on, I still get that knot in my stomach before shipping. Here's why I'm writing about it now.

aiengineeringintroduction

It was 2 a.m. in Abu Dhabi and I was staring at a deployment dashboard, watching error rates climb on a system that — if everything went right — the entire country would depend on by morning.

That was the Alhosn app. The UAE's COVID-19 platform. Over a million people would eventually download it, scan it at every mall entrance, every airport gate, every restaurant host stand. But in that moment, at 2 a.m., it was just me and a Slack channel full of engineers who hadn't slept properly in weeks — trying to figure out why a specific edge case in the vaccination certificate flow was throwing silent failures.

We fixed it. Obviously. You don't get to write a blog post about a system that didn't ship.

But here's what I never expected: that feeling — the knot-in-your-stomach, something-is-about-to-break feeling — it never goes away. Fifteen years of building software and I still get it. I got it shipping TAMM, Abu Dhabi Government's unified services platform that climbed to number one in the App Store's Business category. I got it last month deploying a multi-agent research system for a government client. I'll probably get it tomorrow.

And I think that's the thing nobody talks about.

The gap between the demo and the deployment#

There's a version of AI engineering that lives on Twitter — clean diagrams, impressive benchmarks, "just plug in an API key and go." I love that version. I learn from it constantly. But it's a sketch on a napkin. The real work — the work I've spent the last several years doing — is what happens between the napkin and the production system that processes ten thousand requests without hallucinating a medical dosage or misrouting a government service request.

That gap is where I live. It's also where most of the interesting problems are.

I build enterprise AI solutions — multi-agent systems, voice agents, LLM applications — for organizations where "move fast and break things" isn't an option because the things you'd break are people's actual lives. Healthcare systems. Government platforms. Financial infrastructure. The kind of software where a hallucinated answer isn't embarrassing — it's dangerous.

This puts me in a strange position. I'm genuinely excited about what large language models can do. I've seen them compress months of research into hours. I've watched a well-orchestrated agent system handle tasks that would have required a team of five just two years ago. And also — I've seen a voice agent confidently give a patient the wrong clinic address. I've watched a retrieval pipeline surface a document from 2019 as if it were current policy.

Both things are true at the same time. That's the tension I want to write about.

Why now — and why here#

I've been building software since before "AI engineering" was a job title anyone recognized. Started in the trenches of mobile and web development, moved through government digital transformation — TAMM alone taught me more about building for scale than any architecture textbook — and eventually found myself at the intersection of AI and enterprise systems, which is where everything interesting is converging right now.

For years, I shared what I learned the way most engineers do — in team retrospectives, in architecture reviews, in late-night Slack threads that maybe three people read. But something shifted recently. The AI space is moving so fast that the gap between what practitioners actually know and what's being published is widening. Not because people are gatekeeping — because everyone is too busy building to write it down.

I want to write it down.

Not the polished, everything-worked-perfectly version. The real version. The one where the multi-agent system you designed looks elegant on a whiteboard but falls apart the moment Agent B gets a malformed response from Agent A and enters an infinite retry loop at 3 a.m. on a Thursday. The one where your vector database returns semantically similar results that are factually contradictory and you spend two days figuring out why your chunking strategy is the problem.

That's the blog I want to read. So that's the blog I'm going to write.

What you'll find here#

I'm planning to go deep on a few things.

Multi-agent systems in production. Not the tutorial version — the "here's what happens when you orchestrate six specialized agents and one of them starts confidently generating nonsense that the others treat as gospel" version. I've been building these systems with LangGraph and there are patterns emerging that I haven't seen documented anywhere. Some of them are counterintuitive. Some of them I'm still not sure about.

Voice agents that actually work. I've deployed conversational AI in healthcare and government contexts — environments where "sorry, I didn't understand that" isn't just a UX problem, it's a trust problem. The difference between a voice agent demo and a voice agent that elderly patients will actually use is enormous, and most of it has nothing to do with the model.

Architecture for the real world. How do you design AI systems that serve millions of users when the underlying models change every six months? How do you build evaluation frameworks when "correct" is subjective? How do you convince a government client that an AI system is ready for production when you yourself aren't entirely sure? I don't have all the answers — but I have hard-won opinions and a growing collection of battle scars.

The stuff that doesn't work. This might be the most valuable part. I've made enough mistakes in production to fill a book — and the mistakes are usually more instructive than the successes. I plan to be honest about them.

An invitation, not a conclusion#

I thought about ending this post with a tidy summary — the kind where you list your credentials and say something about "the future of AI." But that felt like the wrong note to start on.

Here's what I actually believe: we're in a moment where the people building these systems know things that matter — messy, practical, hard-to-articulate things — and there aren't enough spaces where that knowledge gets shared openly. Not as thought leadership. Not as marketing for a framework. Just as one engineer saying to another, here's what I tried, here's what happened, here's what I'd do differently.

That's what I want this to be.

I'm Sangam. I'm based in Dubai. I've been building software for fifteen years and AI systems for the last several — and I'm still figuring out half of it in real time. If that sounds like your kind of conversation, I think we're going to get along.

Find me on LinkedIn or GitHub — I'd genuinely love to hear what problems you're wrestling with.

The next post is about multi-agent systems in production. It gets weird. Stay tuned.