AI Agent Framework Selling to the Head of Platform Engineering — 60-Min Training

The scenario every AE walks into

A rep books a call with the Head of Platform Engineering at a 900-person fintech. The team already has LangChain in the repo — three engineers pulled it in for an internal retrieval prototype eight months ago. Nobody signed anything. There is no contract, no seat count, no procurement record. From the rep's side, this looks like a warm inbound. It is actually the hardest deal shape in the category, because the buyer already has a working answer to "can we do this?" and now only cares about "can we run this on-call at 3am?"

That distinction is the whole sale. Agent frameworks get adopted bottoms-up by developers who grab whatever has the best docs and the fastest hello-world, then get bought top-down by a Platform Engineering leader who has to answer for uptime, spend, and audit trails. The person who adopted it is rarely the person who buys it. Your job in the 60 minutes is to move the conversation from the adopter's frame (does it work?) to the buyer's frame (does it stay working, and what does it cost when it doesn't?).

Three stakeholders sit on this deal and each has a different veto. Platform Engineering owns the runtime, the deployment manifests, and the on-call rotation — they veto on operational surface area. AI Engineering (or whatever the org calls the applied-ML group) owns model selection and prompt quality — they veto on whether the abstraction gets in their way. The CISO veto is silent and late: it shows up in week six as a security questionnaire that stalls the deal a full quarter if you didn't pre-empt it. Reps who single-thread to Platform Engineering win the technical evaluation and lose the calendar.

The scenario generalizes. The same shape shows up in API gateway sales, in service-mesh deals, in CI/CD platform cycles, and in observability tooling — anywhere an open-source component gets adopted for free, runs in production for a while, and then triggers a buying motion when it becomes load-bearing. If you've sold Kubernetes tooling, you already know this dance. The agent-framework version just compresses the timeline, because the underlying model providers keep shipping and the customer's architecture is unstable in a way a service mesh's isn't.

How the 60 minutes actually sequences

The training splits into six blocks with hard time boxes. Blowing the box is the most common failure — reps spend 25 minutes on the "why this category is different" preamble and never get to pilot design, which is the only block that changes deal outcomes.

Block one, five minutes: category framing. Agent frameworks are developer-adopted, then enterprise-bought. Open-source traction is the leading indicator; enterprise revenue lags it by six to eighteen months. The practical implication for the rep is that GitHub stars and Discord activity tell you where the pipeline will be next year, not where the quota is this quarter. Teach reps to check whether the account already has the framework in a repo before the first call — if it does, the discovery script changes.

Block two, fifteen minutes: joint discovery. Seven questions, run with Platform Engineering and the economic buyer in the same frame. Opening: what agent workloads are in production today, not in prototype. Multi-provider posture: are Claude, GPT, Gemini, and open-weight models all in scope, or has the org standardized? Observability: which tracing stack — LangSmith, Langfuse, Arize, or a homegrown OpenTelemetry wrapper? Production reliability: are there max-iteration limits, cost ceilings, audit logging? Use-case scope: research, code generation, customer support, internal ops? Team shape: one team or many? Renewal posture: what's already contracted?

Block three, fifteen minutes: pilot design. Covered in detail below. This is the block reps skip and the block that decides the deal.

Block four, ten minutes: incumbent handling. Four wedges, one sentence each, rehearsed until they're reflexive.

Block five, ten minutes: pricing. Joint with the CFO, never procurement-solo.

Block six, five minutes: renewal trap-sets. Set in month one, not month twelve.

The pre-brief matters more than the script. Send a one-page scorecard 48 hours ahead listing the three numbers you'll measure during the pilot — leave them blank for the customer to fill in. Buyers who arrive with numbers already written have pre-committed to a success definition, and the day-seven conversation becomes arithmetic instead of debate.

The seven-day pilot and the numbers that move it

Production-data trials beat synthetic demos by a wide margin in every enterprise-infrastructure category, and agent frameworks are an extreme case because the failure modes only appear under real load — rate limits, provider timeouts, runaway loops, token spend spikes at 2am. A demo environment cannot surface any of those. Structure the pilot so it does.

Day zero. The customer's platform team installs the integration, not the AE. This is a deliberate friction test: if their team can't get it deployed in a day against their own manifests, you've learned something important about the operational surface area, and you'd rather learn it now than in month four. Configuration maps to their actual environment — their secrets manager, their proxy, their cluster.

Days one through three. The framework runs against a real workload. Pick one with genuine traffic, not a synthetic loop. The AE collects metrics from the native dashboard — token spend per run, p95 latency per step, iteration counts, error rates by provider. Do not ask the customer to instrument this manually; if the framework can't self-report, that's a finding.

Day four, mid-trial scorecard. Walk the Head of Platform Engineering through three numbers tied to the pre-brief. If any are off-target, tune the configuration proactively rather than waiting for the complaint. A rep who shows up on day four having already fixed a problem the buyer hadn't noticed converts a vendor relationship into an operational one.

Days five and six. Fifteen minutes with one individual contributor the Head of Platform Engineering picks. That IC's experience is the deal. They will be asked "is this any good?" in a hallway conversation you'll never see, and their answer is the real evaluation.

Day seven. Joint scorecard with Platform Engineering, the economic buyer, and finance. Pricing proposal same day, while the numbers are warm.

On ranges, be honest about what you actually know. Deal sizes in this category commonly span roughly $30K to $400K ACV, with the low end being single-team seat deals and the high end being multi-team platform agreements with support and SLA attached. Published list pricing exists on most vendor sites — use the vendor's own published numbers in the training rather than a range you invented, and update the deck quarterly, because pricing in this category moves faster than in mature infrastructure. Discount structure typically runs in tiers against multi-year commitments, often with case-study rights traded for a step down in year two and three; get your own company's approved tiers from finance rather than improvising on the call.

Three metrics predict renewal better than anything else, and reps should be tracking them from week one: number of production agents deployed (single digits is fragile, double digits is sticky), percentage of the engineering team with observability dashboards actually open weekly, and whether more than one model provider is live in production. That last one is counterintuitive — a customer running two providers has built the abstraction into their architecture, which makes your framework structurally hard to remove.

Trade-offs the buyer is actually weighing

The Head of Platform Engineering is not comparing your framework to a competitor's framework. They're comparing "adopt a framework" against "write 400 lines of orchestration ourselves and own it." That build option is real, cheap-looking, and frequently wins the first round. Teach reps to argue against it honestly.

The build case is strongest when the agent workflows are simple and few — a handful of tool calls, one provider, one team. It gets weak fast at the boundaries: retries with backoff across providers, structured state persistence, human-in-the-loop pause and resume, distributed tracing across a multi-step chain, and cost attribution per workflow. Every team that builds their own eventually rebuilds those five things badly. That's the argument, and it lands better than feature comparison because the buyer has usually already lived it with some other component.

Among frameworks, the trade-offs are real and reps should be able to state them without spin. Graph-based orchestration frameworks favor explicit state machines — more upfront modeling, better production debuggability, heavier for a prototype. Role-and-crew abstractions optimize for fast composition and read well in a demo, but the implicit control flow gets harder to reason about when something breaks at scale. Type-first frameworks appeal strongly to teams already invested in strict typing and validation, and land poorly where the codebase is loose. Retrieval-oriented frameworks are the right answer when the workload is really document Q&A wearing an agent costume. Microsoft's ecosystem entry carries the usual enterprise gravity: easier procurement, tighter Azure coupling, more friction if the customer is multi-cloud on purpose.

The multi-cloud point deserves emphasis because it's the Platform Engineering pain nobody articulates in discovery. This buyer lives in Kubernetes clusters, service meshes, and CI/CD pipelines. Their actual problem isn't "we need AI" — it's "we need to run these workflows across AWS, GCP, and on-prem without rewriting the agent every time we move it." Provider abstraction is the value proposition. "One agent definition, any runtime" is the phrasing that resonates with a team managing three or more environments, and it's also a defensible claim you can demo rather than assert.

Observability is the second trade-off axis and it's where deals are won quietly. Platform engineers don't buy frameworks; they buy operational guarantees. Reserve ten minutes of the training for the integration story: how traces of agent decision chains land in Datadog or Grafana, how token consumption gets logged per step, how OpenTelemetry spans map onto agent steps, what a health-check endpoint exposes about agent state without leaking the reasoning loop. When the buyer asks "how do I know this is working in production?" — and they will, in some form, in the first twenty minutes — a rep who reaches for a slide has already lost ground to a rep who reaches for a trace.

Security, procurement, and the stalls nobody schedules for

The CISO is a silent stakeholder on every six-figure deal in this category and shows up late by default. Pre-empt it. Build a one-page security map into the training materials covering: where the agent stores state, how secrets are injected (Vault, cloud secrets managers), whether external API calls route through the corporate proxy, what the audit trail captures, SOC 2 posture, and data residency options. Hand it to the Head of Platform Engineering in week one and ask them to forward it to security before the pilot ends. Deals that surface the questionnaire on day three close a quarter faster than deals that surface it on day forty.

Agent-specific security questions are different from standard SaaS questions, and reps get caught flat-footed. Expect: what stops an agent from calling an unapproved external endpoint? How is prompt-injection handled when the agent reads untrusted documents? What's the blast radius if a tool call is compromised? Can we enforce a per-workflow spend ceiling that hard-stops rather than alerts? Is there an approval gate for actions above a threshold? Reps don't need to be security engineers, but they need to know which of these their product answers and which require a solutions engineer on the call.

Procurement is the other predictable stall. Routing pricing through procurement alone reliably slows deals, because procurement optimizes for line-item cost while the value case lives in operational risk reduction that only Platform Engineering and finance can price. Run pricing jointly. When procurement pushes for a solo negotiation, the rep's move is to decline politely and re-invite the buyer and the CFO — framed as "the trade-offs here are architectural, not just commercial, and I don't want to give you a number that's wrong for your footprint."

Renewal gets decided in month one. Four trap-sets to lock at kickoff: a performance SLA written into the agreement with a service credit if the agreed metric slips on a rolling 30-day average; an adoption threshold measured on the native dashboard and reviewed monthly; a footprint-expansion clause so adjacent workloads get covered without a mid-year renegotiation; and a standing 15-minute joint scorecard call with Platform Engineering and the economic buyer. There is no late save in this category — a customer who hasn't opened the dashboard since month three is already churned, they just haven't told you.

Pitfalls that kill these cycles

Single-provider pilots. The most common one. A pilot that only exercises one model provider proves nothing about the framework's core value and leaves the buyer wondering why they need an abstraction layer at all. Insist on two providers live, even if the second one carries trivial traffic.

Pilots without observability wired in. If the trace stack isn't connected, day-four and day-seven conversations become anecdote-trading. Wire tracing on day zero or don't start.

No production guardrails demoed. Max-iteration limits and cost ceilings are the two features that convert a Platform Engineering skeptic. An agent that can loop forever and spend unbounded money is a pager incident waiting to happen, and this buyer has been paged before. Demo the ceiling, then demo it triggering.

Leading with feature lists. The category's shortlist criterion isn't features — it's the metric that gets the buyer in trouble if it slips. Find it in discovery, anchor every demo and pricing conversation to it.

Treating open-source adoption as a closed deal. Free usage in a repo is not pipeline. It's a signal worth acting on, but the buying committee hasn't formed yet, and reps who forecast off GitHub activity build unreliable pipelines.

Single-threading to the technical champion. Wins the evaluation, loses the year-two renewal, because the economic buyer never developed a stake in the outcome.

Overreaching on claims about model behavior. Reps who promise deterministic outputs or guarantee hallucination rates lose credibility permanently with this audience. Platform engineers know the underlying models are probabilistic. Sell the guardrails, the observability, and the operational envelope — not certainty you can't deliver.

Letting the pilot drift past seven days. Two-week pilots become four-week pilots become dead pipeline. The time box creates the urgency; without it the champion's attention gets reallocated to whatever page fired last night.

Related questions

How is this different from selling an LLM API?

API sales anchor on model quality, latency, and token cost. Framework sales anchor on orchestration, state, and operational guarantees. The API buyer is often AI Engineering; the framework buyer is Platform Engineering. Same account, different veto, different discovery script.

Should reps target Platform Engineering or AI Engineering first?

Start with whoever has the production pager. AI Engineering usually adopts first, but Platform Engineering signs and renews. Lead with the adopter for technical credibility, then insist on the joint call before any pilot begins.

What if the account already uses the open-source version for free?

That's the best pipeline signal available and the trickiest cycle. The buying trigger isn't features — it's the first production incident or the first audit request. Ask what would have to break for them to want support.

Does the 60-minute format actually work, or should it be longer?

Sixty minutes forces block discipline. Longer sessions expand the framing preamble and squeeze pilot design, which is the block that changes outcomes. Run 60 minutes and add a separate clinic for security-questionnaire handling.

How does this training transfer to adjacent categories?

Directly. API gateways, service meshes, CI/CD platforms, and observability tooling all share the open-source-adoption-then-enterprise-purchase shape. Swap the discovery questions; the block structure, pilot design, and joint-pricing motion carry over unchanged.

FAQ

How long should the pilot run?

Seven days, with a hard stop. Day zero installs, days one through three run real workloads, day four is a mid-trial scorecard, days five and six get an IC's honest read, day seven is the joint scorecard and pricing conversation. Pilots that stretch past two weeks rarely close — the champion's attention gets pulled to production incidents and the evaluation goes cold.

Who needs to be on the discovery call?

Head of Platform Engineering plus the economic buyer, same frame, pre-briefed 48 hours ahead with a scorecard. AI Engineering should attend if the org has a distinct applied-ML group. The CISO doesn't need to attend but does need the security one-pager before the pilot ends.

What's the right way to handle an incumbent framework?

Four wedges: prove the delta on the metric they measure weekly, show faster time-to-value on real data, price against the actual deployed footprint rather than the incumbent's enterprise list, and give both Platform Engineering and the economic buyer a shared dashboard instead of a custom BI project.

Is open-source traction a reliable pipeline signal?

It's a leading indicator, not a forecast. Repo adoption predicts where enterprise demand shows up six to eighteen months later. Treat it as targeting input, never as committed pipeline — no contract, no seat count, no buying committee means no deal yet.

How much of the training should cover security?

At least ten minutes, plus a standing one-pager. Agent-specific questions — prompt injection, tool-call blast radius, spend ceilings, approval gates for high-impact actions — differ enough from standard SaaS security review that reps get caught unprepared. Knowing which questions need a solutions engineer is enough.

What sales methodology should underpin the training?

MEDDPICC maps cleanly onto this cycle: the metric is the number that gets the buyer in trouble, the economic buyer is the one who signs the renewal, the champion is usually the IC from days five and six, and the decision criteria are production reliability and observability rather than feature parity.

Sources

• https://langchain-ai.github.io/langgraph/
• https://docs.crewai.com/
• https://microsoft.github.io/autogen/
• https://ai.pydantic.dev/
• https://docs.llamaindex.ai/
• https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• https://opentelemetry.io/docs/
• https://kubernetes.io/docs/home/
• https://survey.stackoverflow.co/
• https://www.forcemanagement.com/meddicc

Related on PULSE

• [API Security Selling to the Head of Platform Engineering — 60-Min Training](/knowledge/st400)
• [DevSecOps Tooling Selling to the Head of Platform Engineering — 60-Min Training](/knowledge/st399)
• [LLM API Selling to the Head of AI Engineering — 60-Min Training](/knowledge/st407)
• [AI Code Review Selling to the Director of Platform Engineering — 60-Min Training](/knowledge/st431)
• [AI Eval Platform Selling to the AI Engineering Lead — 60-Min Training](/knowledge/st417)
• [AI Observability Platform Selling to the VP of AI Engineering — 60-Min Training](/knowledge/st409)