Cursor for Sales Engineers and Field Engineers

To build custom demos without waiting on an engineer. In the workshop presenter's experience at Airtable, a custom demo used to mean pinging an engineer and waiting a week or two, so most calls got a pre-baked template instead of what the prospect pictured.

Before Cursor, the presenter said, Airtable's SEs built demos in a no-code app builder with about a dozen preset components. Once every SE had a license, demos went from pre-baked templates to bespoke TypeScript shipped to the demo environment. That opened up financial reporting and dashboards the preset components could never cover, and SEs who could vibe code fit custom demos into the normal cadence of calls.

Cursor's own field engineering, technical account management and GTM teams also build and maintain internal tools with it, according to the presenter. This guide covers all three jobs: demos, RFP answers and internal apps.

Start from a blank editor and let the agent fill it. The presenter opens a new window and a new project named for the scenario, such as a COBOL repo that a financial-services prospect wants refactored. The prompt then describes the environment, why it is set up that way, and the workflow it should support. In the presenter's experience, that replaces days of wiring dependencies by hand with a runnable repo in minutes.

Don't let the agent build straight into the blank repo. The presenter speaks a long, slightly messy explanation into the prompt, then switches to Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition.. Plan mode researches the codebase, asks clarifying questions and writes a plan you can edit before anything is built. In the demo, the questions covered the refactor target (Java with Spring?), the compliance context and the industry. You can also add later demo beats to the plan, such as seeded security vulnerabilities, so a "scan for vulnerabilities" step has something to find.

1. 1Open a blank project named for the scenario (cobol-se-demo).
2. 2Speak or paste a long prompt that describes the environment, why it's built this way and the workflow to demonstrate. In the same prompt, ask the agent to write the demo narrative: the beats and the exact prompts.
3. 3Run Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. with a reasoning model, and answer its clarifying questions.
4. 4Add later demo beats to the plan, such as seeded vulnerabilities for a security scan.
5. 5Switch to a fast code model to build the plan and fill the repo.

Keep two copies of the same scenario, as the presenter does. One sits behind the curtain with the demo narrative: plain-language beats ("here's what we're looking at, here's what we're going to do") plus the exact prompts to run. The other is cleaned up, with no Markdown narrative and no prompt references, and that is the one you share on screen.

During the call, the presenter pastes each prompt in live, so the audience never sees prompts being read from the repo. Because the agent wrote the narrative in the first prompt, the script is ready as soon as the repo is.

Two moves carry the presenter's legacy-modernization demos. The first is an analysis prompt aimed at tribal knowledge. The people who built or maintained a legacy COBOL or Java codebase have often left, so its dependencies are hard to see, and one prompt produces a full breakdown.

The second move turns that analysis into a picture, and the presenter uses it in almost every session. Ask the agent to "build me an architecture diagram written in Mermaid and saved to a Markdown file." It scans the repo broadly, and you preview the result inside Cursor with ⌘+⇧+V. Markdown preview renders the diagram, and your generated demo narrative, as a clear visual breakdown. The presenter uses it to show a buyer that Cursor can trace the dependencies in a complex or legacy codebase.

Connect Cursor to your product's real repositories, if your version-control access allows it, and ask them questions in plain English. The code is the most current documentation you can get, and in the presenter's view this is the SE use case that pays off most. The presenter keeps that project open all day, even during calls.

Use Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition. for this. Cursor's help center calls Ask a read-only mode, in which the agent answers questions and explores code but makes no edits. The presenter described it more strictly, as a mode that blocks writing code, generating code and making tool calls. Either way, Ask suits two SE jobs: answering specific RFP and security questions, and teaching yourself unfamiliar tech before a demo.

Decide between deep reasoning and fast execution first. The presenter plans with a slower, smarter model, then builds with one made to generate code quickly. Cursor's help center names current options for both. Grok 4.7Cursor and SpaceXAI's current lead Cursor model, in the weekly pool at $2 per million input tokens and $6 per million output, with a 256k context window and a 500k variant; above 256k input tokens it bills at 2x the standard rate. Press Enter for the full definition., Cursor's flagship, is built for the hardest, longest-running tasks, and Claude Opus and GPT-5.6 Sol handle complex, multi-step tasks well. Composer 2.5The current Composer release, better at long-running tasks and at judging when a job needs a light touch versus deep work. Press Enter for the full definition., Cursor's fast and cost-efficient model, is built for interactive coding.

Free and Plus include only Cursor's own models, so Claude Opus and GPT-5.6 Sol need Premium or higher, a Teams or Enterprise plan, or legacy Pro, Pro+ or Ultra. The lineup changes often, so check the current model guide before a demo, and test the candidates on the demo itself instead of assuming the largest model wins.

Use it as the default if your plan includes it, and switch it off when a demo needs a specific model's traits. That is how the presenter works, with Auto as the daily driver. Plus and legacy Start don't include Auto, and individual plans that do have it get Cost mode only. On Teams and Enterprise, you pick Cost, Balance or Intelligence, and Cursor Router chooses the model for Balance and Intelligence requests, which bill at the routed model's list price.

On Enterprise, an admin has to turn the router on first. Cost mode is where Cursor's pages disagree. The models and pricing docs and the available-models help page count a Cost request as a Cursor-model request against your included pool. The Cursor Router help page says all Auto modes bill at the routed model's list price, so check with your admin before a long demo.

Open a new chat for each task, so each context window holds one topic. Every model has a finite context window, measured in tokens, and the context ring next to your prompt input shows how full it is. When one chat fills with unrelated topics, the presenter warned, the result is context rotThe quality drop that happens when one chat accumulates unrelated tasks or tangents, burying the signal the model needs in a haystack of stale context. Press Enter for the full definition..

Context rot also lowers the model's understanding, the presenter said, because it creates a needle-in-a-haystack problem: with unrelated topics mixed together, the model can't tell what you're trying to accomplish.

Treat each chat as a task-by-task agent, as the presenter does. Build the foundational architecture in one chat, then open new chats for the landing page and for each feature. In the presenter's words: "Stay modular and stay lightweight." A fresh chat starts without the earlier history, which helps, and switching tasks is a natural moment to switch models too.

You can also @-mention the relevant files in your prompt. According to the presenter, that skips the step where the agent works out which files it needs, so it uses context more efficiently than when it scans everything.

Yes, with a project rule that you apply manually. Besides team rules and your own user rules, you can write a project rule with one directive, such as "keep it simple" or a strict code-review instruction, and set its type to Apply Manually. It then applies only in chats where you @-mention it, so untagged agents don't inherit it.

That way one agent becomes a code reviewer, another a planner and another a minimalist. The presenter uses this on calls to show agent behavior that follows instructions. The table lists the three scopes the presenter described.

They build them with the agent and commit them to a shared monorepo. According to the presenter, Cursor's field engineering, TAM, GTM and product teams keep their internal tools in one called FieldSphere. It holds a trial tracker, usage and scoping calculators, a feedback aggregator over Gong call transcripts and a feature-request tracker. The presenter also described a council and a team culture that push new SEs and TAMs to pick a project, even a small dashboard or data aggregator, and keep it maintained.

In the presenter's account, one heavily used example is a usage calculator. Give it an account name or a team ID, and it breaks down how that account uses Cursor by token and by model. GTM uses that breakdown to forecast usage. It runs as a tab inside Salesforce, prefiltered to the relevant account or opportunity, and the team built it, maintains it and adds requested features in Cursor.

1. 1Build it locally with the agent: import a CSV snapshot and render it on localhost to answer your own question.
2. 2Host it, for example on Vercel, the moment a colleague asks "can you send me a link?"
3. 3Wire in live data through webhooks or a proxy query connection to your data warehouse, instead of stale CSV imports.