Tag: AI agent development

For the last two years, enterprise AI has mostly been sold as a feature: a chatbot in the corner of a screen, a summarize button, an assistant that answers one question at a time. On September 11, 2026, Salesforce made a different kind of pitch. It introduced seven named Agentforce agents, each built for a specific job, and described one of them as able to pursue a goal across weeks instead of a single conversation.

The naming is not a cosmetic detail. It signals a shift in how vendors want buyers to think about AI: less as software you configure and more as labour you deploy. This piece follows on from our earlier look at MCP and A2A governance, and it covers what Salesforce announced, what its customer results do and do not show, and what a buyer should ask before treating an AI agent like an employee.

What Salesforce announced

According to Salesforce’s announcement and coverage from Unite.AI and Startup Fortune, the seven agents and their jobs are as follows.

Casey is a help agent for customer service, working across voice, SMS, WhatsApp, and web chat. Paige handles IT and HR requests for employees, including through Slack and employee portals. Carter is a shopper agent that helps with product discovery, comparison, and checkout. Marshall is a supply chain agent that orchestrates back-office processes with audit trails. Piper handles inbound lead generation, engaging and qualifying leads for B2B sales. Fin is a customer agent that resolves complex customer-experience workflows. Hunter is an outbound sales agent that manages a pipeline from research through outreach.

Availability differs. Six of the seven, Casey, Paige, Carter, Marshall, Piper, and Fin, are generally available now. Hunter is in pilot, with general availability planned for November 2026.

Hunter is also the agent that uses a new long-horizon runtime. Salesforce describes it as built on three capabilities: memory, which preserves context across sessions; durable execution, which keeps a plan running over time; and dynamic steering, which adapts behavior based on feedback from users. The point of the runtime is that an agent can work toward a goal across days and weeks, instead of finishing one task and forgetting it. Hunter is the first agent to run on it.

The announcement included other platform pieces. Multi-Agent Orchestration, which routes work across coordinated teams of agents, is generally available. Agentforce Coworker, an employee-facing agent with AI Skills, and Agent Optimizer, a tool for refining agents, are scheduled for general availability in October 2026. Salesforce also introduced Agent Script, an open-source language for defining agent behavior with deterministic rules, which matters because it gives builders a way to fix certain steps in place instead of leaving everything to the model. None of the coverage we reviewed gave pricing.

How long the memory lasts

Some headlines around this launch describe agents with months of memory. The sources we reviewed do not support that. Salesforce’s own description is days and weeks. That is still a meaningful change, but the difference matters when a buyer is estimating how long an agent can hold onto a plan.

The customer results, and why to read them carefully

Salesforce published six customer results with the launch. All of them are reported by Salesforce, and none of the coverage we reviewed included independent verification or a definition of how each metric was measured.

Engine reported that 50% of chat inquiries are fully resolved by its help agent, which it calls Eva. Perk reported that Hunter built 60% of its sales pipeline. Autism Queensland reported that Paige resolves 70% of administrative requests. Hibbett reported that an agent handles 90% of core shopper journeys, after going live in six weeks. Asana reported 4x conversation volume driven by Piper. Anthropic reported that Fin resolves 79% of conversations autonomously.

These are useful as directional evidence. They are not benchmarks, and four things are missing that any buyer should ask about.

The first is definitions. Resolved could mean that a customer got a correct answer, or it could mean that the conversation ended without escalation. Those are very different outcomes. The second is baselines. Fifty percent resolved means more or less depending on what was resolved before the agent arrived. The third is scope. A figure for one team, one region, or one channel may not transfer to your business. The fourth is selection. Vendors highlight their strongest results, so a set of six published numbers says little about the distribution of outcomes across all customers.

There is one specific point on Perk. Hunter is still in pilot, so that result necessarily comes from early use, not a generally available product. Startup Fortune’s coverage made the same overall point, describing the results as early evidence and not a guarantee.

The governance layer was announced separately

Coverage of this launch sometimes lumps the AI Control Plane in with the seven agents. It was announced separately, one day earlier, on September 10, alongside what Salesforce calls a Trusted Enterprise AI Harness.

According to AI Weekly, the control plane provides routing, lineage, and cost and observability across both Salesforce and third-party AI, and it is positioned as a governance layer over a multi-vendor agent landscape. An analyst blog covering Dreamforce described it as a central registry of agents, MCP servers, and APIs with automatic discovery and a single gateway for model, MCP, and agent calls, and said it is designed to cover agents beyond Salesforce’s own.

Two cautions apply. AI Weekly reported that most capabilities are live while the rest are scheduled for fiscal year 2028, so buyers should not assume everything described is available today. And the same analyst blog noted that the control plane was initially previewed in 2025, which suggests some of it is an evolution of earlier work and not new this month. Neither source gave a general availability date for the full set.

A registry of agents, MCP servers, and APIs is exactly the kind of inventory that AI governance requires. It is also a reminder that governance products from a platform vendor cover that vendor’s view of the world first, so a company running agents from several suppliers should test how well the third-party coverage actually works.

Why names and job titles matter

Giving an agent a name and a role is a marketing decision, and it is also a framing decision. A named agent with a job title invites the same expectations we place on a person in that role: that it owns an outcome, that someone is accountable for it, and that it can be evaluated like a hire.

That framing has real benefits. It gives buyers a clearer mental model than a generic assistant. It pushes vendors to tie agents to measurable jobs such as resolving support tickets or qualifying leads, which is what sensible AI automation projects do anyway. And it makes it easier for a business to ask what work is being replaced, augmented, or created.

It also creates a risk. Names encourage people to trust an agent in the way they would trust a colleague, and an agent is not a colleague. It has no professional judgment, no personal accountability, and no understanding of context beyond what it has been given. Startup Fortune raised the question directly: “which decisions stay with people, which ones the agent takes alone?” That question should be answered in writing before an agent goes live, not discovered after an error.

Why weeks-long agents change the risk

The long-horizon runtime deserves separate attention, because it changes what can go wrong. A chatbot that answers one question and forgets it produces contained errors. An agent that holds a plan for weeks, remembers past interactions, and adjusts its behavior can compound a mistake, act on stale information, or continue a course of action after circumstances have changed.

Memory also raises data questions. What does the agent retain, for how long, and who can see or delete it? Durable execution raises control questions. How do you pause or stop an agent that is mid-plan, and how do you review what it did while nobody was watching? Dynamic steering raises accountability questions. When feedback changes an agent’s behavior, who approved that change?

These are design questions for anyone working on AI agent development, and they are procurement questions for anyone buying agents. The sensible default for a weeks-long agent is tighter limits: narrow permissions, explicit approval for irreversible actions, clear stop conditions, and a complete log of what it decided and why.

What to ask before you deploy a job-ready agent

Whether you buy from Salesforce or another vendor, the same questions apply.

What exactly is the job, and how is success measured? Define the metric before the pilot, including what counts as resolved or qualified.

What does the agent decide alone, and what needs a person? Write the boundary down and test it.

What data does it read, retain, and write? Confirm retention periods and deletion.

How do you audit and stop it? This is the core of AI governance for agents. Ask to see the logs and the pause controls.

How does it behave when it is wrong? Test escalation paths and error handling with real edge cases.

What is the fallback? Keep a documented way to run the process without the agent.

How does it fit with the rest of your agents? If you run agents from more than one vendor, check whether the governance layer really covers them.

Where this leaves you

The confirmed facts are these. Salesforce launched seven named agents on September 11, 2026. Six are generally available and Hunter is in pilot until a planned November release. Hunter runs on a new runtime designed to pursue goals over days and weeks. A separate governance announcement the day before introduced an AI Control Plane, with parts still to roll out. All customer results are Salesforce-reported and lack published definitions.

The broader shift is real. Enterprise AI is increasingly sold as a defined piece of work with a name attached. That makes it easier to evaluate, provided you insist on definitions, baselines, and limits. Businesses exploring AI automation, AI agent development, or generative AI development can borrow the useful part of the framing, which is to scope each agent to a specific job, and skip the risky part, which is treating it like a person.

Frequently Asked Questions

1. What are the seven Agentforce agents?
Answer: Casey (customer service), Paige (IT and HR), Carter (shopping), Marshall (supply chain), Piper (inbound lead generation), Fin (customer experience workflows), and Hunter (outbound sales). Salesforce announced them on September 11, 2026.

2. Which agents are available now?
Answer: Casey, Paige, Carter, Marshall, Piper, and Fin are generally available. Hunter is in pilot, with general availability planned for November 2026.

3. What is the long-horizon runtime?
Answer: It is a new runtime that lets an agent pursue goals across days and weeks using memory, durable execution, and dynamic steering. Hunter is the first agent to use it.

4. Are Salesforce’s customer results independent?
Answer: No. All six results are reported by Salesforce, and the coverage reviewed did not define how metrics such as resolved were measured. Treat them as directional evidence, not benchmarks.

5. What is the AI Control Plane?
Answer: It is a governance layer announced separately on September 10, 2026 that provides routing, lineage, cost and observability across Salesforce and third-party AI. Some capabilities are live and the rest are scheduled for fiscal year 2028.

6. How should a business evaluate an AI agent before deploying it?
Answer: Define the job and success metric, set the boundary between agent and human decisions, confirm data retention, check audit logs and stop controls, and test failure handling.

If you want to know which of your workflows are ready for AI agents and where the risks sit, that is exactly what we look at in a free AI Readiness Audit.

Most companies have a policy on which software employees can install. Far fewer have one for AI agents, the programs that can read files, call tools, and take actions on a person’s behalf. That gap is now the subject of a commercial product category, and the clearest sign came on September 1, 2026, when CrowdStrike launched Falcon Guardian at its Fal.Con conference in Las Vegas.

The launch is worth reading closely, not because a single product settles anything, but because of what it assumes: that unapproved AI agents are already running on company machines and that the endpoint is where they need to be caught. Two statistics have been attached to the story, and they need careful handling. Here is what is confirmed, what the numbers actually show, and what the practical lesson is for AI security and AI governance teams.

What CrowdStrike announced

According to CrowdStrike’s press release and coverage from SiliconANGLE, Security Boulevard, and BizTech, Falcon Guardian does four things.

First, it discovers known and shadow AI agents across Windows and macOS endpoints. Second, it blocks agents that are not on an approved list from running on managed systems. Third, it ties agent behavior to endpoint telemetry, linking user prompts to identities, the tools an agent invoked, and the resulting system changes. Fourth, it detects attacks aimed at agents and agents that misbehave, and it estimates the blast radius when an incident occurs.

CrowdStrike also announced supporting pieces: an AI Gateway for centralized control of enterprise AI traffic, a managed service called Falcon Complete for Guardian, a threat hunting service called Falcon Adversary OverWatch for Guardian, and integration with its Next-Gen SIEM.

Availability is uneven, and that matters for anyone planning around it. SiliconANGLE reported that the core Guardian features and the managed threat hunting service are available now, while the AI Gateway is pre-beta and expected to reach general availability next quarter, and Falcon Complete for Guardian is due later this quarter. CrowdStrike’s press release did not list pricing.

CEO George Kurtz framed the pitch in one line: AI has not changed the attack, it has changed its speed. The company’s argument is that the endpoint, which it has long positioned as the control point for stopping attacks, is also the place where agents execute.

What the sources do not say is equally useful. They name Windows and macOS as the supported endpoints and say nothing about other environments. They do not list which agent tools or frameworks Guardian recognizes. And none of the coverage we reviewed includes an independent evaluation of how well it works. Treat this as a vendor announcement, not a tested result.

What shadow AI means in practice

The term is borrowed from shadow IT, where employees adopt tools without approval from the technology or security team. Shadow AI is the same pattern applied to AI: assistants, coding agents, browser extensions, and automation tools that staff install or connect on their own.

It happens for understandable reasons. The tools are free or cheap, they are useful on day one, and many can be installed in minutes without any request to IT. A developer adds a coding agent. A marketer connects an assistant to a shared drive. A finance analyst runs an automation that reads email. Each decision looks small. Together they create a set of programs with real access to company data that nobody has inventoried.

Agents raise the stakes over ordinary shadow IT because they act, not just store. A file-sharing app that nobody approved holds data. An agent that nobody approved can read that data, send it somewhere, and run commands, often with the permissions of the person who installed it.

The two numbers, and what they do and do not show

Two statistics have been attached to this story. They come from different sources and they measure different things.

The first is 89%. CrowdStrike’s 2026 Global Threat Report, published on February 24, 2026, states that AI-enabled adversaries increased their activity by 89%, measured year over year from 2024 to 2025. That is a statement about attackers using AI, not about employees installing unapproved agents. It is also about activity, which is broader than the attacks some summaries describe. The same report says adversaries exploited legitimate generative AI tools at more than 90 organizations by injecting malicious prompts to steal credentials and cryptocurrency. That second figure is closer to the shadow AI concern, because it shows AI tools themselves being used as an attack path.

The 89% is real, and it comes from the company selling the product. It supports the argument that the threat is accelerating. It does not show how many unapproved agents are running inside any given company.

The second number is 17,800. AIR Security, a startup that announced $50 million in funding on September 3, 2026, reported finding more than 17,800 public AI add-ons, with 6.7 million installations in total, that rely on untrusted external sources for their instructions. The company also reported finding AI skills that impersonate Anthropic and OpenAI and are designed to get past security reviews and run arbitrary code. Coverage describes add-ons as skills, plugins, and MCP servers, which are the extensions that give agents new abilities.

Two cautions apply. AIR Security sells a firewall for AI agents, so it has a commercial interest in the finding, and it is a separate company from CrowdStrike. The coverage we reviewed also did not include a published methodology or a link to a full report, so the count cannot be independently checked. That does not make it wrong. It means it should be read as a vendor’s research and used to understand the type of risk, not as a measured baseline.

Together the two figures make a reasonable case for taking the issue seriously. Attackers are using AI more, and the supply chain of extensions that agents rely on is largely unvetted. Neither figure tells you your own exposure.

Why this is a governance problem first

The most important detail in the product description is easy to miss. Guardian blocks agents that are not on an approved list. That means someone has to create the list.

A detection tool can tell you which agents are running. It cannot decide which ones should be. That decision is AI governance: defining which agents are allowed, for which tasks, with which permissions, approved by whom, and reviewed how often. Without it, a discovery tool produces an inventory and a set of alerts with no policy to measure them against.

Kurtz described the aim as turning policy into protection. The order of that phrase is the point. Policy comes first. Organizations that buy enforcement tooling before they write the policy tend to discover that the hardest questions were never technical. Who can approve a new agent? What counts as sensitive data an agent may not touch? Which extensions and MCP servers are acceptable? What happens when a team needs something that is not on the list?

What a practical response looks like

You do not need to buy a product to start. The same steps apply whether you use an endpoint platform, a gateway, or manual review.

Find out what is already running. Ask every team which AI assistants, agents, and extensions they use, and check managed devices where you have the tooling to do so. Expect the first answer to be incomplete.

Write an approved list and a request path. If the only answer to a new tool is no, people will route around you. Make it easy to ask, and give a fast answer.

Vet the extension supply chain. Skills, plugins, and MCP servers can pull in instructions from outside your control. Review where each one loads content from, what permissions it requests, and who publishes it. Be cautious with anything that carries a familiar brand name but comes from an unverified publisher.

Apply least privilege. This is basic AI security hygiene, and it applies to agents as much as to people. Give agents the narrowest access they need. An agent that only has to read one folder should not be able to reach the whole drive or run commands on the machine.

Log what agents do. Record which identity started an agent, which tools it invoked, and what it changed. If something goes wrong, that record is what lets you estimate the blast radius.

Plan the response. Decide in advance who can disable an agent, revoke its credentials, and notify affected teams.

Evaluate vendors on evidence. When assessing any agent security product, ask which agents and platforms it covers, how discovery works, what it does when it finds an unapproved agent, and what independent testing exists.

For companies that build agents for customers or for internal use, this also shapes design. Teams working on AI agent development should build in identity, scoped permissions, and audit logging from the beginning, so that the agents they ship are ones a security team can actually govern.

Where this leaves you

Falcon Guardian is a confirmed product launch with a defined feature set, some parts available now and others still to come. The 89% figure is CrowdStrike’s own finding about attacker activity. The 17,800 figure is a separate vendor’s research with no published methodology in the coverage we reviewed. None of these prove that your company has a shadow AI problem today.

What they do show is that the industry now treats unapproved agents as an AI security category worth building products for, and that the endpoint is one place to look. The durable part of the story is the AI governance work underneath: an inventory, an approved list, vetted extensions, limited permissions, and a record of what agents do. Companies that have those in place can evaluate any tool from a position of strength. Companies that do not will be buying software to solve a policy gap.

Frequently Asked Questions

1. What is Falcon Guardian?
Answer:Falcon Guardian is CrowdStrike’s AI agent security product, launched on September 1, 2026 at Fal.Con. It discovers known and shadow AI agents on Windows and macOS endpoints, blocks agents that are not approved, and links agent behavior to endpoint telemetry.

2. What is shadow AI?
Answer: Shadow AI refers to AI tools and agents that employees use or install without approval from IT or security. Because agents can read data and take actions, they carry more risk than ordinary unapproved apps.

3. Where does the 89% figure come from?
Answer: It comes from CrowdStrike’s 2026 Global Threat Report, published February 24, 2026, which says AI-enabled adversaries increased their activity by 89% year over year. It measures attacker activity, not unapproved agents inside companies.

4. Is the 17,800 add-ons figure from CrowdStrike?
Answer: No. It comes from AIR Security, a separate startup that sells an AI agent firewall. It reported more than 17,800 public add-ons with 6.7 million installations relying on untrusted instruction sources. The coverage reviewed did not include a published methodology.

5. Do I need a product like Falcon Guardian?
Answer: Not necessarily. Start with an inventory of the agents in use, an approved list, and a request process. A tool can enforce that policy, but it cannot write it for you.

6. What should an AI governance policy for agents include?
Answer: It should define who can approve agents, which data they may access, which extensions and MCP servers are acceptable, what permissions they receive, how their actions are logged, and who can shut them down.

If you want to know which AI agents and tools your teams are already relying on, and where the governance gaps are, that is exactly what we look at in a free AI Readiness Audit.

Our earlier piece on MCP and A2A governance looked at the open standards that decide how agents connect to tools and to each other. This one looks at the layer underneath those standards, which is the model itself, and at a recent event that shows how quickly access to that layer can change for reasons that have nothing to do with your product.

On August 28, 2026, OpenAI announced that it will end Cursor’s access to its models on November 12. The immediate story is about two companies and an acquisition. The lasting story is about every business that has built a workflow on top of someone else’s model. Here is what is confirmed, what is disputed, and what a sensible response looks like.

What is confirmed

The sequence is short. SpaceX acquired Anysphere, the company behind the Cursor coding editor, in an all-stock deal reported at $60 billion, which closed on August 14, 2026. Two weeks later, on August 28, OpenAI published a post explaining its decision to end Cursor’s access to OpenAI models, with November 12, 2026 as the date.

OpenAI’s stated reason is trust. It said it cannot be confident that SpaceX will use its technology within OpenAI’s terms of service, and it pointed to a history of contract disputes involving Elon Musk’s companies, including, in OpenAI’s account, xAI’s violation of OpenAI’s own service terms. OpenAI also said it was giving the maximum notice its agreement allowed, which works out to a little over ten weeks, and that its contract included a limited window to cancel after a change of control.

OpenAI’s help center article adds practical detail. It describes November 12 as the end of a transition period and says the formal termination date will be confirmed later. The affected features are the local Chat and Agent modes that currently offer OpenAI models. The unaffected features are Cursor Tab and autocomplete, Auto model selection, Cloud and Background Agents, Automations, the Cursor CLI, and the Cursor API and SDK, all of which continue to use models supplied by Cursor.

Users who want to keep using OpenAI models have three routes. They can bring their own OpenAI API key, which is billed separately from any Cursor or ChatGPT subscription. They can install OpenAI’s Codex extension and sign in with a ChatGPT plan or an API key. Or they can connect through an AI gateway their organization already manages, such as Amazon Bedrock or Azure. One detail matters for budgets: a ChatGPT subscription does not include API usage, so a team that switches routes may see a new line item.

Anthropic responded quickly. Co-founder and Chief Compute Officer Tom Brown said the company will keep increasing compute to support Claude models in Cursor.

What is disputed or still unclear

Several points are less settled than the headlines suggest, and they are worth separating from the confirmed facts.

Cursor CEO Michael Truell said OpenAI models account for only about 5% of Cursor’s traffic. That is Cursor’s own claim, not an independent measurement, and DevOps.com reported that it was widely questioned on social media. Treat it as Cursor’s position, not as an established number.

Truell also said Cursor was in talks with OpenAI to find a solution. Nothing in the sources reviewed shows that those talks have produced an outcome, and no response from SpaceX appears in the coverage we could verify. The November 12 date could still change, either through negotiation or through the formal notice OpenAI’s help article mentions.

The $60 billion price and the August 14 closing date come from reporting on the deal. The OpenAI post and the help article do not discuss the price. So the accurate framing is that the deal was reported at that value.

None of this changes the central lesson. Even if OpenAI models are a small share of Cursor’s traffic, the event shows how a change of ownership can turn a supplier into a gatekeeper overnight.

Why this is not really a Cursor story

Every company that builds on a third-party model has the same exposure Cursor just discovered. The contract you signed can be ended by the supplier under conditions you do not control, and an acquisition, on either side, is one of the most common triggers. In this case the acquired party was the customer. It could as easily be the supplier, whose new owner may reprice, restrict, or retire the product you rely on.

There is also a competitive dimension. Within hours of OpenAI’s announcement, a rival lab publicly reaffirmed its support for Cursor. That is good news for the customer in the short term, but it moves the dependency instead of removing it. A team that swaps one model vendor for another is still exposed to the same category of risk, only with a different counterparty.

Treat model access the way finance teams treat any critical supplier. Ask who owns the vendor, what happens if that changes, how much notice the contract requires, and what your fallback is. Most engineering roadmaps never ask these questions, because the model feels like infrastructure. It is closer to a contract that can be ended.

Switching models is not a configuration change

The technical half of the risk is easy to underestimate. Standards like MCP and A2A make it easier to connect an agent to tools and to other agents. They do not make one model behave like another.

Analysts quoted by CIO made this point directly. Manoj Chandra Jha of Nord-IQ Research said prompts and agent instructions that work well with OpenAI models can produce different results with another model, which forces enterprises to retune both prompts and evaluations. Abhishek Satapathy of Avasant listed where the differences show up in coding agents: repository-level work, debugging, refactoring, test generation, multi-file changes, and tasks where an agent must inspect a codebase, make changes, run tests, and correct its own errors.

That list should look familiar to anyone doing AI agent development. Agents chain many steps together, so a small difference in how a model interprets an instruction can compound across a workflow. A prompt that produced clean output on one model can drift on another, with tool calls made in a different order, formats interpreted differently, or errors handled in a different way.

CIO also quoted Pareekh Jain, who advised enterprises to support multiple models, test alternatives regularly, and “avoid making important workflows too dependent on one model.” The word regularly matters. A fallback model that has never been tested is only a hope.

What resilience looks like

Cursor itself offers a useful example of preparation. Most of its product does not depend on OpenAI’s models at all. Tab completion, Auto selection, cloud agents, automations, the CLI, and the API all continue on Cursor-supplied models. A Forbes analysis argued that this reflects deliberate investment in its own coding model, Composer 2.5, built on open-source checkpoints, which lets Cursor treat frontier model access as something it can substitute. That is an analyst’s interpretation rather than a confirmed account of Cursor’s strategy, but the product structure supports the point. The features most exposed are the ones where users chose an OpenAI model by name.

Very few companies can train their own model. The principle still applies at smaller scale: keep the part of your product that users experience separate from the part that depends on a single supplier. For teams working on AI agent development, that usually means keeping business logic, tool definitions, and evaluation data in your own repository, and treating the model as a component you can replace. Prompts written for one model should be documented as model-specific, so nobody assumes they will transfer.

A practical checklist for model dependency

Whether you are building internal tools, customer-facing agents, or a full product, the same steps reduce the risk. This is the kind of work that belongs in any serious AI development plan from the start.

Inventory every model dependency. List each workflow, which model it calls, through which route, and under which contract. Include shadow usage, such as teams running personal API keys.

Put an abstraction layer between your application and the model. Route calls through one internal interface so that changing the model is a change in one place, not a rewrite.

Build an evaluation suite before you need it. A set of representative tasks with expected outcomes lets you compare a replacement model on evidence instead of impressions. This is the piece Jha’s comment points to, and it is the one teams most often skip.

Test a fallback model on a schedule. Run the evaluation suite against at least one alternative every quarter, and keep prompts tuned for it, not only for your primary.

Read the contracts. Look for change-of-control clauses, notice periods, usage restrictions, and pricing terms. Note who can end the agreement and under what conditions.

Understand the billing routes. As the Cursor case shows, subscriptions and API access are often billed separately. Know which one each workflow actually uses.

Assign an owner. Model dependency is a business risk, so it needs an owner outside the engineering team who reviews it alongside other supplier risks.

Where this leaves you

OpenAI’s decision on Cursor is confirmed, with November 12 as the announced end date, though the formal termination date and the outcome of talks remain open. The claim that OpenAI models are 5% of Cursor’s traffic is Cursor’s own. The wider point does not depend on either detail. Access to a model is a supplier relationship, and supplier relationships change when ownership changes.

For teams investing in generative AI development and agent workflows, the response is measured, not alarmed. Inventory the dependencies, build the evaluation suite, test the fallback, and review the contracts. The cost is a few weeks of engineering time. The alternative is discovering your dependency on a Tuesday afternoon with a ten week clock running.

Frequently Asked Questions

1. When does OpenAI stop providing models to Cursor?
Answer: OpenAI announced on August 28, 2026 that access ends on November 12, 2026. Its help center describes that date as the end of a transition period and says the formal termination date will be confirmed later.

2. Why did OpenAI end the agreement?
Answer: OpenAI said it cannot be confident SpaceX will use its technology within its terms of service, following SpaceX’s acquisition of Cursor’s parent company. It cited a history of contract disputes involving Elon Musk’s companies.

3. What still works in Cursor after the cutoff?
Answer: Cursor Tab, Auto model selection, Cloud and Background Agents, Automations, the CLI, and the API and SDK continue on Cursor-supplied models. The affected features are local Chat and Agent modes that offer OpenAI models.

4. Can developers keep using OpenAI models in Cursor?
Answer: Through other routes, yes. OpenAI lists bringing your own API key, using the Codex extension, or connecting through an AI gateway such as Amazon Bedrock or Azure. API usage is billed separately from a ChatGPT subscription.

5. Is it true that OpenAI models are only 5% of Cursor’s traffic?
Answer: That is what Cursor CEO Michael Truell said, but it is Cursor’s own figure and was questioned publicly. It has not been independently verified.

6. How can my business reduce model dependency risk?
Answer: Inventory every model dependency, put an abstraction layer between your application and the model, build an evaluation suite, test a fallback model regularly, and review supplier contracts for change-of-control terms.

If you want to know how exposed your own workflows are to a single vendor, that is exactly what we look at in a free AI Readiness Audit.