Cursor for Knowledge Workers (No Code Required)

Yes. Cursor started as an editor for engineers, but its team now pitches it as a platform for building with AI agents: you get the frontier models plus the harness that turns plain language into work the agent can act on. Cursor's own growth team demos data analysis, meeting recaps and email drafting with zero hand-written code.

The entry point matters. Don't start in the file-and-code editor most screenshots show. Open the Agents window from the toggle in the top right, or File > New Agents Window. That's where the non-coding work lives.

The mental model underneath every recipe below is the same. You are the domain expert. The agent is the execution partner. The two-modes view helps: sometimes you want a one-off answer, sometimes you want a durable tool you keep using.

Drop the data in and ask in plain English. In the workshop, Emily exported an anonymized usage CSV from the Cursor dashboard, then asked "who is the top Cursor user on my team?" The agent read the file and answered, then handled follow-ups like the top model used. Cursor accepts a CSV, an image and your codebase as input in the same flow.

For a real database instead of a one-off export, connect it through an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server and let the agent explore. Emily gave the agent almost no schema, let it think hard and burn tokens to learn the structure through the Databricks MCP, and got back exact account-creation dates. Then she made it repeatable (see the skills section below).

Once you have an answer, visualize it. Canvas, launched recently, lets the agent write React to render a dashboard directly inside the IDE. Emily turned the usage CSV into a live dashboard, then iterated by voice ("match the Cursor dashboard", "add a tooltip"). The decision rule is one-off versus always-on:

Let the agent explore once, then ask it to write a skill. The first run is expensive on purpose: the agent crawls your database schema to learn where the data lives. After it succeeds, prompt "create a skill for how to fetch user data and creation date." Every future run invokes that skill and jumps straight to the right place instead of searching again.

That's the explore-once, codify-as-skill loop: pay the discovery cost a single time, then every repeat is cheap and deterministic. Skills sit alongside rules and sub-agents in Settings, under "rules, skills and sub-agents." They do different jobs:

Connect your notes tool through an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server, then ask for the recap. Emily connected Granola and prompted: a weekly recap of the past 7 days of meeting notes, plus an action-item list of things she promised to do so she doesn't get pinged. The agent listed the meetings, queried the notes and returned the summary in seconds. The same pattern extends to Google Calendar.

1. 1Connect the source (Granola) as an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server.
2. 2Ask for a 7-day recap of meeting notes.
3. 3Ask for an action-item list of what you promised to do.
4. 4Read the summary: external calls, syncs, and items like "create a community-program application form."

MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers are how Cursor reaches your internal knowledge bases. Emily splits personal MCPs (Figma, Granola) from team MCPs (Databricks for the database, Statsig to read every experiment, backend services). Marketplace integrations exist for Slack (fetch context and post messages), Notion (internal docs) and Datadog (alerts). Many are coding-flavored because that's where Cursor began, but product, design, writing and support ones exist too.

Yes, through automations: always-running agents on a schedule or a trigger. Emily turned the one-off recap into a Monday-morning automation by attaching the Granola and Slack connectors inline, authenticating live, and firing a test run. Triggers include a schedule (every week), a GitHub pull request opened, a Slack channel created or a new message in a watched channel. Automations default to memory, so they look at prior runs.

Real examples from inside Cursor: a bug-report triage agent that files to Linear, dedupes, auto-upvotes when many people flag the same issue, and follows up asking for screenshots or repro steps when a report is thin. And a daily agent that Slacks the team "what do you want for dinner?" then creates a DoorDash group order in the food channel.

Email drafting is the most involved recipe. Emily owns the enterprise sales inbox. A webhook listens for every inbound message, triggers a cloud agent, and drafts a tailored reply grounded in the docs and the user table, so it knows whether the sender is an existing customer expanding or a net-new prospect wanting a demo. The cloud agent runs unattended because the API key is injected into it.

Match the model to the task, not to a leaderboard. A model exposes three dials: intelligence (the context window, up to 1M tokens at the max), reasoning effortA model dial (high / medium / low) for how hard the model thinks before responding, set separately from which model and how fast it runs. (high, medium or low), and speed. The speed dial is the one people misread. A faster run costs more but runs the same model on different GPUs. You're paying for hardware, not a smarter brain.

So the routing is simple. A quick lookup against tables you've already wired ("when did I sign up?") is low-effort and low-reasoning, and you want it fast, so Emily reaches for Composer 2Cursor's in-house agentic coding model: frontier-level coding quality at high speed and low cost, built as a software-engineering specialist rather than a general-purpose model. fast, which blends speed with medium intelligence. A production-down database error or a gnarly bug gets a smart, longer-running model like Opus 4.7. Her rule of thumb: Opus is more creative, GPT models are more problem-solving.

Brain-dump your context, plan before building, then test on a few examples. George's thesis: the models are smart, but they don't know how your work gets done. As a knowledge worker you carry years of pattern-matching in your head. The job is to describe the problem, describe what good looks like, let the agent plan, correct it, then let it execute and check the output against your gut.

Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. is the workhorse for this. Start a task there, the agent researches your docs and codebase and writes a step-by-step plan as a Markdown file, and you review it before any work happens. The other modes round it out: agent (the default), multitask (a meta-agent babysitting parallel agents), and ask (read-only, safe for analysis or onboarding when you don't want the agent writing anything).

Voice mode lowers the friction of the context dump. Both presenters use it to talk faster than they type. The bottleneck in good agent work is getting tacit expertise out of your head, and rambling at it by voice gets more of that across than careful typing.

Run a task per agent and keep them in parallel. Emily ran a Canvas dashboard, a long database analysis, a website build and a skill-creation at once. One focus tip: when launching a build, tag the specific file so the agent doesn't "go on a long grind looking through the entire codebase."

Be honest about the edges. The polished demos came from people who eyeball every output and adjust. The agent is a strong first pass, not an autopilot for judgment.

• You still verify. When the ChatGTM team scored leads, they tested the agent's output against experienced reps' gut and adjusted the weights until it matched. The human stays the check on quality and edge cases.
• Automations need a GitHub connection today, even for code-free tasks like reading meeting notes.
• Surfaces aren't equal. The desktop IDE is the fullest experience; agents also run on the web, through Slack, from the CLI and inside JetBrains, but feature coverage varies by surface.
• Tool sprawl is unsolved. Cursor's own honest answer on governing the explosion of internally-built tools: "we're flying the plane as we're building it." Their gate is adoption first, then access controls and data guardrails once a tool proves valuable.

When you do want to share what works, promote it. Rules and skills start local. On Teams you save project-level rules in the codebase so anyone in that repo inherits them. On Enterprise you set them team-wide. Organizations (launching soon) will let admins scope configs per group, with org-wide rules like "when writing SQL, don't allow injections" enforced everywhere.