I sat in Cursor Compile London this morning expecting another tour of agent stacks. What I got was more useful: a kill-filter for AI work, and a reminder that a demo is not a system.
Pauline Brunet is VP of Forward Deployed Engineering at Cursor. She has spent about a decade on enterprise AI deployments, and previously built FDE functions at Element AI (now ServiceNow) and C3 AI before joining Cursor in 2026. This morning she opened Compile with AI Deployments at Scale. These are my notes from the room, not a transcript.
Her public talks are the longer cut of the same argument. They were not this morning's session. Start with the AI Engineer World's Fair talk (about 21 minutes, watch on YouTube) and this Latent Space interview. They still rhyme. Scoped work of about six weeks with a named customer team, not open-ended staff-aug. The outcome filter is the same one she used at Compile: revenue up, cost down, risk down.
Most AI programmes I see stall in the same place. The model works in a notebook. Security has questions. Nobody owns the thing after the showcase. Budget evaporates. Brunet's answer was not "use a better model." It was: filter harder, then treat whatever survives like a product.
Three Gates Before You Build
Every idea goes through three gates.
Feasibility. Can you actually build it? The useful point here was tempo. What felt impossible last week can be a few days of work now. Stay close enough to reassess. Call people back when the answer flips.
Data and expertise. Do you have the data? Do you have the people who understand the domain? Tech without both stalls. A claims model with no claims SMEs is a toy.
Economic benefit. Will the organisation fund it? This is the boring gate. It is also the one that gets you cover when security, risk, and procurement show up.
Pick use cases that matter to the organisation. The ones that win budget and sponsorship. Then you have air cover when (not if) you hit blockers.
Platform teams like the first gate. We under-index the other two. If you cannot name the SME and the budget owner, you do not have a use case. You have a lab.
The Hot Role Sits With Users
Brunet called the critical hire a Forward Deployed Engineer. FE in her language, and her job title. Palantir people will recognise the shape. Notable Capital's note on the title is a useful map of why it is everywhere and still fuzzy: product, engineering, and customer in one seat, and last-mile production as the actual work.
These people sit between the system and the people who have to live with it. They do technical discovery. Talk to users. Map the current process. Find where the data actually lives. They learn how the organisation works, not how the org chart says it works. Then they stay with users through the adoption slog.
That last part is the job. Plenty of people distrust a new system because they have done it their way for 25 years. Manufacturing planning and insurance claims came up as examples. You do not talk those users into a chatbot. You walk the change with them.
Who they hire: software engineers who can put systems in production. Data scientists who can run evals and post-training. Domain experts from insurance, financial services, claims. The "good" profile is a builder who is curious, thinks like a product person, and is slightly obsessive about the customer, whether that customer is external or another team down the hall.
I have hired platform engineers on the same instinct. The ones who last will sit with a team through a messy onboarding. The ones who only want to design the control plane do not.
If your AI programme has no FEs, you have a demo factory.
Leave the POC Behind
Do not linger on proofs of concept for weeks. If it is feasible, move into a production-grade system.
Her definition was specific. Production-grade means an owner, CI/CD, traces and logs, a plan for scale, real data access, and users interacting with it to make decisions.
Architecture is the usual cost and latency trade-offs plus company constraints. If you are an AWS shop, you are an AWS shop. Stop pretending otherwise in the POC.
Evals sit here too: golden tasks plus adversarial prompts. Get SMEs in the loop early. Design for repeatability across lines of business, not a one-off that only works for the pilot team.
That is the same bar I use for an internal platform service. If it has no owner and no traces, it is not a service. It is a weekend project that escaped.
Soft Judgement, Hard Rails
The useful split: probabilistic soft judgement from the model, deterministic hard rules in code.
Audit through traces and logs. Prefer deterministic evals where you can. Is there a cart? A refund ID? The right SQL rows? Keep LLM-as-judge sparse. Bound the eval list. Ship, then add. Do not drown in evals.
// Deterministic first. A judge prompt is a last resort.
func evalRefund(got RefundDecision) []string {
var fails []string
if got.RefundID == "" {
fails = append(fails, "missing refund ID")
}
if got.AmountCents <= 0 {
fails = append(fails, "non-positive amount")
}
if !got.InOriginalCurrency {
fails = append(fails, "currency drifted")
}
return fails
}// Deterministic first. A judge prompt is a last resort.
func evalRefund(got RefundDecision) []string {
var fails []string
if got.RefundID == "" {
fails = append(fails, "missing refund ID")
}
if got.AmountCents <= 0 {
fails = append(fails, "non-positive amount")
}
if !got.InOriginalCurrency {
fails = append(fails, "currency drifted")
}
return fails
}Teams treat evals like a completeness theorem. They are a product backlog. A short list you can run in CI beats a cathedral of judges nobody maintains.
If you cannot write a deterministic check, you probably cannot write a useful judge prompt either. Start with the check.
Guardrails Belong in the System
System-level guardrails beat prompt suggestions. Tool allow lists. Schema validation. Least privilege. Short-lived credentials.
The permission model was a Venn diagram: agent permissions intersect user permissions. The agent does not get a god mode because it is "helping." Track violations in traces. Graduate trust. Handle PII at input, in traces, and at output. Keep a human in the loop for high stakes.
I have already argued this as an AI tool gateway. Brunet was making the same point from the product side. Prompts are not a control plane.
Measure Revenue, Cost, or Risk
Brunet collapsed success to three numbers: increase revenue, decrease costs, mitigate risk.
Instrument the value in the application. Start narrow. Scale horizontally, then vertically. Avoid "productivity" as a headline if you cannot show ROI.
This is where a lot of internal AI work dies honestly. Copilot-style time saved is real and still hard to defend in a budget review. If you want sponsorship, pick a use case that moves one of those numbers and measure it where the work happens.
A dashboard that says "hours saved" is a slide. A claims flow that leaks less money is a budget line.
Know What You Actually Own
Competitive advantage, in her framing, comes from upskilling plus selective partners. Protect core IP. Outsource what is not strategic. She used a SpaceX-style partner pitch: you do not hand the whole stack to a vendor and hope the moat survives. In the public interviews, change management often sits with those partners rather than a standing internal army.
She called the remaining pieces an AI factory: talent, data, and compute. Data included the ugly local signals, not just the warehouse. A telco seeing traffic around a Taylor Swift concert was the example. Compute was the owned-cluster story. Colossus came up. Choose partners carefully.
For most of us, "owned Colossus" is not the lesson. The lesson is: know which of talent, data, and compute you actually hold, and stop confusing a partner's demo environment with an advantage you can keep.
Kill More Work Earlier
If a use case cannot name a budget owner and a production owner, I am not starting it. Curiosity is cheap. Sponsorship is the scarce part.
Brunet did not give me a new agent framework. She gave me permission to be less polite about POCs that have no path to an owner.