When the word "resolved" decides an agent's revenue

Sierra, Bret Taylor’s company, has a clear policy: it gets paid only when its agent completes a task for the customer. Intercom lists Fin at $0.99 per outcome, with no charge per seat or per token.

Yet on Intercom’s own community forum, one customer wrote that the company should stop assuming Fin resolved the issue whenever a human agent replies to the customer after Fin.

Those three details point the same way. When money flows only once something is resolved, the question of what counts as “resolved” decides revenue. The people who answer that question, measure it and push the number up are the engineers who work alongside customers.

If you want to move into an FDE role, this is worth understanding properly. When customers pay per seat, an engineer’s work can end on handover day. When they pay for outcomes, the way an engineer deploys and runs the agent directly affects how much the vendor collects.

“Resolved” is a contract term, not a feeling

Sierra defines outcomes as business events: a resolved support conversation, a saved cancellation, an upsell, a cross-sell. Conversations that go unresolved are mostly free. That sounds fair until someone has to write the code that counts them.

Intercom’s definition shows where the difficulty lies. An outcome can be counted when the customer completes a workflow, but it can also be counted when the customer asks nothing further after Fin’s answer. In other words, silence is treated as resolution. That is an assumption, and every assumption eventually meets a customer who disputes it.

The complaint on Intercom’s forum is a typical example. Picture a specific case: a customer asks about a refund, Fin answers, and then a staff member steps in because Fin’s answer was not enough. The system records a Fin resolution, while the customer’s support team sees itself paying for work its own people did.

Manny Medina pinpointed this ambiguity in a Sequoia analysis. Is the outcome handling time? A customer closing a ticket and then buying more? CSAT? NPS? Each answer leads to a different measurement pipeline, and the choice has to be made during deployment, not left on a sales slide.

Every percentage point of resolution is revenue

An AWS case study on Intercom and Anthropic says Fin reached an average resolution rate of 56% in the first 30 days after deployment. For a vendor that charges per outcome, that figure is no longer just a quality metric. It is a revenue lever.

Take a hypothetical calculation. A customer has 10,000 conversations a month; at 56%, that is 5,600 billable outcomes.

If an engineer finds three categories of questions the agent often gets wrong, fixes the knowledge base and the tool-calling flow, and lifts the rate to 60%, the vendor gains 400 outcomes a month without selling a single new contract.

The calculation also cuts the other way. If the outcome definition is too broad, for instance treating every silent customer as resolved, the dashboard looks good but customer trust falls, as the forum complaint shows.

So a good FDE does not try to raise the number at any cost. The job is to make the number honest first, and only then to raise it.

Sierra also makes clear that the work does not stop at go-live. The company writes that after launch it continues to run focused, directed optimisation efforts to improve the agent’s performance over time. Under outcome-based pricing, revenue from outcomes is what pays for that work.

Sequoia’s three conditions are all FDE work

Sequoia’s analysis of how pricing models mature for agentic AI companies lists the conditions needed before charging for outcomes. One is a clear definition of what success looks like for each customer. The other two are reliable measurement of outcomes and consistent delivery of results.

Note the words “each customer”. A telecoms company might treat retaining subscribers who are about to cancel as the most important outcome, while an e-commerce marketplace cares about how many returns are processed without human help. No single definition works for everyone, so someone has to sit with each customer and agree on theirs.

Reliable measurement is real engineering work too. It means identifying which event in the customer’s system marks a case as done, handling cases where staff step in, and deciding how long a silence must last before it counts. Those decisions belong to someone who understands both the agent’s logs and the customer’s operations.

Putting the old and new pricing models side by side shows how FDE work shifts. The table below is inferred from the facts above; it does not describe any particular company.

Aspect	Seat or token pricing	Outcome-based pricing
Who bears the risk when the agent answers wrongly	Mostly the customer	The vendor, since unresolved cases are mostly not billed
First question to the customer	How many users, which systems to integrate	For this particular customer, what counts as a resolved case
When the engineer’s work ends	Usually at go-live	It does not, because post-launch optimisation is a revenue source
Metric the engineer must defend	Uptime, latency	Resolution rate and the reliability of the counting method
Typical source of disputes	Usage invoices	The outcome definition, for example whether it counts when staff reply after the bot

Why Sierra calls these people agent engineers

Natalie Meurer of Sierra argues that FDEs are best defined by accountability to the customer, rather than by the shape of the role or the type of work involved.

Even so, Sierra deliberately named the role “agent engineer”. The company explains that a title should convey the technical nature of the work, not just dedication to the customer.

The two ideas fit the pricing model. According to ZenML’s summary of a Sierra talk, these engineers’ responsibilities are tied to concrete outcomes such as a completed sale or a resolved customer request. Those are exactly the things that appear on the invoice.

Bret Taylor summed up the attitude required in advice to vendors: come to customers as a partner and help them solve their pressing business problems. Under an outcome model, that is more than a slogan. If the customer’s problem is not solved, the vendor has no revenue.

What to practise if you want this job

The rarest skill here is not prompt writing. It is turning a vague business goal into a measurable definition, then defending that definition before both the customer’s operations team and your own sales team. Developers who have built customer-service systems, CRMs or analytics pipelines already have half the foundation.

When reading job descriptions, look for phrases such as “resolution rate”, “outcome”, “success metrics” and “agent engineer”. When you see them, ask the employer directly whether engineers own the number after go-live or only do the integration.

In the interview, you can also ask how the company decides that a case is resolved, and who is allowed to change that definition.

On a CV, a line such as “built a customer-support chatbot” says almost nothing. Write instead how you defined the metric, which event you measured it with, how you handled exceptions, and how far the number moved.

A candidate who can describe discovering that an old counting method was inflating results, and fixing it, will be remembered longer than one who only shows off a high rate.

Outcome-based pricing forces vendors to share risk with their customers. The engineer who can agree with a customer on what “done” means, and keep that count honest after go-live, will be the person a company finds hardest to replace.