Forward Deployed Engineering: One Person, One Idea, and an Agentic Workflow

The opportunity: your ideas no longer need a team

Until recently, turning an idea into a finished, published product took a team. A story series needed a writer, an editor, an illustrator, a voice artist, a video editor, and someone to run the website. A data product needed analysts, engineers, a QA team, and operations. The idea was never the expensive part. The team was. If you had the idea and not the payroll, the idea stayed in a notebook. Most ideas did.

That has changed, and the change is practical, not theoretical. AI agents now do the repetitive production work: writing drafts, drawing, recording, cutting, checking, and deploying. What they cannot do is decide what is worth making and whether the result is right. That part stays with the person who had the idea. So today the whole thing takes two people: one with the idea and the judgment, and one who knows how to design, build and run agentic workflows around that person. The second role is the new skill, and it is what DataPhoenix brings.

The economics follow. Work that used to need a hired team now needs one person’s hours and a known, bounded spend per unit of output. The constraint moves from “can I afford to produce this” to “do I have an idea worth producing”. For a company or an individual sitting on a backlog of ideas, data or content that never justified a team, that is a large and immediate opportunity, and the cost of finding out is low.

Here is one engagement where DataPhoenix was the second person. The client owns Travels with Henry, a travel series told by a narrator, with real and researched places, long-form illustrated episodes and spoken narration on the web and YouTube. He had the material, the voice and the ideas, and no way to produce episodes at the rate he could write them. His ask was plain: make it work. Keep my voice. I approve, I don’t produce. Tell me what each episode will cost before I spend it. Keep the narrator and the pictures consistent. Say on every page that AI helped make this.

That is a forward-deployed engineering engagement. We don’t write a recommendation and leave. We come to the client, build inside their operation on their real material, ship, stay while it breaks, and hand it over working. Here is how that went.

The engagement: how a forward-deployed engineer builds an agentic workflow

How the system is put together

A fusion of human judgment, non-deterministic agents and a deterministic CI/CD pipeline. The pipeline’s steps and gates guide the agents to consistent delivery.

Map how the work really runs

The first job is to sit with the client and write down what one episode actually takes, step by step, and where the hours go. For this client: research, a script, narration recorded from the script, a scene list, a picture for each scene, chapter markers, a video cut, and a page on the site. Most of those steps are repetition: the same kind of work, done again, for every episode. A few are judgment: is this script his? Do these pictures look right? Is this ready to go out?

That split is the design. Automation goes where the repetition is. The person stays where the judgment is: the script, the pictures, and the release. Everything in between should run without him.

Build inside the client’s operation and ship the first episode

We built the production line around the client’s own material and his own way of working, not a demo. AI agents research, draft and structure the script. The client reads it and approves it or sends it back. From there the line runs by itself: narration is generated, scenes are described, pictures are drawn from a fixed character reference, chapters are marked, the video is assembled. The client looks at the pictures and approves them, then approves the release and the air time. Nothing between those points waits on a person.

Cost was built in as a gate from the start, not a report at the end. Every paid step quotes its cost before spending. Each episode has a ledger and a hard ceiling. Hitting the ceiling stops the line and asks; lifting it is a recorded decision with a name on it.

The first episodes went out while the line was still rough. That is deliberate. A forward-deployed engineer ships early and fixes on the ground, because the real failures only show up on real episodes.

Stay while it breaks, and turn every break into a check

This is where most of the value was built, and it is the part a recommendation can never give you. The line was tested end to end on real episodes, and every failure it produced became a check: a missed passage in the narration, a drifting voice, a picture that stopped looking like the narrator. Each one was fixed once and then written into the pipeline as a rule or a mechanical test, so the same fault cannot come back unnoticed. The checks that already existed were tuned against the same real output.

It is the same continuous loop that DevOps teams run on software: build, release, observe, learn, feed the lesson back into the pipeline, and release again. The agents stay non-deterministic; the pipeline around them gets stricter with every turn of the loop, and quality ratchets up without anyone having to remember why.

The right tool for the job

No single model or vendor is best at everything. One is better at reasoning and long-form writing, another at generating images, a cloud voice sounds better than an actor at this budget, and for some workloads you do not need a model at all: a library or a piece of open-source software does the job faster, for nothing, and gives the same answer every run. The differences are large enough that putting a job on the wrong tool costs quality and money at the same time.

The clearest argument for the split came from trying the opposite. An early version ran the writer unattended inside the pipeline; it looped on its own revisions and burned a month of credits in an afternoon. Writing moved back into a supervised conversation with one human gate, and the pipeline kept the jobs that benefit from being mechanical.

Cost optimisation: FinOps for AI workloads

How you pay matters as much as what you pick, and there are three ways to pay: a subscription, metered API credits, or your own hardware running local models. For a workload that runs all day in a long editing loop, a subscription is the right shape: the cost is known and the loop can iterate without a meter running. For a workload that is occasional and measurable, like recording narration, metered credits are better: you pay per unit and nothing while idle. And for a workload that must run on every episode without fail, like speech recognition over a forty-minute recording, buying the hardware and running the model locally wins: no bill per run, no data leaving the machine, and fast enough on a GPU that the check actually happens instead of being skipped. A skilled forward-deployed engineer knows which product does which work best, which of the three cost models fits each workload, and when open-source code beats any model at all. That is most of what “optimal” means in a system like this.

One mistake we see often among aspiring AI operators: putting a sustained corporate workload on metered API billing because that is how the tutorials start. For a workload that runs every day, that is rarely the most cost-effective way to pay. A metered API is right for occasional, measurable calls; for an agent that works all day, a subscription seat on the vendor’s business tier costs a known amount per month however hard it runs. And for a check that must run on every unit of output, the right answer is often your own GPU and an open-source model, where the marginal cost of one more run is electricity. Choosing the billing model per workload is ordinary FinOps discipline applied to AI, and it is part of what an engineer embedded with you is for.

Hand over ownership

The engagement is done when the client runs the line without the engineer in the room. He approves at his three gates, every check runs on its own, and the rulebook and the ledger stay with him. The website works the same way: there is no web editor. Publishing an episode means adding it and its details; the index, the numbering and the front page derive themselves. When an episode was added out of order, every later one renumbered itself and nobody edited a page.

What this enables and the value

The client can now do what a small publishing team does, without the team. He publishes at a pace one person could not sustain by hand, knows what an episode will cost before he spends it, and puts every episode through the same checks whether it is the third or the thirtieth. His hours go into the parts only he can do: having the ideas, keeping the voice, and deciding what is good enough to go out. If you are curious about the results, you can watch the episodes here.

The travel blog is one person’s material. The pattern is general: take the idea, the data or the backlog you already have, put automation where the repetition is and people where the judgment is, make every check mechanical, and ship. This is the work DataPhoenix does as a forward-deployed engineer: we come to you, map how your work really runs, build the agentic workflow inside your operation with a human in the loop at every decision that matters, ship early, stay while it breaks, and hand it over working.

Want to learn more? The local models in this story are the same approach we use for clients who cannot send data to a public endpoint, described under private model enablement. The checks and gates are the data-pipeline discipline from from raw to ready, applied to media instead of tables. If you want an engineer embedded in your own workflow, that is our AI consultancy.