Agentforce can automate marketing work. But it can’t compensate for fragmented data, undocumented consent logic, or unclear ownership. Before you put an agent anywhere near your Marketing Cloud environment, ask one simple question: Can you reliably answer who is in your VIP segment, why they’re there, and whether they’re eligible to receive a message, all from data the agent can access?

If the answer is no, the problem isn’t your AI strategy. It’s your marketing foundation. That’s what makes Agentforce readiness different for Marketing Cloud teams. 

Your audience logic may live across Data Extensions built years ago. Consent rules may be split between attribute sets, suppression scripts, and AMPscript. Campaign knowledge may sit in spreadsheets, Slack threads, and the heads of people who built the programs. None of that makes Agentforce a bad investment. It means there’s work to do before you give an agent the keys.

Here’s what we’d fix first.

1. Begin with the result, not with the capability.

The usual mistake is to begin with an interesting feature and then look around for a place where it can be applied. Rather, start with a marketing process that allows an agent to produce a result that can be given a numerical value. Before you deploy anything, be able to answer four questions:

• Which business outcome is this agent accountable for?
• What level of risk are we prepared to take if we make a mistake?
• What kind of data is required in order to carry out the task, and is that data currently available in a usable form?
• Who is it that uses this agent on a day-to-day basis, and what does it take the place of?

Marketing teams usually find that the most promising early choices are those which are internal and read-only. It is much easier to control an agent who helps a campaign manager to locate the correct Data Extension, displays previous campaign performance, or replies to the question “which segments have already received this offer” than it is to control one that creates audiences or triggers journeys.

That is also the correct first step for a second reason, since it enables you to develop an operating model based on a use case in which mistakes are inexpensive, namely, how agents are designed, tested, given permission, released, and monitored. Only after those practices are in place can you apply them to agents that write, not just those that read.

2. Your data is the constraint

Agentforce can only act on what it can access, and in Marketing Cloud the stuff it can access is generally a mess. So, before you define the scope of an agent, carry out an audit for:

• Data Extension sprawl. Duplicated, near-identical, and abandoned DEs with no clear system of record. An agent asked “who’s in our VIP segment” needs one defensible answer, not eleven.
• Subscriber key integrity. Inconsistent keys across DEs and business units mean an agent can’t reliably reason about a single person.
• Consent and preference logic. If unsubscribe status, preference center selections, and suppression rules live in scripts rather than in data, an agent has no way to respect them.
• Knowledge quality. Campaign documentation, naming conventions, brand rules. If these are stale, the agent’s answers will be confidently stale too.
• Data Cloud readiness. If you’re grounding agents in unified profiles, identity resolution and harmonization quality become an Agentforce dependency, not a Data Cloud project running in parallel.

Treat access as part of the same exercise. An agent doesn’t need visibility into every data extension in the account just because it exists. Decide what data each agent needs, where it lives, and under what conditions it should retrieve it. That decision is where governance actually begins.

3. Governance, and who owns it

Each agent you create behaves like a user in your org. It has an identity, permissions, and the ability to take actions. Very few marketing teams have thought about it that way, and governance usually arrives after the first agent is already live. That’s the wrong order.

A workable governance model covers five things:

Identity. Configure each agent’s profile deliberately. Don’t clone an admin profile because it’s faster. Give the agent the access its role requires and nothing beyond it.

Data grounding. Provide access only to the data the task needs. Check field-level visibility carefully. Some masking protections behave differently for agents than for human users, and PII exposure through an agent is still PII exposure.

Action scoping. Define what the agent may do, not just what it may see. In a Marketing Cloud context, this is the part that matters most. Can it create an audience, modify a journey, initiate a send? Get these boundaries wrong at design time, and you will find out about it in production.

Guardrails. Defaults are a starting point, not a configuration. Test against edge cases, including the ones that only occur to you on the third pass. Agentforce Testing Center is useful here for validating behavior at scale against synthetic scenarios.

Observability. Monitor after launch. Agent behavior drifts as underlying data and prompts change, and uptime tells you nothing about whether the answers are still right.

This situation only makes sense if the appropriate people are in the room from the beginning. You should have involved the Salesforce administrators, the developers, IT, security, legal and compliance personnel, the data teams, and the marketers who will be using the system. Each of these groups identifies a risk that the others do not; security sees the access issue, legal identifies the consent issue, and the campaign manager notices the workflow which appears efficient on a slide but ends up causing two hours of extra work in reality.

That’s also how governance survives contact with reality. Policies are difficult to enforce when the people working around them don’t understand why they exist.

4. Where Agentforce fits in your marketing architecture

Agentforce isn’t a separate product bolted onto Salesforce. The direction of travel is an agentic enterprise where agents work alongside employees across sales, service, marketing, and operations, and Agentforce 360 pulls agent capability together with the platform, data, and collaboration layers.

For a Marketing Cloud team, the practical question is where the agent sits relative to everything you already run. Map the connections explicitly:

• Marketing Cloud Engagement, and which business units are in scope
• Data Cloud, and whether agents are grounded in unified profiles or in raw Data Extensions
• Sales and Service Cloud, where campaign context and customer history diverge
• Journey Builder and Automation Studio, and which automations an agent may touch
• Slack, for approvals and human-in-the-loop checkpoints
• Flows, Apex, and REST/SOAP API integrations
• External systems: CDP, ecommerce, loyalty, analytics

You have no need to redesign the environment, but it is necessary to know in what part of it the agent is situated and which of those connections is the first one to break.

5. If you’re weighing Marketing Cloud Next

This is the question which we are being asked most frequently at the moment. Does Agentforce alter the migration calculus?

Well yes, but not in the way that most people think. Agentforce doesn’t necessitate MC Next, and there’s little merit in carrying out a migration just in order to enable agents. It is true that the work involved is shared; data model cleanup, consent architecture, integration rationalization, and governance design are all prerequisites for both options. The teams currently carrying out the readiness work are not having to decide between the two; instead, they are carrying out the basic preparatory work required by either route.

What’s important is the order in which things are done. In the case where a migration is already planned for the next 12 to 18 months, developing agents for your existing architecture would involve doing it twice. But if it isn’t already planned, then there’s no need to delay.

6. Measure marketing outcomes, not agent activity

The purpose of deploying an agent isn’t to generate more conversations or complete more requests. It’s to improve the marketing operation. Conversation volume, response time, and request counts may look good on a dashboard, but they don’t tell you whether the investment is creating meaningful value. Measure the change in the work and outcomes the agent was introduced to improve:

• Time-to-campaign. Are campaigns getting from brief to launch faster?
• Campaign productivity. Is the team able to execute more campaigns or programs without adding headcount?
• Workload shift. Is the team spending less time finding, reconciling, and assembling information, and more time on strategy, creative, and optimization?
• Adoption and completion. Are marketers actually using the agent, and can it complete the tasks it was designed to handle without unnecessary human intervention?
• Quality and risk. Are errors, escalations, incorrect audience selections, or compliance issues staying within an acceptable range?
• Business performance. Where the agent influences customer-facing activity, can you connect its contribution to outcomes such as conversion, engagement, revenue, or retention?

Set the baseline before you roll out. If you don’t know how long a campaign takes today, how much manual effort it requires, or how often errors occur, you won’t be able to demonstrate that the agent made the operation better.

The real cost of skipping this

Agentforce pilots usually do not fail in an obvious way; instead, they fail by never being used.

The agent is created, shown to senior management, after which the campaign team starts asking one another on Slack, since the agent’s answers were correct frequently enough to be noteworthy and incorrect frequently enough to fail to be trusted. No one takes the matter any further. The license is renewed and the pilot never really finishes and never really turns into anything.

What separates the teams that get past that isn’t better prompts or a bigger deployment. It’s that they treated data quality, permissions, and action boundaries as the project rather than as prerequisites to the project. The agent was the last thing they built, not the first.

None of the work above is exotic. Most of it is the SFMC hygiene your team has been meaning to get to for two years: the duplicate Data Extensions, the consent logic nobody’s documented, the integrations held together by one automation and a lot of goodwill. Agentforce doesn’t create those problems. It just removes your ability to keep working around them.

Which is the useful thing about this moment. For the first time, the case for fixing the foundations has a number attached to it.