Cursor in Teams for Subagents

The situation

Counter-thesis: this is not just another Cursor integration. Cursor in Teams changes the intake path for cursor subagents, rules, and review habits.

The wrong path: I believed the agent work should stay inside the IDE while chat stayed separate. I tried that split, and here is what happened: the request lived in one place, the context in another, and the handoff became the failure point.

Diagnosis: this is the classic context-splitting trap. When the prompt, repo, and review surface are separated, the workflow gets brittle.

The actual thesis: Cursor in Teams works best when Teams is the intake layer and Cursor is the execution layer.

The changelog says Cursor can be mentioned in any Teams channel to delegate a task to a cloud agent or pull information back into Teams. It also says Cursor picks the right repository and model from the prompt and recent agent activity, reads the whole thread for context, and can create a PR for review. For Cursor for engineering teams, that changes how cursor custom agents, cursor skills, and review checks get used.

If you are building a Cursor workshop or cursor AI coding training path, this belongs next to Cursor subagents and skills. The question is less “can the agent do the task?” and more “what should the team define before the task leaves chat?”

Walkthrough

Failure mode one: the request is too vague to route well. If you shipped AI code, you have hit this: Teams chat rewards shorthand, but agents need structure when work crosses repos or depends on recent activity.

Named fix: The Teams Intake Note. Write one line that names the repo, the outcome, and the risk before you mention @Cursor.

# Teams Intake Note
- Repo: web-app
- Outcome: add a failing test for checkout tax rounding
- Risk: do not touch payment provider config
- Review: open a PR only; no merge

That gives the agent a cleaner routing signal and starts the review conversation earlier. That is tip one.

Failure mode two: the agent does useful work, but nobody can tell what it was allowed to touch. If you shipped AI code, you have hit this too: delegation is easy to start and hard to govern unless you pair it with repo rules.

Named fix: The Scoped Rule Boundary. Put the local constraint in a .cursor/rules/*.mdc file and keep it narrow enough that a reviewer can read it fast.

---
description: Checkout tests only
globs:
  - src/checkout/**
  - tests/checkout/**
apply: auto
---

- Do not modify payment gateway credentials.
- Prefer test-first changes.
- If the task touches pricing logic, stop and ask for review.

That makes the work easier to audit and gives the PR a clearer shape. That is tip two.

Failure mode three: the agent solves the task, but the team still does not trust the handoff. If you shipped AI code, you have hit this: chat-native delegation can hide the chain of evidence.

Named fix: The PR Proof Check. Review three things: the task matches the intake note, the changed files match the scoped rule, and the PR description explains what the agent did not touch.

[ ] Task matches the Teams Intake Note
[ ] Changed files stay inside the scoped rule
[ ] PR explains exclusions and follow-up work
[ ] Tests or validation are visible

That keeps review focused on alignment instead of reconstruction. That is tip three.

Failure mode four: the team treats Teams as a side channel instead of a durable workflow. If you shipped AI code, you have hit this pattern: the first few tasks work, then the process turns into one-off prompts and private habits.

Named fix: The Shared Delegation Pattern. Use one repeatable path: Teams intake, Cursor execution, PR review, and a short post-merge note in the repo’s team docs or AGENTS.md boundary.

That gives different contributors the same path without re-teaching the process. That is tip four.

Failure mode five: the team forgets that chat context is not repository truth. If you shipped AI code, you have hit this as well: the thread can be rich, but it is still temporary.

Named fix: The Thread-to-Repo Rule. Anything that matters after the task ends should live in a rule, a skill, or a repo convention, not only in chat.

That keeps decisions out of scrollback. That is tip five.

Synthesis: Teams is the intake desk, not the archive. Cursor is the execution layer, not the memory. The thesis is simple enough to repeat in Slack: Teams receives the work, Cursor performs the work, and the repo records the truth.

Tradeoffs and limits

Cursor in Teams is useful when the task is bounded, reviewable, and tied to a real repository. It is less useful for ambiguous work that needs live pair programming, and it does not remove the need for scoped rules, repo conventions, or human review.

I would also be careful about over-trusting automatic repo and model selection. The changelog says Cursor picks based on prompt and recent agent activity, but teams should still verify that the chosen scope matches the request before they rely on the result. The thesis still holds, but only if the intake note and the scoped rule are real.

A practical note from our methodology: in the Review step, treat every Teams-delegated task as untrusted until the PR proof check passes.

Further reading

• https://cursor.com/changelog
• https://cursor.com/docs
• https://cursor.com/docs/rules
• https://cursor.com/docs/agent
• https://github.com/anthropics/skills/blob/main/README.md
• https://github.com/openai/skills/blob/main/README.md

Where to go next

If you are rolling this out, start with one repo, one scoped .cursor/rules/*.mdc file, and one PR review checklist, then expand from there. For the broader training path, see Cursor subagents and skills.