Tag: enterprise AI agents

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.

On 17 August, Google’s A2A protocol became a hosted project of the Agentic AI Foundation at the Linux Foundation, the same neutral body that already stewards Anthropic’s MCP. Axios broke the story first, and coverage followed within two days across the AI trade press. Nothing about the technology changed. No specification was rewritten and no API broke. What changed is who is responsible for where these standards go next, and that answers a genuine, practical fear for anyone buying agent technology right now: whether committing to one vendor’s agents locks you out of everyone else’s.

At the same time, the agentic AI adoption numbers tell a very different story from the governance news. Most enterprises still cannot get an agent past a pilot. Both things are true at once, and understanding why matters more than either headline on its own.

What actually changed on 17 August

Two protocols now sit under the same governance roof at the Agentic AI Foundation, AAIF for short.

MCP, the Model Context Protocol, was Anthropic’s founding contribution to AAIF when the foundation launched on 9 December 2025. MCP defines how a single AI agent connects to tools, data and applications, essentially the wiring between an agent and everything it needs to actually do work.

A2A, the Agent to Agent protocol, is what Google built to solve a different problem, how independent agents built by different vendors discover each other, hand off tasks and coordinate across organisational boundaries. Google had already donated A2A to the Linux Foundation back in June 2025. What happened on 17 August was narrower and more specific, A2A moved from the Linux Foundation’s general portfolio into AAIF specifically, the foundation built for agentic AI, joining MCP under one roof.

It is worth being precise about what this was not. Coverage of the move has been careful to point out that this is not an ownership event. Each protocol keeps its own maintainers, its own specification process and its own release schedule. What the foundation actually settled is who stewards the specifications going forward, not who controls them technically. What it left unsettled is arguably more important for a business evaluating this, which agent gets to read which data when multiple vendors are involved. Shared governance answers the communication question. It does not answer the access and responsibility question, and that gap is still something every enterprise has to work out contractually, not technically.

AAIF has grown fast since December, from under 40 member organisations to more than 250. The platinum members list reads like most of the industry that matters here, AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI all sit on it together, which is notable given how rarely these companies share governance of anything.

Google Cloud’s VP for agent infrastructure, Rao Surapaneni, explained the practical reasoning to Axios plainly. Enterprises are deploying agentic systems from multiple technology providers, and those agents need to actually work together. A protocol that only one vendor controls does not solve that problem. A protocol under neutral, shared governance at least has a chance to.

Why this is a bigger deal than it sounds

If you are not building agent infrastructure yourself, a protocol governance change can sound like plumbing news, and mostly it is. But the practical question underneath it is one every business evaluating AI agent vendors right now should be asking.

Before this kind of consolidation, building a multi-agent system meant either committing to one vendor’s full stack, or writing custom integration code for every agent-to-agent handoff yourself. Neither is a comfortable position. The first creates lock-in. The second creates a maintenance burden that grows with every new agent you add.

With MCP and A2A both governed by the same neutral body, the practical effect is that agents built on different platforms have a real, shared standard for talking to each other, rather than a patchwork of vendor specific bridges that break every time one side updates. That does not eliminate vendor lock-in entirely, plenty of it can still happen at the platform layer above these protocols, but it meaningfully lowers the risk of choosing a vendor today and finding yourself boxed in a year from now.

This is not purely theoretical. A2A has already moved past the pilot stage in its first year, with reported adoption spanning supply chain, financial services, insurance and IT operations, sectors where coordinating autonomous systems across multiple tools, vendors and environments is not optional, it is the whole point. Those are also, not coincidentally, some of the same sectors leading on actual production use of agents generally, which suggests the businesses that need multi-vendor coordination most are the ones pushing hardest for exactly this kind of shared standard.

For a business evaluating who to build an AI agent strategy with, this is now a fair question to ask any vendor directly: do your agents speak MCP and A2A, or only your own proprietary protocol.

The number that matters more than the governance news

Here is the part most coverage of this story skipped entirely, and it is the more important half.

Gartner’s most recent enterprise survey found that 80 percent of enterprise applications shipped or updated in the first quarter of 2026 now embed at least one AI agent, up from just 33 percent two years earlier. The range is wide, everything from a customer service deflection bot handling routine queries to a fully autonomous coding agent opening pull requests against a shared repository. That sounds like near universal adoption, and by one measure, it is.

Separate research from S&P Global Market Intelligence and McKinsey tells a different part of the story. Only 31 percent of enterprises actually have an agent in production. Adoption and production are not the same thing, and the gap between them is enormous. Banking and insurance lead at roughly 47 percent in production. Healthcare sits at 18 percent, government at 14 percent.

A separate KPMG survey from earlier this year adds another layer to the same picture. 42 percent of US enterprises have tested or deployed AI agents in some form, but only 15 percent have actually achieved scaled, orchestrated multi-agent adoption, meaning multiple agents working together rather than one isolated tool running in one workflow. Most organisations that have started are still stuck well short of the coordinated setup that actually needs a protocol like A2A in the first place.

Research from MIT’s NANDA initiative puts a number on exactly where projects stall. Of custom enterprise AI tools built, roughly 60 percent get evaluated, about 20 percent make it to a pilot, and only 1 in 20, five percent, actually reach production. The drop happens overwhelmingly between pilot and production, not between idea and pilot. Getting something working in a demo has never been the hard part.

Gartner’s own forecast is blunter still, more than 40 percent of agentic AI projects are expected to be cancelled before the end of 2027, cited reasons being escalating costs, unclear business value and inadequate risk controls.

A governance standard for how agents talk to each other does not fix any of that. AI agent interoperability was never the reason most agent projects stall between pilot and production. The reasons are the same ones we wrote about a fortnight ago covering AI readiness generally, the wrong use case gets chosen, the data underneath the agent was never actually ready, nobody owns the system once it is live, and success was never clearly defined before the build started. A protocol under good governance still fails against a process that never met those four conditions to begin with.

What this actually means if you are building an agent strategy

Two separate decisions are getting easier to make right now, and it is worth treating them as separate, because conflating them is exactly how a business ends up with a technically sound agent that never earns its keep.

Which protocol standard to build on just got clearer. MCP and A2A, under shared neutral governance with the backing of every major cloud and AI lab, are a safer long term bet than a vendor’s proprietary alternative. Ask any agent vendor directly whether they support both, and treat a vague answer as a warning sign rather than a technicality to sort out later.

Whether your business is actually ready to run an agent in production has nothing to do with this news at all. That question is still answered the same way it always was, by checking whether the process you want to automate is repeatable, runs at real volume, follows consistent rules, and is expensive enough in hours that solving it is worth the build. A governance standard makes the plumbing safer. It does not make a badly scoped project succeed, and it will not move you from the 69 percent still stuck outside production into the 31 percent who have actually gotten there.

The businesses currently sitting in that 31 percent did not get there because they picked the right protocol first. They got there because they picked the right process first, and only then worried about the technical layer underneath it.

Frequently asked questions

1. Did the protocol itself change on 17 August?
Answer: No. No specification was rewritten and no API changed for existing users of either MCP or A2A. What changed is which body stewards A2A going forward, moving it into the Linux Foundation’s Agentic AI Foundation alongside MCP rather than sitting in the Foundation’s broader, less specialised portfolio.

2. What is the actual difference between MCP and A2A?
Answer: MCP connects a single AI agent to the tools, data and applications it needs to do its job, essentially agent to tool. A2A connects independent agents to each other, so agents built by different vendors or teams can discover one another and hand off work, essentially agent to agent. They solve different layers of the same overall problem.

3. Does this mean vendor lock-in with AI agents is solved?
Answer: No, and no announcement has claimed that. Lock-in can still happen at the platform layer above these protocols through proprietary extensions or platform specific features. What has improved is the baseline, the core communication layer is now under shared governance rather than controlled by any single company. Data access and responsibility between agents from different vendors is still something you need to settle contractually, governance of the protocol does not settle it for you.

4. Why do 80 percent of companies have agents but only 31 percent have them in production?
Answer: The two figures measure different things. Having at least one agent embedded somewhere in an application is a low bar that most enterprises have now cleared. Running an agent reliably in production, with proper monitoring, ownership and a clear success measure, is a much higher bar, and most organisations have not built the operating discipline for it yet. Separate research puts the actual production rate for custom built tools as low as 5 percent, with most of the drop-off happening between pilot and production specifically.

5. Which industries are actually using this in production already?
Answer: Banking and insurance lead general agent production use at around 47 percent. On the interoperability side specifically, A2A’s first year of adoption has concentrated in supply chain, financial services, insurance and IT operations, sectors where coordinating agents across multiple vendors and systems is a core requirement rather than a nice to have.

6. Should this change which AI agent vendor we choose?
Answer: It is worth adding as one factor. Ask whether a vendor’s agents support MCP and A2A as open standards, since that reduces your long term switching cost. It should not be the only factor. Whether the vendor can actually help you scope a use case that clears the readiness bar matters more than protocol support alone.

If you are trying to work out whether a specific process in your business is actually ready for an AI agent, or whether the agent conversation you are having is solving the wrong problem entirely, that is exactly what we walk through in a free AI Readiness Audit.