FDE at Fieldguide: What does a forward-deployed engineer actually do?

People ask me all the time: what does a forward-deployed engineer (FDE) actually do?

Is it software engineering? Solutions engineering? Sales engineering? Do you need to be technical? At Fieldguide, the answer begins with engineering. The role is deeply technical. Our FDEs design systems, debug complex failures, and ship production software.

But the job starts earlier than a typical engineering ticket and ends well after a pull request. You work directly with some of the biggest audit and advisory firms in the world, help shape the product, and rapidly build and deploy prototypes they can test against real workflows.

Why I wanted to become an FDE

Before joining Fieldguide, all of my experience was in traditional software engineering roles, and I first learned about forward-deployed engineering through Nabeel Qureshi’s essay, “Reflections on Palantir.” What stayed with me was how close the engineers were to the people using what they built.

Problems were not always filtered through layers of abstraction or handed over as perfectly written product specs. Engineers could observe the workflow, hear what was frustrating, and understand why an obvious solution might not work.

That closeness appealed to me for another reason. I want to start a company one day. The FDE role felt like a chance to build the skills a founder needs: finding real problems, earning customer trust, making product trade-offs, and still doing the building. The Fieldguide role was exactly that.

What the work looks like

Today, I work directly with practitioners at audit and advisory firms. We study their workflows, learn how AI and agents fit their audit methodology and processes, and translate those requirements into production systems and agents we build on the Fieldguide platform.

Customer feedback rarely arrives as a clean, structured ticket. We work through the problem together, sketch a possible experience, and build a prototype. Putting working software in front of someone has a way of exposing what you misunderstood.

Feedback also surfaces bugs. We reproduce the bug against the same inputs, inspect logs, trace the failure through the stack, and deploy a fix. Seeing that friction disappear is immensely satisfying.

Other times, the feedback changes the feature itself. That might be the most valuable part of the role. You don't just hear what the customer asked for, you learn why they asked for it.

One of the engineering problems we’re solving

We’re continually expanding the capabilities of our AI agents to support complex audit engagements. One problem I find especially interesting is generating precise, verifiable citations from dense Excel workbooks. In audit and advisory, a plausible answer is not enough. A reviewer needs to trace every conclusion back to the exact evidence that supports it. That requirement turns citation generation into a provenance problem, not just a retrieval problem.

The pipeline first has to parse the workbook’s structure: sheets, headers, formulas, merged cells, and the relationships between values. A critical data point might be one cell among tens of thousands of rows. Its meaning may depend on a distant column header, an adjacent cell, or context on another sheet.

The evidence is not always stored as cell data. Workbooks can contain embedded images, screenshots, and PDFs, so extraction has to work across both structured and unstructured content. The hard part isn’t finding the fact. It’s keeping a pointer back to the workbook, sheet, cells, or embedded asset as that evidence moves through indexing, retrieval, and inference.

The final citation also needs enough surrounding context for a reviewer to validate it quickly. A technically correct cell reference can still be practically useless.

Solving this touches spreadsheet parsing, multimodal extraction, semantic indexing, retrieval, agentic tool orchestration, evaluation, and the interface used to inspect results. It’s a systems problem that goes well beyond prompt engineering.

This is where working directly with practitioners matters. You learn much faster which failures are merely inconvenient and which make an output unusable in an audit.

Who should consider the role

My biggest takeaway is that customer proximity does not make the engineering less challenging. It gives you direct access to hard problems.

You still need to enjoy writing code, digging through system logs, and tackling difficult technical failures. This is not an escape from engineering. But you should also want to learn a customer’s world. The role requires enough humility to admit what you do not understand, ask the next question, and change your mind when the first prototype is wrong.

On any given day, you might discuss audit methodology with a practitioner, sketch an interface with Design, iron out requirements with Product, and trace a bug through the backend stack. That combination is the FDE job.

While I originally came to Fieldguide to grow as an engineer and builder, working here has shown me just how deep and rewarding the forward-deployed engineering path is. Solving mission-critical problems alongside our customers continues to make me a sharper technical leader, and building long-term impact here is one of the most fulfilling engineering challenges I could ask for.

Interested in joining us? See our open positions.

Note: FDEs go through our Software Engineer interview process, apply to any of those roles and express interest in FDE when you meet our team.