The pitch is always clean.
Spin up an agent. Give it work. Watch it run. Suddenly the boring stuff disappears, the business gets faster, and the humans move on to higher-value work.
That is the version everybody wants to believe.
Then the agent needs access. Then it hits an edge case. Then it asks for context it should already have. Then it breaks because a tool changed something small. Then it quietly stops being useful because nobody owns the maintenance.
That is the version people do not put in the demo.
I am not anti-agent. I am running this stuff myself. I believe in the direction. But the more I use it, the more obvious this gets: automation is not magic. It is infrastructure.
And infrastructure needs a human harness.
The agent is not the whole system. The human harness around the agent is what makes the system useful.
Key takeaways
- Agents create leverage when someone owns access, context, QA, maintenance, and judgment.
- “Forward deployed engineer” means different things at different companies, especially now.
- The valuable role is not always a pure engineer. It may be a builder, operator, systems thinker, prompt wrangler, integrator, customer translator, or some mix of all of it.
- If you hire for character and curiosity, you can train the tooling. If you hire only for credentials, you may miss the person who can keep the system alive.
The fantasy breaks at maintenance
Dan Shipper said something on Lenny’s Podcast that stuck with me: “Automation is a lie. Every agent needs a human.”
That is the whole argument.
Not because agents are fake. They are not. They can do real work. They can move faster than a person on a lot of tasks. They can handle research, coding, writing, summarizing, planning, routing, and a bunch of operational work that used to chew through hours.
The problem is the word “agent” makes people imagine independence.
Real work is messier than that.
An agent needs access to systems. It needs context about what matters. It needs guardrails. It needs someone to notice when it is confidently wrong, quietly stale, or pointed at the wrong problem.
It needs someone who understands the work well enough to say, “No, not that. Try it this way.”
That is not a small detail.
That is the job.
What FDE means now
Dan called the person maintaining these systems a forward-deployed engineer type. I think that is right, but the term needs some unpacking.
What does forward deployed engineer even mean in June 2026?
Every company seems to have a different definition. Some mean a technical person embedded with customers. Some mean a solutions engineer with more code access. Some mean a product-minded implementation person. Some mean an internal AI operator who keeps agent workflows from falling apart. Some mean “the person who figures out the weird stuff nobody else owns.”
That confusion is not new.
The industry has always struggled with role definitions. Designer, developer, marketer, product manager, solutions architect, consultant, operator: the edges have always been fuzzy. As the web changes, those edges keep moving.
AI just makes the blur impossible to ignore.
The FDE idea matters because it points at a real need: someone who can sit close to the work, understand the tools, understand the people, and translate between them without getting precious about the title.
The boring part of AI is the part that decides whether it works: access, context, maintenance, debugging, and judgment.
There are different flavors of this role
I do not think there is one perfect FDE profile.
There are flavors.
There is the customer-facing FDE: the person who sits with clients, understands their workflows, and turns messy real-world needs into working systems.
There is the internal operations FDE: the person who connects agents to tools, maintains workflows, watches for drift, and keeps the system useful after the demo glow wears off.
There is the AI systems operator: the person who may not write production code all day, but understands enough about prompts, APIs, context, permissions, and review loops to make agent work reliable.
There is the product-minded engineer: the person who can build, but also knows when the problem is not technical.
There is the weird hybrid: part developer, part strategist, part support, part QA, part firefighter, part translator.
That last one is harder to write a job description for.
It is also the one a lot of companies actually need.
The winning pattern is less romantic
Dan also talked about why he changed his mind on personal agents.
The clean theory is that every person gets their own agent. Everyone has a little digital helper working in the background. Nice idea. The problem is that personal agents require personal maintenance.
Most people do not want another system to babysit.
They already have email, Slack, calendars, tasks, clients, kids, jobs, bills, logins, and whatever fire is burning that day. Give them an agent that needs constant tending and they will use it for a week, maybe two, then stop.
The more useful pattern right now is different: one agent or agent system shared across a team, maintained by someone with the right technical and operational profile.
Not necessarily a pure engineer. Not necessarily a pure operator. Someone who can sit between the tool and the business.
Someone who can connect systems, diagnose failure, translate messy requests into executable work, and keep the thing from drifting into uselessness.
I am living the smaller version of this
I see this in my own setup.
I have OpenClaw running in my life and work. It helps. A lot. I can route ideas, create drafts, track work, push things forward, and turn scattered input into useful output faster than I could without it.
But it does not maintain itself.
I still have to shape the system. I still have to decide what matters. I still have to check the work. I still have to make sure the tools have the right context and that the output matches the actual job.
When it works, it feels like leverage.
When it breaks, it feels like another thing I own.
That tension matters.
If an agent saves ten hours but creates six hours of maintenance, maybe it is still worth it. If it saves two hours and creates five hours of cleanup, you built yourself an expensive chore.
That is the calculation people keep skipping.
Do not ask, “Can this be automated?” first. Ask, “Who is going to maintain this when it stops behaving like the demo?”
Character and curiosity beat perfect labels
This is where I think hiring gets interesting.
If every company defines FDE differently, hiring only against a rigid title is going to miss good people.
The better filter is character and curiosity.
Does this person take responsibility when the system gets weird?
Do they keep digging when the first answer does not work?
Can they talk to a customer, read a workflow, understand a tool, and admit when they do not know something?
Can they learn fast without pretending they already know everything?
Can they hold the technical details and the human details at the same time?
That is the profile.
The tools will keep changing. The title will keep changing. The stack will keep changing. The person who is curious enough to learn and grounded enough to own the outcome will keep mattering.
The human role gets sharper
The lazy AI take is that humans disappear.
I do not buy it.
I think the opposite happens in the places where the work matters. The human role gets sharper.
Somebody still has to know what good looks like. Somebody still has to know what the business is trying to do. Somebody still has to decide which mistakes are acceptable and which ones are expensive.
Somebody still has to understand when the agent is producing output but not progress.
That person may not be doing every task manually anymore.
But they are still responsible for the work.
That is why the forward-deployed engineer idea matters. It gives a name to the person holding the system together. The person is not decoration. They are not training wheels.
They are the reason the agent survives contact with real life.
AI agents do not eliminate operators. They expose who the real operator is.
The difference between theater and operations
A lot of companies are going to do AI theater.
They will announce agents. They will demo workflows. They will talk about automation. They will have screenshots, dashboards, internal excitement, and a few impressive examples.
Then the system will get stale.
Nobody will own it. Nobody will tune it. Nobody will notice when the workflow changes. Nobody will want to be the person cleaning up after it.
That is how useful tools become abandoned tools.
The companies that get real value will treat agents like operations, not magic. They will assign ownership. They will decide what the agent is allowed to do. They will decide what requires human review.
They will improve the system over time instead of pretending the first version is the product.
That is slower than the fantasy.
It is also how things actually work.
The question that matters
The question is not whether AI agents are useful.
They are.
The question is whether the maintenance burden is worth the output. The question is whether the person managing the agent understands the work deeply enough to keep it pointed at reality.
The question is whether the system makes the organization better or quietly creates one more thing nobody wants to own.
I am still bullish on agents.
I am also bullish on the humans who can keep them useful.
That is the part people keep trying to skip. It is also the part that decides whether any of this turns into real leverage.
