Tag: AI automation

On October 8, 2026, Google Cloud introduced the Gemini agent, a general-purpose agent for work, at its Gemini at Work event. The announcement, published as a post by Google Cloud CEO Thomas Kurian, makes a specific pitch: an agent with its own account, its own audit trail and a budget cap that pauses it. For anyone responsible for AI governance, that is a notable shift, because controls that used to be added afterward are now described as part of the product.

This is a vendor announcement. Google’s claims have not been independently tested, and the post gives no general availability date, eligibility rules or agent pricing. This piece sets out what was announced, what is not established, and the question it raises: the features are Google’s, but who owns the policy behind them? It follows our earlier look at CrowdStrike’s shadow AI agent product and is written for teams doing AI agent development or generative AI development, and for those adopting agents from vendors.

What Google announced

According to the Google Cloud post, the Gemini agent plans tasks, uses tools, connects to a company’s business systems and returns finished work in the documents and inboxes people already use. The governance claims fall into four groups.

Identity. Google says coworker agents have dedicated identities, including their own email addresses on a company domain, and see only the context a person or team gives them. In Workspace, an agent gets its own account with an email address, a calendar, a Drive and a place in the company directory. Google also says each identity is cryptographically attested and limited to least-privilege permissions.

Audit trail. Google says every action the agent takes is written to an audit trail and “attributed to the agent rather than to a person.” The identity is stamped into the logs, and the logs can be watched in real time.

Spend caps. Administrators can set a hard limit on a project’s AI spend in the Cloud Billing Console. The project’s agent pauses when the cap is triggered, and work resumes with one click. Spend is tracked per project, so costs can be charged back to departments.

Policy and security. Rules are written once and apply to every agent, such as barring agents from documents classified as need to know. The post frames governance as four questions: who the agent is, what it is allowed to do, what it did and where you can see it, and what it should never touch.

Identity: an account is not an owner

A separate account solves a real problem. When an agent works through an employee’s login, its actions look like that employee’s, and revoking one disrupts the other. A separate identity lets security teams grant narrower access and switch the agent off without touching a person’s account. Analyst firm Futurum credits the design with giving security teams a clear line between human and agent actions.

What an account does not provide is an accountable owner: it does not say which person approved the agent’s permissions or answers when it gets something wrong. Google says an agent sees only what people share with it, which means someone is sharing, and that decision belongs to you. Our guide to AI agent governance puts inventory and scope of authority at the start of its framework for this reason.

The audit trail, and what it leaves open

An action-level log helps reconstruct what happened, and attributing entries to the agent keeps human and automated activity apart. It also raises a question the post does not address: how does a reviewer link an agent’s action back to the request, and the person, that set it off? That is our inference, not a gap Google has acknowledged.

A log only helps if someone reads it. A September survey published by Guild.ai, a vendor of agent management tools, and fielded by Morning Consult, reported that 39.8% have logging or audit trails and 31% have an automated kill switch. The release does not state the base for those figures and the research is vendor-sponsored, so treat them as indicative only.

Spend caps: useful, but thinly described

The post gives no time period, no alert thresholds and no figure for how quickly a cap takes effect. An earlier Google Cloud post on billing for agents, dated August 26, 2026, describes a firm monthly project cap, alerts at 50%, 80% and 100% of budget, and an optional overage setting. The October post does not say whether the same settings apply to the Gemini agent, so do not assume they do.

Two limits follow from how a cap works, and both are our reading. The cap sits at the project level, so one runaway agent could pause others sharing the project. And a cap limits cost, not harm: an agent can send a wrong message or delete a file at almost no cost, so caps sit beside permissions and approvals, not in place of them.

What independent voices say

Coverage so far is analysis of the announcement, not testing. Carmi Levy, an independent analyst quoted by CIO on October 8, said Google is trying to become “the gatekeeper of the new enterprise operating system.” He called Google arguably ahead on identity and audit trails, but questioned whether CIOs and CISOs can trust it with mission-critical processes.

Mahmoud Ramin of Info-Tech Research Group, quoted in the same article, said the announcement does not create a new category, and called enforcing governance non-negotiable.

Futurum, in an October 9 analysis, noted that Google says it does not intend to charge a per-seat license for coworker agents in Workspace, but has not said how it will meter agent activity.

What is and is not confirmed about availability

Google’s product page says “Not every feature shown on this page is available right now.” It lists delegating multi-step background tasks, mobile and desktop access, and third-party model choice as early access.

The Kurian post gives no general availability date, eligibility criteria or agent-specific price. It labels the Financial Services and Legal specializations as in preview, with Government, Healthcare and Retail coming soon. It does not label the core agent, coworker agents or spend caps as preview or generally available, so their status is unconfirmed. Futurum makes the same point: Google gave few general availability dates.

Reworked reports that a Google spokesperson told VentureBeat the agent comes at no additional charge where Gemini Enterprise is available. We did not find that in Google’s own posts, so treat it as reported.

Who owns the policy behind the controls

Google has built mechanisms: an identity, a log, a cap and a place to write rules. None of them decides anything. Someone still has to choose which agents may exist, which data counts as need to know, what each budget should be and who reviews the logs.

This is the point our CrowdStrike piece made about detection tools. A product can enforce a policy, but it cannot write one.

There is also a coverage problem. Google’s controls cover Google’s agent, while agents from Salesforce, Microsoft and others bring their own identities, logs and caps. Shared protocols help agents talk to one another, but as we noted in our look at MCP and A2A governance, they do not settle who is responsible. That belongs to a policy that sits above any one vendor.

Is your agent governance ready? A checklist

Use Google’s four questions as a test, whichever platform you run.

Who is the agent? Keep a register in which every agent has a named owner, a purpose and an identity of its own, not a shared login or a personal account.

What can it do? Grant the narrowest access that lets it do the job, name the data it must not open, and review access on a schedule.

What did it do? Retain logs long enough to reconstruct an incident, assign someone to review them, and record who requested each task.

What should it never touch? Write a short list covering regulated data, payments, deletion and external sending, then test that the controls block those actions.

Set a budget for each agent or project, and decide who is alerted and who may resume work. Rehearse the stop by timing how fast you can disable an agent and revoke its credentials. A short AI Readiness Audit can show which of these controls you already have.

What this means if you build or buy agents

For teams doing AI agent development, identity, scoped permissions, logging and spend limits belong in the requirements from the first sprint, because they are cheaper to design in than to add later. Teams working on generative AI development can use the four questions as a design review before an agent reaches production.

For AI automation that connects agents to CRM and finance systems, start with read-only access and add actions as controls prove themselves. Wider AI development programs should treat agents as production systems with an owner and a review schedule. Google’s preview focus on financial services and legal is a signal too: finance and banking and law firms should apply the strictest version of these questions.

Where this leaves you

The confirmed facts are these. On October 8, 2026, Google Cloud introduced the Gemini agent and said its agents have their own identities, including email, that every action is written to an audit trail attributed to the agent, and that project-level spend caps pause the agent when triggered. This is a vendor announcement that has not been independently tested. Google’s post gives no general availability date, eligibility rules or agent pricing, and some related features are in early access or preview.

The practical response does not depend on any one vendor. Treat identity, logging and caps as tools, and AI governance as the policy that tells them what to enforce. Decide who owns each agent, what it may touch, what it may spend and who reviews its record. That discipline supports AI automation and AI development alike, so write it down before the platform asks for it.

Frequently Asked Questions

1. What did Google announce on October 8, 2026?
Google Cloud introduced the Gemini agent in a post by CEO Thomas Kurian. Its governance claims include agent identities with email addresses, an audit trail attributed to the agent, and project-level spend caps.

2. Does the Gemini agent really get its own email address?
Google says so. In Workspace, a coworker agent gets its own account with an email address, calendar and Drive. It is a vendor claim, with no availability date given.

3. What does the audit trail record?
Google says every action is written to an audit trail attributed to the agent, not a person. The post does not describe log retention or how an action links back to the requester.

4. How do the spend caps work?
An administrator sets a hard limit on a project’s AI spend in the Cloud Billing Console, and the project’s agent pauses when it is triggered. The post gives no time period, thresholds or enforcement speed.

5. Is the Gemini agent available to everyone?
Not as far as Google’s pages show. The post gives no general availability date or eligibility rules, some capabilities are in early access, and some industry versions are in preview.

6. If I use Google’s agent, is my AI governance solved?
No. The platform supplies identity, logging and caps, but you still decide which agents exist, what they may access, what they may spend and who reviews their activity.

7. What should my company do first?
Answer Google’s four questions for every agent you run, name an owner for each, and write the policy before relying on any vendor’s controls.

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

Ask most IT leaders whether they know which AI agents are running in their company, and the answer is yes. A new survey suggests that confidence may be running well ahead of the controls behind it. Published by Guild.ai and fielded by Morning Consult, it found that 96.4% of IT decision-makers are confident their agent inventory is complete and accurate, while 66.7% of organizations with agents reported an agent-related operational consequence in the past 12 months.

One point belongs at the top, not the bottom. Guild.ai sells tools for managing AI agents, so this is vendor-sponsored research, and it should be read that way. This piece follows on from our earlier look at shadow AI and sets out what the survey reports, what its wording and bases do and do not support, and what an organization can do with the findings. It is written for teams planning AI governance and AI automation programs for agents, not just buying software for them.

What the survey reports

According to Guild.ai’s September 22, 2026 release, Morning Consult surveyed 362 U.S. IT decision-makers at companies with 100 or more employees. Interviews were conducted online from August 4 to 9, 2026, and the data was weighted by age, company size, industry and role. The margin of error is plus or minus five percentage points for the full survey.

The headline figures are these. 96.4% of IT decision-makers are confident their organization has a “complete and accurate inventory” of its AI agents. 66.7% of organizations with agents had an agent-related operational consequence in the past 12 months. 96% of organizations report agents in production, and 47% of those with agents run dozens or more.

The control figures are lower. 42.7% have a centralized dashboard or monitoring tool, 39.8% have logging or audit trails, and 31% can immediately stop a malfunctioning agent with an automated kill switch. On unapproved use, 60.6% say it is very or somewhat likely that employees deploy agents without formal approval, 35.9% require agents to be registered before deployment, and about half have a formal policy on unauthorized agent use.

Who ran it, and why that matters

Morning Consult fielded the survey, but Guild.ai commissioned and published it. Guild describes its product as a control plane for the agent lifecycle, with offerings that include AI governance and AI observability tools, according to its website. The findings point toward exactly the kind of tooling it sells, such as the 83.9% who rate real-time visibility into agent activity as extremely or very valuable.

That does not make the numbers wrong. Vendor-sponsored surveys can be carefully run, and an outside firm doing the fieldwork counts in its favor. But the sponsor chose which results to feature, so treat the data as informative and the conclusions as the vendor’s.

What the numbers do and do not show

Several details affect how far the headline can be pushed.

The word incident is not defined. The release describes an “agent-related operational consequence” and, elsewhere, an agent-related incident, and neither term is defined in the material we reviewed. A consequence could be a minor disruption or a serious breach. Two in three is a striking figure, but without a definition it does not tell you how serious those events were.

The bases differ. The 96.4% is a share of IT decision-makers. The 66.7% is a share of organizations with agents. The release does not state the base for the monitoring, audit trail and kill switch figures, so they cannot be compared precisely with the others.

The scope may be narrower than it sounds. Guild’s report page describes the survey scope as internally built and actively managed agents. If that is right, the confidence is about agents an organization built and manages, and the survey does not show how confident leaders are about agents employees bring in on their own. The 60.6% on unauthorized deployment is the nearest measure of that, and it is a perception of likelihood, not a count.

Confidence is self-reported. A leader who says the inventory is complete is giving an opinion. The survey did not test whether the inventory was actually complete, so it shows a gap between belief and controls, not a measured gap between the inventory and reality.

The margin of error applies to the full survey. Subgroup figures, such as organizations with agents, rest on fewer respondents and carry more uncertainty than the plus or minus five points suggests.

The confidence gap, read carefully

The core observation is that confidence and controls do not line up. Nearly everyone is confident about the inventory, yet fewer than half have centralized monitoring and fewer than four in ten have audit trails. A complete inventory and no way to see what the agents do is a thin kind of control.

The kill switch figures need a careful reading, because they cut both ways. Only 31% have an automated kill switch. But Guild’s own release reports that 76.5% can stop a malfunctioning agent within minutes, using an automated switch or a manual process. So most organizations say they can stop an agent quickly, and a minority have automation to do it. The accurate summary is that manual shutdown is common and automation is not. Whether a manual process works at three in the morning, or when ten agents misbehave at once, is a different question the survey cannot answer.

A second survey, and the same caveat

A separate survey points in a similar direction. SecureWorld reported on August 31, 2026 on research by Cequence Security and Enterprise Management Associates, which ran the survey for Cequence. It reported that 94% of respondents were at least moderately confident that agents do not have more access than needed, while only 32.7% used least-privilege access scoped to the task. It also reported that 47% could not reliably inventory their agents, and that 65% had seen an agent act outside its intended scope.

The sample was 202 IT and security leaders, and the coverage did not describe fieldwork dates or margins of error. Cequence is also a security vendor. Two vendor-sponsored surveys finding a gap between confidence and practice is suggestive, not conclusive, since both sponsors benefit from that story. A Cequence executive said that confidence “is usually measuring compliance, not cyber”, which is one vendor’s view, not a finding.

Why a confident inventory is not a governed one

An inventory is a list. It tells you which agents exist. AI governance is what you do with the list: who owns each agent, what it may access, who approved it, what it costs, how it is monitored, how its changes are reviewed and how it is stopped or retired.

Seen that way, the survey’s pattern is easy to understand. Teams build agents quickly, record them in a spreadsheet and feel in control. Then an agent changes, a credential is shared or an owner leaves, and the list no longer matches reality. Confidence comes from writing the list. Control comes from keeping it true.

This is also why the registration figure matters. Only 35.9% require agents to be registered before deployment. Without a registration step, an inventory is something someone compiles occasionally, not something the process produces automatically.

What to do with this

You do not need the survey’s sponsor, or any vendor, to act on its lessons. These steps apply whether you buy tooling or do the work by hand.

Test the inventory by evidence. Do not ask whether the list is complete. Look for agents the list does not contain by checking service accounts, API keys, automation platforms and cloud billing for agent activity, and by asking each team what they run.

Assign an owner to every agent. A named person or team should answer for what each agent does and what it can reach.

Make registration a precondition. An agent should not go into production until it is on the list, with its permissions, data access and purpose recorded.

Log actions, not just existence. Keep a record of what each agent did, which tools it called and which data it touched, with enough retention to reconstruct an incident.

Define incident and track it. Agree what counts as an agent-related incident in your organization, from a near miss to a breach, and record each one. You cannot improve a rate you do not measure.

Rehearse the stop. Test how fast you can disable an agent and revoke its credentials, in practice, with the person who would actually do it. If the answer depends on one individual, write it down and share it.

Limit permissions. Give each agent the narrowest access that lets it do the job, and review the access on a schedule.

For businesses planning AI agent development or wider AI automation, these controls are cheaper to design in at the start than to add later. Teams doing generative AI development should treat identity, scoped permissions and logging as part of the build, not as a later compliance task.

Where this leaves you

The confirmed facts are these. Guild.ai published a Morning Consult survey of 362 U.S. IT decision-makers, fielded in August 2026. 96.4% are confident their agent inventory is complete, and 66.7% of organizations with agents reported an agent-related operational consequence in the past 12 months. Fewer than half have centralized monitoring or audit trails. The research is vendor-sponsored, its key terms are not defined in the release, and confidence is self-reported.

The practical response does not depend on any single percentage. Treat a complete-looking list as a starting point: test it, assign owners, log what agents do and practice stopping them, whether you are in AI agent development or simply adopting agents. Organizations that do this can adopt agents faster, because they know what they are running. For anyone building AI development capability, that discipline is the foundation.

Frequently Asked Questions

1. Who ran the Guild.ai AI agent survey?
Guild.ai published it and Morning Consult fielded it. It surveyed 362 U.S. IT decision-makers at companies with 100 or more employees, online, from August 4 to 9, 2026, with a margin of error of plus or minus five points. It is vendor-sponsored research.

2. What are the key findings?
96.4% of IT decision-makers are confident their agent inventory is complete and accurate, and 66.7% of organizations with agents had an agent-related operational consequence in the past 12 months. Only 42.7% have centralized monitoring, 39.8% have audit trails and 31% have an automated kill switch.

3. Does this prove that most companies have a governance problem?
It suggests a gap between confidence and controls, but it does not prove it. Confidence is self-reported, incident is not defined, and the survey is sponsored by a company that sells agent management tools.

4. Is an incident the same as a security breach?
Not necessarily. The release uses the phrase agent-related operational consequence and does not define it, so it could cover anything from minor disruption to serious harm.

5. Can most companies stop a misbehaving agent?
The release reports that 76.5% can stop one within minutes by automated or manual means, but only 31% have an automated kill switch. Manual shutdown may work in a calm test and be harder in a real incident.

6. What is the difference between an agent inventory and AI governance?
An inventory lists which agents exist. Governance covers ownership, permissions, approval, monitoring, change control and shutdown. Strong governance keeps the inventory accurate over time.

7. What should my company do first?
Test your inventory by looking for agents it does not list, then assign an owner to each agent, require registration before deployment and set up logging of what agents do.

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

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.