I spent twenty years doing on-site ERP work, and now I’m packing my bags again to go be an FDE.

Twenty years ago, I was a young guy doing ERP implementations. The project was at the client’s factory, and I’d drop my suitcase in the dormitory and consider myself moved in. Days I’d be buried in procurement, the warehouse, finance; nights I’d be back in the office tweaking configurations until the small hours. One stay would last half a year.

What I did back then, put plainly, came down to one sentence: turning all that messy paper in the client’s factory into numbers the system could recognize.

Twenty years later, I’ve got a new identity. My business card reads “Systems Architecture & Business Analyst,” and I’ve started taking on FDE work again. FDE—Forward Deployed Engineer. The name sounds new, expensive, and impressive. But when I break the job down, I almost laugh—it’s still hauling my bag into the client’s office, still getting tangled up with the business folks, still doing “translation.”

Except this time, what I’m translating has shifted from “paper” to “AI.”

01 Twenty Years Ago, I Turned Paper into Numbers

First, let me describe what factories looked like back then. Purchase orders were handwritten, goods-receipt notes were carbon-copied, warehouse ledgers were recorded stroke by stroke in notebooks, and at month-end, finance would clutch a stack of receipts and reconcile the books. The data was all there—it just lay on paper, in drawers, and in different people’s heads.

The first thing I did was collect. Sheet by sheet, stack by stack. Then came organizing: typing all those messy paper receipts into numbers, one by one, and entering them into the system. After that came mapping—where did this batch of goods come from, when was that payment due, at which step did a document go missing, and how did the business actually flow?

How tedious was it? I had an entire drawer of scratch paper covered in arrows and boxes—all business flows.

And mapping business flows was the real hard part. What runs in a system is never data—it’s rules: who approves, above what amount it gets escalated, how to fix things after a rejection. Nobody had ever written these rules down; they lived in the veterans’ heads and habits. My job was to ask about them, write them down, and translate them into configurations and code the system could execute.

This work was unglamorous and slow, but it couldn’t be skipped. Without someone on-site checking things line by line, ERP is just a pile of licenses sitting in a contract, unsellable.

Without someone on-site, ERP is just a pile of unsellable licenses.

A quick aside. This kind of work—turning paper into numbers, translating business into rules—is essentially translation. Now some people want to tackle it with an engineering approach. AgentSteamer is an enterprise-grade AI agent platform built around “Agent as a Service,” underpinned by a Harness Engineering framework—put simply, a framework for producing, running, and governing agents, managing objects like Agents, Skills, and Workflows under one roof. Its built-in RAG (Retrieval-Augmented Generation) is aimed at exactly this: knowledge bases, document parsing, chunking, embedding, hybrid retrieval, and finally a Reranker layer—find the source first, then talk about the answer.

02 “On-Site Work Is Disappearing”—I’ve Heard This for Over a Decade

In the years since, a saying gradually took hold in the industry: on-site work, that unglamorous grind, belongs in a museum.

The reasoning sounded smooth enough. Look—cloud, SaaS, out-of-the-box. Software became a monthly subscription service, standard features were two clicks away, configurations were edited in a browser. Who’d want to pay big money to have a bunch of consultants camp out for months? Plenty of software companies indeed thrived on standardization and scale replication.

For a few years, phrases like “customization is original sin” and “implementation consultants will eventually be eliminated”—as someone who did implementation, I felt both panicked and stubbornly defensive hearing them.

Then AI arrived.

03 And What Happened? AI Sent Me Back to the Field

AI and ERP took completely opposite paths.

ERP’s flaw is being “too specific”—it comes with a fixed set of processes, and you have to bend your business to fit its shape. AI’s flaw is being “too general”—a model sits there, can write articles, write code, read contracts, but it has no idea what your company actually does.

In other words, the model gives you raw material, not a finished product.

Take a general-purpose large model and ask it to “help me process a return,” and it stares blankly. Because the word “return” means completely different things at Company A and Company B. Is it a quality-issue return or a seven-day no-reason return? Does the returned item go back into inventory or get destroyed? When is the refund issued, and who approves it? These answers aren’t in the model’s parameters—they’re in the air of the client’s meeting room.

So an old playbook got dusted off. Palantir built its early business on exactly these people—they called these engineers Forward Deployed Engineers, sent directly to the client, living alongside them, defining problems together, building prototypes together, going live together. This was once one company’s secret weapon; now, a wave of AI companies in Silicon Valley are hiring similar people in droves. OpenAI, Anthropic—names you’re surely familiar with—have also set up forward-deployed and solutions-landing roles, specifically doing the work of “stuffing models into a specific company’s concrete business.”

Since returning to the field, my days have been pretty varied. Today I’m meeting with the client’s reconciliation team, breaking a pile of muddled accounts into individual rules; tomorrow I’m connecting to an internal database, cleaning up data scattered across Excel files; the day after, I’m building a rough prototype so the business folks can start using it, listening to their complaints, then going back to adjust. Tuning prompts, connecting data, writing integrations, going live, collecting feedback again—rinse and repeat.

FDEs never sell software. Clients can buy software themselves. What they sell is “results that actually run.”

Another change: the people are back, and there’s more running on the field too. Before, you’d deploy one system; now it might be a bunch of agents each doing their own thing—so who assigns the work, and who closes the loop? AgentSteamer has a feature called “Master Council”—let me be clear upfront, this is the platform’s built-in multi-agent collaboration mechanism, not the same thing as any team’s title. Here’s how it runs: the orchestrator first analyzes the task, then distributes work to several masters in the council. Each master runs its own independent workflow and skills, parallelizing where possible, and reports results back when done. Sound familiar? Isn’t this just a reincarnation of our old on-site squad?

04 Twenty Years Apart, I Put the Two Side by Side

The work I do today and the work I did twenty years ago are so similar it gives me the creeps.

Twenty years ago, I faced paper. Twenty years later, I face data—but it’s messy. Client data is scattered across dozens of Excel files, several legacy systems, plus a pile of PDFs and chat logs. Formats differ, definitions differ—a single “customer list” can have three or four versions.

The first thing I do is still collect. Then organize: cleaning, chunking, and labeling all that messy data, shaping it into structured data AI can understand. After that comes mapping—which part of the business does this data correspond to, what exactly does this field mean, and who owns this flow?

The most similar part is the final step. Twenty years ago, after I finished mapping out the business flows, I translated them into system configurations and code. Today, I “feed” them to AI—training AI to understand the business flows. The same phrase, “help me process a return,” has to be taught to understand what it specifically means at your company, which path it follows, and who signs off on it.

Put these two things side by side on a table, and here’s what it looks like:

Dimension	20 Years Ago (I Did ERP)	Today (I Do FDE)
What you face	Messy paper receipts	Messy digital data
First step	Collect and enter one by one	Gather and aggregate bit by bit
Organize into	Digital data a system can recognize	Structured data AI can understand
Map out	Business flows	Business flows
Delivery method	On-site, working hands-on with the business	On-site, working hands-on with the business
Core action	Translation	Translation

The things we face have changed, the tech stack has changed, but the core motions are almost identical: both are on-site, hands-on with the business, sitting side by side with the client, getting your hands dirty. The core action is still the same word—translation.

Taking those vague, contradictory, “you know what I mean” requirements from clients and translating them into a system that a machine can execute and deploy. Machines can’t do this on their own, because machines don’t understand “you know what I mean.” Someone has to be there, someone has to ask the hard questions, someone has to make the call.

Having taken the comparison this far, I want to add one more detail. Twenty years ago, those business rules had to be written into documents one by one, then turned into code one by one. Today, this can be drawn directly. AgentSteamer has built visual workflow orchestration—15 node types, drag and connect; make a mistake and you can undo and redo, and once you’re done it auto-validates and auto-layouts. The business logic in my head looks exactly like what gets drawn out.

Of course, there are differences. The wall in the ERP era was mainly a “people” wall—departments passing the buck, veteran employees refusing to cooperate, the boss changing his mind at the last minute. In the AI era, besides that wall, there’s a new one: the inherent uncertainty of the model itself. It gets confused, it confidently makes things up, and you can’t test it as thoroughly as you would an ERP. So this job now feels more like mentoring a smart but unreliable intern—you have to keep an eye on it, coax it along, and cover for it when it falls.

05　The Stronger the Tech, the Less Idle This “Translator” Gets

So here’s the question: why does this pattern keep repeating?

After twenty years in this game, I’ve figured out one thing—the stronger and more general-purpose the technology, the more it needs people to land it.

The more specialized something is, the closer it is to a finished product—plug it in and it works. The more general-purpose something is, the further it is from a finished product. That gap between “general-purpose” and “actually usable by a specific company” is the space left for people. And no matter how fancy the business model, that gap can’t be filled by anything but people crawling through it, stretch by stretch.

These words, bought with twenty years, I want to share with three kinds of people.

If you’re still working for someone else, don’t rush to turn yourself into a standardized part. Work that can be standardized is being standardized; but work that “requires being on-site, requires grinding it out with people, requires handling the unexpected” is only becoming more valuable. The fact that FDE roles are being snapped up by Silicon Valley says it all: knowing how to write code isn’t rare—people who can land code in someone else’s real business are.

Companies building products, don’t turn your nose up at the grunt work of landing. Everyone loves a good tech story, but what customers pay for is the thing that actually runs. Whether you’re willing to send people and put in the unglamorous effort at that “on-site” is often what determines whether you survive.

And to the clients, don’t buy into the “out-of-the-box” myth either. No matter how good the tool is, your processes are your own. Who’s going to straighten them out, who’s going to sit with you until the system is running—I was asked this question twenty years ago, and I still have to answer it again today.

Think one step further: people grow old, tools iterate, so what about what I’ve accumulated over twenty years? Part of what platforms like AgentSteamer want to do is turn this craftsmanship into individual Skills and Workflows, managed together with Agents, so the next person who walks in with a suitcase doesn’t step into the same pit all over again.

Twenty years ago, I wheeled a suitcase into a client’s factory campus. Today, I walk into a client’s office with a coffee in hand.

The suitcase became a laptop, tweaking configs became tuning models, and the name of the story changed too.

But that chair—the one where you work hands-on at the business front line—I’m still sitting in it, and I figure I’ll be sitting in it for years to come.

Tools will change,
but the people who squat on-site won’t.

What about you—still “suitcase on-site”? Let’s chat in the comments.