MeetextMeetext
Start free

Forward deployed engineering

Forward deployed engineering should scale like software.

It is the least scalable role in enterprise software, and it is growing because AI products are being sold to enterprises faster than anybody can deploy them. The work is largely the same every time. That makes it a software problem.

Who is in the middle

Enterprise software is sold like a product and delivered like a project. Something has to sit between the two.

Traditional
  1. Software vendor
  2. Forward deployed engineer
  3. Enterprise customer

A person in the middle. They do not scale, they are your most expensive engineers, and every customer needs one again.

Meetext direction
  1. Software vendor
  2. Meetext
  3. Enterprise customer

Software in the middle. The repeatable parts run without anybody, and the parts that still need judgement arrive with the context to make it quickly.

The job, broken down

Before arguing about which parts can be automated, it helps to say what the job actually is. Eleven things, in roughly this order, for every customer.

  1. 01Understand requirements
  2. 02Understand the environment
  3. 03Plan the deployment
  4. 04Configure
  5. 05Handle security and admin approval
  6. 06Deploy
  7. 07Validate
  8. 08Diagnose
  9. 09Repair
  10. 10Upgrade
  11. 11Operate

Steps one and two are judgement and will be for a while. Steps four through eleven are the same motions against a different tenant, and they are where the weeks go.

What is software, and what is not

The left column runs today. The right column does not. We keep them apart because the second column is only believable if the first one is accurate.

Software today

Running in the product. This is what a customer can rely on this week.

Deployment packaging
Capabilities frozen into a package per customer.
Entitlements
What this customer bought, enforced at the package.
Authorization lifecycle
OAuth, admin consent, reconnection, revocation.
Security review
A generated artifact with claims and their provenance.
Validation
A real capability executed before anyone is told it works.
Credential management
Per environment, rotated before expiry.
Health
Three layers, watched separately because they disagree.
Incident handling
Fingerprinted, deduplicated, correlated with changes.
Versioning and rollback
Per customer, to packages that actually worked.
Operational history
Append only, replayable, with attribution.

Direction

Not shipping. This is the half of the job that still needs a person, and the half the operational record is being built to take over.

Requirement understanding
Reading what the customer asked for.
Deployment planning
Proposing the sequence, not just recording it.
Configuration generation
Writing the configuration, not collecting it.
Automated diagnosis
Naming the cause, not just the symptom.
Automated remediation
Acting, under approval, and recording why.
Upgrade planning
Deciding who can move to version four, and when.
Autonomous execution
The whole loop, with a human on the approval.

The order matters

You cannot automate diagnosis of a deployment you do not have a record of. Every entry in the right hand column above needs the same thing first: a trustworthy account of what each customer is running, what they approved, what changed, what broke and what fixed it last time.

An agent that can actRests on it

Proposes the fix, having read a record it can cite.

Automated diagnosisRests on it

Recognises this failure because it has seen it across customers.

A trustworthy accountBuilt today

What each customer runs, what they approved, what changed, what broke, and what fixed it last time.

An agent reasoning over a pile of API responses will be confidently wrong. An agent reasoning over an append-only deployment record, with provenance on every inference, can be checked. That is why the entry point is infrastructure and not an assistant.

Questions

What is a forward deployed engineer?
An engineer who works inside a customer's environment to get a product actually running there: understanding their systems, configuring the integration, getting through security review, handling identity and permissions, proving it works and keeping it working. The title varies. Solutions engineer, implementation engineer, customer engineer and post-sales engineer describe substantially the same work.
Why does the role exist at all?
Because enterprise software is sold as a product and delivered as a project. The product is the same for every customer; the environment is different for every customer. Somebody has to close that gap, and today it is a person.
Why does it not scale?
The work is roughly the same each time and roughly as expensive each time, because almost nothing from the first customer is reusable as software. Whatever a first enterprise deployment costs a team in weeks, the tenth tends to cost something similar. Headcount is the only lever, and forward deployed engineers are among the most expensive engineers to hire.
Is Meetext an AI FDE?
Not yet, and we will not claim it before it is true. Meetext is the deployment control plane an AI FDE would have to operate through: the record of what every customer runs, approved, changed, broke and recovered from. The automation is being built on top of that record, and the page says clearly which parts are software today and which are direction.
Does Meetext replace our solutions engineers?
It removes the repeatable work from their week. Understanding a customer's requirements and designing what they should get is judgement. Running the same OAuth flow, the same security questionnaire, the same validation and the same upgrade for the fortieth time is not.
2 environments free

Stop assigning an engineer to every customer.

Connect a source, publish, and send one link. Your next enterprise customer installs itself.

Start freeTalk to us

2 customer environments free, forever. No card required.