Turning on Agentforce, Now Assist, Joule and Copilot safely
Most business platforms now ship their own AI. Agentforce in Salesforce, Now Assist in ServiceNow, Joule in SAP, Copilot in Dynamics 365 and Power Platform. Cohash helps you turn them on properly. We find out what's already enabled, which user each agent acts as and what it grounds on, then choose use cases with named owners, test against real cases, and set up monitoring with an off switch.
- 01Inventory what's on
- 02Identity and data review
- 03Use cases with owners
- 04Configure and test
- 05Rollout and monitoring
- 06Release cadence
The story
Told without the client's name or anything that could identify them.
A distribution company discovered Agentforce had been switched on in its Salesforce org under Winter '27. Meanwhile separate teams were piloting Now Assist and Copilot, and none of the assistants talked to each other. Security asked which user account each agent acted as. Nobody knew. We went through admin settings, licences and release notes on every platform to list what was already on. Then we traced each agent's run-as user, permission sets and grounding sources, and fixed the over-broad access before anything went live. A few use cases per platform got a named owner, a success measure and a list of allowed actions, and we tested them on real past cases. Agents went to a small group first. Consumption was checked weekly, and there was a documented way to switch each one off.
why it was urgentFrom September 2026 Salesforce is turning Agentforce on in existing orgs, on a rolling basis. Its Winter '27 release does that for eligible orgs and removes the setup toggle. ServiceNow announced Otto on 5 May 2026, which combines Now Assist, Moveworks and AI Experience under AI Control Tower. Microsoft, from September 2026, moved Dynamics 365 and Power Platform to a continuous roadmap.
- openAgentforce is switched on in your Salesforce org. Nobody decided what it's for.
- recurringNow Assist skills are licensed but only one or two are switched on.
- blockedEvery platform team is running its own assistant pilot, and none of them talk to each other.
- openSecurity wants to know which user account each agent acts as.
The estate, before and after
Before: vendor assistants switched on without owners
Agentforce came on by default and other teams ran their own Now Assist and Copilot pilots. The agents ran as broad integration users, grounded on whatever knowledge content happened to be connected, and users didn't know which assistant to ask.
Read the diagram as text
- Employees → Agentforce: ask
- Employees → Now Assist pilot: ask
- Employees → Copilot pilot: ask
- Agentforce → Broad integration users: runs as
- Now Assist pilot → Broad integration users: runs as
- Agentforce → Uncurated knowledge: grounds on
- Copilot pilot → Uncurated knowledge: grounds on
After: vendor agents with owners, scoped identities and monitoring
Each platform's agent does the tasks it owns, under a scoped identity, grounded on curated sources. Usage and answer quality go to a dashboard. Use-case owners review it before they widen access or switch an agent off.
Read the diagram as text
- Employees → Agentforce: service cases
- Employees → Now Assist: IT tickets
- Employees → Joule: invoice questions
- Employees → Copilot: CRM tasks
- Agentforce → Scoped agent identities: runs as
- Now Assist → Scoped agent identities: runs as
- Joule → Scoped agent identities: runs as
- Scoped agent identities → Curated knowledge sources: grounds on
- Scoped agent identities → Consumption and quality: actions · usage
- Consumption and quality → Use-case owners: weekly review
- Use-case owners → Switch-off runbook: switch off
How we run it, phase by phase.
6 phases take you from Vendor AI arriving on by default or half set up to Agentforce, Now Assist, Joule and Copilot in governed use. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory what's on
Check each platform's admin settings, licences and release notes for AI features already enabled or due to be. Note which ones come on by default and which need a decision.
- phase 02
Identity and data review
Find out which user or integration account each agent runs as, what permission sets and sharing rules it inherits, and which knowledge sources it grounds on. Fix any over-broad access before an agent goes live.
- phase 03
Use cases with owners
We pick a few use cases on each platform with a business owner, things like case summaries, ticket triage or invoice questions. Each gets a success measure and a list of the actions the agent may take.
- phase 04
Configure and test
Build topics, actions, skills or agent instructions, then test them against real past cases, including the awkward ones. Guardrails and handoff to a person are tested, not assumed.
- phase 05
Rollout and monitoring
Release to a small group, watch answers, actions and consumption, and keep a documented way to turn each agent off. Widen access only when the owner signs off.
- phase 06
Release cadence
Vendor AI changes with every platform release. So we do a short review each time, checking new defaults, renamed features and anything that changes what an agent can do.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every agent runs as a known identity with scoped permissions
We went through the user or integration account behind each agent, plus its permission sets and sharing rules, and cut access back to the job the agent actually does.
- result 02
Each use case has an owner and a list of allowed actions
We keep a use-case register. It records the business owner, the success measure and the permitted actions for each agent, platform by platform.
- result 03
Agents were tested on real cases before release
Topics, actions and skills were tested against real past cases, awkward ones included. Guardrails and the handoff to a person were tested too, rather than assumed to work.
- result 04
Every agent can be watched and switched off
We built a dashboard per agent showing consumption and answer quality, and wrote a switch-off runbook that says exactly how to turn each one off.
- result 05
Each platform release gets an AI review
We do a short review per release. It looks at new defaults, renamed features and anything else that changes what an agent can do, and we adjust permissions and tests to match.
Risks we plan for
-
Agents with admin reach
Run the agent as a broad integration user and it inherits all of that user's reach. Scope its permissions down to the one job it does.
-
Grounding on the wrong data
Stale or sensitive content in knowledge bases and record fields goes straight into the agent's answers. Clean up the sources first, then connect them.
-
Surprise consumption
Some vendor AI features charge per action, per credit or per conversation. Set usage limits and check cost every week from the start of the rollout. The invoice is a bad place to find out.
-
Overlapping assistants
Put an assistant in every tool and people won't know which one to ask. Decide early which platform is the front door for each kind of task, and tell users.
Where AI helps, and where it needs guardrails
Every platform now ships its own agent layer, plus an MCP door for outside agents. Salesforce Winter '27 adds third-party agent orchestration. ServiceNow governs actions through AI Control Tower. SAP's Joule Studio supports MCP and A2A. So the design question is which agent owns which task, and how one hands off to another. We map that, give each agent its own identity, and keep a single audit trail across the platforms.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Inventory of AI features per platform, with enablement status and decisions
yours to keep - report02
Agent identity and permission review with fixes applied
yours to keep - inventory03
Use-case register with owners, measures and allowed actions
yours to keep - runbook04
Test results against real cases, and a switch-off runbook per agent
yours to keep - document05
Consumption and quality dashboard per agent
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Agentforce was turned on automatically. Should we turn it off?
Not necessarily. Salesforce says default enablement comes at no extra charge, but check what agents exist, which user they run as and who can reach them. Then decide use case by use case.
02Which platform's AI should we start with?
Look for a clear task that happens a lot and sits on clean data. Case summaries in service and ticket triage in IT get picked first a lot, mostly because it's easy to tell whether the output is right.
03Do we need a separate AI platform if vendors ship their own?
Not always. If the work stays in one platform, vendor AI fits. Work across systems may need your own agent calling each platform through its APIs or MCP server.
04Do you also handle ongoing releases?
We do. Each platform release is reviewed for AI changes, then we adjust the agents, permissions and tests. It can sit inside platform support or run as a standalone service.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAI pilot to production with forward deployed engineers
Taking an AI pilot into production with forward deployed engineers who work with the business team, build evals, connect real systems and hand over cleanly.
read the case study8f3c07db - 01Salesforce: Winter '27 product release announcementsalesforce.com ↗
- 02Salesforce release notes: Agentforce auto-enable (Winter '27)help.salesforce.com ↗
- 03Salesforce Ben: Agentforce auto-enabled in Winter '27salesforceben.com ↗
- 04ServiceNow newsroom: ServiceNow Otto (5 May 2026)newsroom.servicenow.com ↗
- 05SAP News: New agentic capabilities on SAP BTP (5 Nov 2025)news.sap.com ↗
- 06Microsoft Dynamics 365 blog: moving beyond release waves (25 Aug 2026)microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it