Cursor for Knowledge Workers (No Code Required)

Yes. Cursor started as an editor for engineers, and in Cursor's knowledge-work workshop, presenters from its growth and GTM team pitched it as a platform for building with AI agents. They described it as frontier models plus the harness that turns plain language into work an agent can act on. They showed data analysis, meeting recaps and email drafting without any hand-written code.

Start in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. rather than the file-and-code editor. Cursor's docs describe the Agents Window as its agent-first interface, and you open it from the editor with ⌘+⇧+P, then Open Agents Window. In the workshop, the presenter switched to it with the toggle in the top right and did all the non-coding work there.

Every recipe below rests on the same split, as the presenters described it: you are the domain expert, and the agent is the execution partner. Some tasks need a one-off answer, and others need a durable tool you keep using.

Drop the data in and ask in plain English. In the workshop, Emily, one of the two presenters, exported an anonymized usage CSV from the Cursor dashboard and asked the agent who the top Cursor user on her team was. The agent read the file, answered, then handled follow-ups such as which model was used most. She also showed that Cursor accepts a CSV, an image and your codebase as input in the same flow.

For a live 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. Press Enter for the full definition. server and let the agent explore. Emily gave the agent almost no schema and let it spend tokens learning the structure through the Databricks MCP, and it returned exact account-creation dates. She then made the lookup repeatable with a skill, as the next section shows.

To see the answer as a chart, ask Cursor for a canvas, which opens beside the chat as an interactive view. Emily turned the usage CSV into a live dashboard this way, then refined it with follow-ups such as "match the Cursor dashboard" and "add a tooltip". Her rule for choosing between a canvas and a real website was one-off versus always-on:

Let the agent explore once, then ask it to write a skill. The first run is expensive, because the agent has to crawl your database schema to learn where the data lives. When the agent had worked out the structure, Emily prompted "create a skill for how to fetch user data and creation date." After that, runs that use the skill go straight to the right place instead of searching again.

You pay the discovery cost once, and each repeat costs less. Skills sit alongside rules under Customize in the sidebar. Rules, skills and subagents each do a different job in Cursor:

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. Press Enter for the full definition. server, then ask for the recap. Emily connected Granola and asked for a weekly recap of the past 7 days of meeting notes, plus a list of the things she had promised to do, so she wouldn't get pinged about them. The agent listed the meetings, queried the notes and returned the summary in seconds. She said the same pattern works with 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. Press Enter for the full definition. server.
2. 2Ask for a 7-day recap of your meeting notes.
3. 3Ask for an action-item list of what you promised to do.
4. 4Read the summary. Emily's recap covered external calls and syncs, with action items such as "create a community-program application form."

Emily called MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers a good way to connect Cursor to internal knowledge bases. She keeps personal ones (Figma, Granola) separate from team ones (Databricks for the database, Statsig to read every experiment, and backend services). She also pointed to Marketplace integrations for Slack, which can fetch context and post messages, Notion for internal docs and Datadog for alerts. Many integrations lean toward coding, but she said product, design, writing and support ones exist too.

Yes, with Automations, which run cloud agents in the background on a schedule or when an event fires. Emily turned the one-off recap into a scheduled automation: she attached the Granola and Slack connectors, signed in to both on the spot and fired a test run. Triggers include a schedule (every Monday, say), a pull request opened on GitHub, a new public Slack channel and a new message in a connected channel. Memories are on by default, so an automation can read and write notes across its runs.

The presenters described two automations that run at Cursor. One triages bug reports: it files them to Linear, removes duplicates, upvotes an issue when many people flag it and asks for screenshots or repro steps when a report is thin. The other asks the team on Slack "what do you want for dinner?" each day, then creates a DoorDash group order in the food channel.

Email drafting was the most involved recipe. Emily owns the enterprise sales inbox, where a webhook listens for every inbound message and triggers a cloud agent. The agent drafts a reply from the docs and the user table, so the draft reflects whether the sender is an existing customer who wants to expand or a new prospect who wants a demo. It runs unattended because its API key is injected into it.

Match the model to the task. Emily described three dials on a model: intelligence (she chose the 1M-token context window as the maximum), 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. Press Enter for the full definition. (high, medium or low) and speed. She said a faster run costs more but runs the same model on different GPUs, so you pay for hardware, not a smarter model. Plus runs Cursor's models at fixed settings, with Fast off and effort at medium.

Emily routed tasks by those dials. For a quick lookup against tables she had already wired, such as "when did I sign up?", she used Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. fast, which she said blends speed with medium intelligence. Cursor's current ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. model is 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., which also comes in a Fast version. For a production-down database error or a hard bug, she would pick a smarter, longer-running model such as Opus 4.7, a third-party model that Free and Plus don't include. In her experience, Opus is a bit more creative and the GPT models lean a bit more toward problem-solving.

Dump your context into the agent and let it plan before it builds. George, the workshop's other presenter, argues that the models are smart but don't know how your work gets done. Describe the problem and what good output looks like, correct the agent's plan, then check a few outputs against your own judgment.

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. suits this work: the agent researches your codebase, asks clarifying questions and writes a Markdown plan you can edit before anything is built. Cursor's help lists three other modes: Agent for most tasks, Ask for read-only questions, and Debug for tricky bugs that need runtime evidence. The presenters called Ask safe for analysis and onboarding, and they showed a multitask mode, a meta-agent that watches parallel agents, which the help doesn't list.

To dump context by voice, click the microphone icon in the chat input and speak. Both presenters use voice because they talk faster than they type, and George sees getting tacit expertise out of your head as the bottleneck in agent work.

Give each task its own agent, and run them in parallel. Emily ran a canvas dashboard, a long database analysis, a website build and a skill creation at once. When she started the website build, she tagged the specific file so the agent wouldn't "go on a long grind looking through the entire codebase."

Don't expect the agent to replace your judgment. The polished demos came from people who checked every output and adjusted it, so treat the agent's work as a first pass.

• You still verify. When George's team built ChatGTM, an internal tool for sales reps, they tested the agent's lead scores against experienced reps' judgment and adjusted the weights.
• Automations and cloud agents need a plan that includes them, and Free and Plus don't.
• Surfaces differ. The presenters called the desktop IDE the most common surface, and agents also run on the web, in Slack, from the CLI and inside JetBrains. Check what a surface supports before you rely on it.
• Governing the tools people build is still an open problem, by the presenters' account. Asked how Cursor manages them, they said "we're flying the plane as we're building it": adoption comes first, and access controls and data guardrails follow once a tool proves its value.

To share what works, move it out of your own setup. Project rules saved in a repo are shared with everyone who works in it. On Team and Enterprise plans, admins can also create Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition. in the dashboard that apply across all of the team's repositories. The presenters' example of an organization-wide rule was "when writing SQL, don't allow injections." They described Organizations as launching soon, and Cursor has since made them generally available to Enterprise customers, with groups that get their own model access, spend limits and agent permissions.