When an agent fails in front of a customer, nobody looks at the model. They look at the retry log. The question from the operations side is almost always the same: did the step run twice? That question has nothing to do with prompts or embeddings. It is an idempotency question, the same one I was answering for message queues long before anyone called a workflow agentic.
My titles over that stretch read like a changelog. .NET developer on federal case management software. Co-founder of a small services company, which mostly meant writing code in the morning and chasing invoices in the afternoon. Architect on a telecom platform. Engineering lead on medical imaging software. Then agentic AI work in financial services, where the title on my profile finally caught up with what I was doing every day: forward deployed engineer.
The term came out of Palantir, where engineers were embedded with customers instead of sitting behind a product backlog. For years it was a niche title. Then the AI labs and the companies building on top of them started hiring for it, because they hit the same wall Palantir hit: the model works in the demo and falls over in the customer's actual workflow. Somebody has to sit in that gap and close it with code.
What changed for me was distance. On the federal work I was three layers away from the person using the software. A business analyst wrote the requirement, a lead broke it into tasks, and I built the task. In medical imaging I was closer, close enough that throughput and uptime numbers had names and hospital shifts attached to them. In financial services the distance went close to zero. Whether an agent could be trusted with a step in account onboarding was a conversation I was part of, and the answer depended on things I had built that week.
That closeness changes how you spend a day. Less time writing code from a ticket, more time figuring out what the ticket should have said. Less arguing about frameworks, more arguing about what happens when the downstream system is slow. A release prep agent is maybe two hundred lines of interesting logic and two thousand lines of plumbing: secrets, retries with backoff, an audit trail for every output, a way for a human to see why the agent made the call it made. The customer never sees the two hundred lines. They live inside the two thousand.
This is why I don't buy the argument that software engineering is going away. The parts of the job that AI tools are eating are real. I write fewer boilerplate controllers than I did five years ago, and Copilot and Claude draft a lot of the test scaffolding I used to type by hand. But the parts that decide whether a system holds up have not moved at all. Healthcare taught me that through HL7 and DICOM, where a message format from decades ago still has to be read correctly by the newest device in the building. Backwards compatibility is not a nostalgic skill. It is the reason the new system is allowed to exist.
The cloud did the same thing to the job a decade earlier. Nobody racks servers for an enterprise app anymore, and the engineers who were good at it did not disappear. They became the people who understood why the managed service behaved strangely at 2 a.m. I have shipped across Azure, AWS, and Google Cloud now, sometimes in the same organization in the same quarter, and the skill that transferred was never the console. It was knowing what at-least-once delivery means for your data, and what a timeout does to a workflow that was never designed to be retried.
So the role shifts. Developer became full stack, full stack became architect, architect became forward deployed, and in five years there will be another title that recruiters search for. Each shift moved the work closer to the customer and wrapped it in more context. None of them removed the need to read a stack trace, reason about state, or say no to a design that will page someone at night.
When engineers ask me how to make the move, my answer is less exciting than they hope. Sit with the people who use what you build, even if it is just one afternoon a month. Learn one cloud deeply and two more well enough to read their docs without a translator. Own an outcome end to end at least once, including the part where it breaks in production and you have to explain why to someone who does not care about your architecture diagram.
The most forward deployed code I write these days is rarely a prompt. It is usually an idempotency key, a timeout, or an audit log line, added for a reason that feels like paranoia right up until the first retry fires in production.