A team is unhappy with the code an agent produces and has worked through every model in the picker without much change. Which account of how Cursor assembles an agent explains where the remaining leverage sits?

The principle — An agent in Cursor is three things working together: instructions, meaning the system prompt plus the rules you supply; tools, meaning file editing, codebase search, terminal execution and the rest; and the model that reasons over both. Cursor orchestrates those components for each model it supports, tuning the instructions and the tools specifically for every frontier model.

Why the key is correct — Naming all three components is what changes your behaviour. Two of them are already tuned on your behalf, and the part you genuinely own is the context you add: rules, referenced files, and a clearly stated goal. So when output is poor, the productive move is to fix the instructions feeding the agent rather than to keep cycling the picker.

Why the others are wrong — Treating the agent as the model alone is the belief that causes endless swapping; Cursor supplies its own prompt and tool set, and your rules sit on top of that rather than constituting it. Believing you must assemble all three yourself gets the anatomy right but the ownership wrong, because a newly supported model arrives already fitted out. And a single fixed wrapper shared across every model is exactly what Cursor says it does not ship, which is why identical prompts can land differently.

Remember this — The picker is one component of three, and the other two are where your effort actually lands.

Sources — Cursor's Agent overview documentation.