Forward Deployed Engineer

Take an enterprise prospect from the first technical conversation to a live, adopted deployment: scoping what is genuinely buildable, building the demo, the custom agents, and the skills yourself, and being personally accountable for the first moment the customer's own team sees the product do something real.

Responsibilities:

• Pre-sale, technically. Sit in discovery, work out the minimum viable setup for this prospect, then build and run the demo yourself. You decide what is feasible; nothing enters a proposal without your scoping behind it, and your "no" blocks the line item.
• The demo and the setup, hands-on. Configure the workspace, wire the data sources and connectors, seed the brand knowledge, and get the outputs looking like this customer's brand. Not a spec you hand to someone in an environment you stand up in.
• Custom agents and skills, for the whole life of the account. Most enterprise requirements don't land as a feature request; they land as "our category model isn't yours, " "this claim needs a compliance check; we do differently, " or "this report has to arrive in our format. " You build the agents and skills that close that gap: writing them, wiring them to the customer's sources and connectors, testing the output quality, deploying them into their workspace, and maintaining them as the requirement moves. This runs from the pre-sale demo through onboarding and continues once they're live; it is not a one-time setup task.
• Onboarding through go-live. Run the POC and the training with the customer's day-to-day users, not just the executive buyer. Gather custom requirements directly, and be honest about which are configuration and which need engineering. The second kind gets flagged as roadmap evidence and never committed to a date.
• The requirements trail. Enterprise onboardings run on daily standups where asks arrive informally, one at a time, for weeks. Keeping that legiblewhat was asked, by whom, what we agreed, and what the customer still owes usis a core part of the job, not admin around it.
• The wow moment, as a number. You own the success metric for the journey from pre-sale to go-live. It has to be measurable, falsifiable, and meaningful to the people using the product daily. A dashboard that only the buyer ever opens is a failed deployment.
• Escalations inside your window. A blocked demo, a stalled data-access request, a POC going quiet: yours. Post-launch product issues route to product; you stay involved only to settle what was actually promised.
• This is the seat's actual working surfacewhat an ordinary Tuesday looks like. We run AI-native internally, not as a talking point: the expectation is that you drive these tools yourself rather than asking someone to run them for you.
• Building agents, skills, and demo setups: Claude Code and equivalent agentic dev tools; writing skills; wiring MCP connectors; scripting against our APIs; automating the repetitive parts of your own job. Customer conversations: Clarify call recordings, transcripts, and notes; every discovery, demo, and standup is captured there and is the raw material for scoping. Product and engineering handoff: Linear issues, projects, and milestones, where a requirement goes when it needs engineering rather than configuration. Prototyping an idea before it costs engineering time. A working prototype is often the fastest way to settle a scoping argument. Proving adoption: PostHog is the thing you deployed that is actually being used, by whom, and how often. Comms and documents: Slack (internal, incl. canvases) and Google Workspace. SOWs, requirement trackers, training material, status writeups The knowledge base: A maintained internal wiki of accounts, modules, objections, and past decisionsyou're expected to read it before a call and add to it after.
• What "AI-native" means concretely here. You should be someone who reaches for an agent before doing forty minutes of manual work: pulling a transcript apart into a requirements list, reconciling a customer's tracker against Linear, and turning a discovery call into a configuration plan. Much of the internal tooling around this seat is itself built as skills and scheduled agents; you will use them, and you will be expected to write new ones when you notice the same manual task twice.

Requirements:

• You have carried enterprise customers' end-to-end discovery through live usage in a technical, customer-facing seat (forward deployed engineer, solutions/implementation engineer, technical account, or delivery engineer). Not pure pre-sale, not pure post-sale.
• You build, including with LLMs. Comfortable in Python or an equivalent for real work: pulling and reshaping messy client data, calling APIs, wiring integrations, and standing up a demo environment without waiting on an engineering queue. On top of that, you can build an agent or a skill against a requirement and judge whether its output is actually good, grounding it in the customer's own sources, evaluating quality, and iterating when it's wrong. You will be asked to show something you built. See the stack section above for what we run equivalents for; exact-tool matches aren't required.
• Scoping discipline under commercial pressure. You can say "that isn't what this does, " to a room that wants to hear yes and can tell configuration apart from engineering on the spot.
• You write things down clearly. Requirements, scope, escalation replies, and status. Half of this job is being the reason nobody has to reconstruct what was agreed upon six weeks ago.
• Enterprise sales-cycle literacy: You have worked with security reviews, compliance sign-offs, procurement, and customer-side stakeholders who control data access, and you route around them without over-promising.
• We are not screening for an exact tool list; most of this is learnable in weeks by someone who has done the shape of the job before. What we do need is that you've worked at this altitude: built things against ad-platform and analytics APIs, handled a client's data on their terms, and shipped LLM-backed features you were responsible for the quality of. Read the lists below as "you should recognize most of a column and have real depth in some of it, " not as requirements.

Nice-to-haves:

• Regulated-industry deployments (BFSI, insurance, healthcare) and the compliance-boundary instincts that come with them.
• Real depth in one of the customer-side categories above, paid media APIs, attribution, or martech/CRM integration, rather than passing familiarity with all of them.
• Depth beyond the basics on agent tooling: multi-step/tool-using agents, retrieval design, and structured evaluation of model output rather than eyeballing it.
• Having been the first or only person in a role like this at an earlier-stage company.