~/ emre.cavunt_
Platform-Engineering

Pauline Brunet: AI Deployments at Scale | Compile London

Pauline Brunet session notes: use-case selection, forward deployed engineers, production ownership, evaluations, permissions, and outcomes.

Asking someone to change a process they have used for 25 years is a substantial ask. A working demo does not explain how their day will change, what happens when it gets something wrong, or whether their experience still counts.

Pauline Brunet addressed that work in AI Deployments at Scale, the opening session at Cursor Compile London on 16 September 2026. Her notes on use-case selection, engineering, and governance kept the people who would use the system in view.


Three Gates for a Use Case

  1. Feasibility: can it be built? Revisit rejected ideas as model capabilities change. Something that failed a few weeks ago may now be practical.
  2. Data and expertise: is the data accessible, and are the people who understand the domain involved? Both are needed.
  3. Economic benefit: does the result matter enough for the organisation to fund it? Sponsorship helps unblock security, procurement, and other dependencies.
A use case that cannot pass all three gates does not become a product. It parks.

Forward Deployed Engineers

Brunet described forward deployed engineers learning the existing process, finding the data, and staying with users as the new system enters their work. Someone's reluctance to adopt it can reveal an exception the team has missed or a responsibility the demo never had to carry.

That is why discovery starts with the people doing the job.

The discovery questions included:

  • What does the user do today?
  • Where does the information actually live?
  • Which exceptions require domain expertise?
  • What would the future experience change?
  • Why might someone with 25 years in the job distrust that change?

Manufacturing planning and insurance claims were examples. In a shopping workflow, a subject-matter expert might identify that purchase history sits in an ERP, rather than the system the engineering team first looked at.

The hiring mix included software engineers who can ship production systems, data scientists who understand evaluations and post-training, and domain specialists. Builder, product mindset, and curiosity about the customer were the recurring qualities.

Move Beyond the Proof of Concept

Once feasibility is established, build towards a system with:

  • A named owner.
  • CI/CD, upgrades, traces, and logs.
  • Real data access.
  • Users making decisions with the output.
  • An architecture that accounts for cost, latency, and scale.

Existing company constraints belong in that architecture. An AWS-only organisation is still AWS-only after the demo. A prototype that ignores those constraints leaves the integration work untouched.

Start with a narrow scope, such as auto claims. Extend across lines of business after the first deployment works, then into adjacent use cases.

Golden Tasks and Adversarial Prompts

Define the intended behaviour before assembling the evaluation set.

For a shopping agent, a golden task could check that a size-10 shoe reaches the cart and that the expected order identifier is created. An adversarial task could ask for the shoes for free and check that the system refuses.

Brunet distinguished deterministic checks from model-based judgement:

CheckEvaluation
Correct item and size added to the cartInspect the cart
Refund createdCheck the refund identifier
Correct records returnedCompare the query result
Helpful or considerate responseHuman review or a carefully designed judge

Keep the initial set bounded. Run representative tasks, involve domain experts, ship to a small group, and add cases from observed failures. The session warned against accumulating thousands of hypothetical evaluations before anyone uses the system.

Probabilistic Decisions, Deterministic Rules

Some work calls for judgement; some has an explicit business rule. Put hard thresholds and required conditions in code rather than asking the model to remember them.

Trace the decisions and tool calls so that failures can be investigated. The output alone does not show which data was accessed or which intermediate action failed.

Agent Permissions Intersect User Permissions

An agent helping someone with their salary or holiday allowance must not disclose a colleague's salary merely because its own credentials can access that record.

The agent does not get a god mode. Only the intersection is allowed.

The controls discussed included tool allow lists, schema validation, short-lived credentials, and least privilege. An order task may need an order identifier without needing card details or the user's entire purchase history.

Sensitive data needs handling throughout the flow:

  • Input: retrieve only what the task requires.
  • Traces: redact sensitive information.
  • Output: check what will be sent to the destination.

Track unauthorised tool calls, excessive data retrieval, and leaks. Start with supervised actions and expand permissions as the workflow proves reliable. Brunet's personal example was researching scuba-diving shops: draft messages first, review outbound messages next, and reduce supervision only after checking the results.

Revenue, Cost, and Risk

The three outcome categories were increased revenue, reduced cost, and reduced risk.

If a metric cannot reach one of these three, it is a slide, not a budget line.

Connect intermediate metrics to those outcomes. Better customer satisfaction may reduce churn. Avoided stock-outs may preserve sales. Time saved needs a measured connection to the work being funded.

Build outcome tracking into the application. The inventory example was a system reporting the demand protected by preventing a stock-out, rather than relying on a separate presentation to argue its value.

Partners and Core IP

The closing discussion covered talent, data, compute, and partner selection. Keep strategic knowledge and core IP under deliberate ownership. Use partners where they add capacity or expertise, and include upskilling the internal team in the work.

One data example was a telco using local activity around a large concert to anticipate pressure on its network. Useful signals can sit outside the usual warehouse datasets.

The session also included vendor claims about X data and Colossus capacity. Those figures are not independently verified here.