For years, routing customers in Journey Builder meant wiring up frozen if/then branches: if purchase count is greater than three, send them down Journey A, otherwise Journey B. It worked, but it was brittle. Marketing Cloud Next changes the model with the Journey Decisioning Agent, an Agentforce-powered agent that picks the best journey for each contact in real time, based on their unified profile in Data 360. In this guide you will see how the agent makes its calls, how to prepare your data so it decides well, how to wire it into existing journeys, and which guardrails to keep before you hand orchestration over to AI.
From rule-based branching to agentic decisioning
Conditional branching has a structural flaw: it freezes business logic at a single point in time. Every new exception (a VIP segment, a region, a preferred channel) means another branch, and the journey quickly becomes unmanageable. The Journey Decisioning Agent flips the logic. Instead of describing how to route, you describe what outcome you want, and the agent selects the most relevant candidate journey.
In practice, the agent weighs the contact's attributes, recent behavior, engagement trends, and whatever context lives in Data 360, then assigns each contact to the journey most likely to drive engagement. The decision is recalculated on every entry, not locked in once when the journey starts.
What changes for ops teams
You stop maintaining dozens of branches. Instead you maintain a small pool of well-built candidate journeys and a clear definition of the goal. The agent handles the rest. That shifts the work away from segmentation plumbing and toward data quality and journey design, which is exactly where it belongs.
Preparing your data in Data 360
An agent is only as good as the data it reads. Before you activate anything, make sure your unified profiles expose the signals that matter: purchase recency, engagement score, subscription status, preferred channel. Here is a sample SQL query that builds an eligibility Data Extension to feed your candidate journeys.
SELECT
c.SubscriberKey,
c.PreferredChannel,
e.EngagementScore,
p.LastPurchaseDate,
CASE
WHEN p.LastPurchaseDate >= DATEADD(day, -30, GETDATE()) THEN 'active'
WHEN p.LastPurchaseDate >= DATEADD(day, -90, GETDATE()) THEN 'lapsing'
ELSE 'dormant'
END AS LifecycleStage
FROM Contacts c
JOIN Engagement e ON e.SubscriberKey = c.SubscriberKey
JOIN Purchases p ON p.SubscriberKey = c.SubscriberKey
WHERE c.OptInStatus = 'subscribed'The LifecycleStage field does not dictate routing; it hands the agent one more signal to reason with. The cleaner and fresher your signals, the more trustworthy the decisions.
Triggering a decision through the API
The Journey Decisioning Agent plugs into your systems over a REST API. When a business event fires (an abandoned cart, a status change, a support interaction), you call the decision endpoint with the contact's context and get back the chosen journey.
POST /services/data/v62.0/marketing/decisioning/journey
Content-Type: application/json
Authorization: Bearer {access_token}
{
"subscriberKey": "0031t00000abXyZ",
"context": {
"event": "cart_abandoned",
"cartValue": 189.90,
"preferredChannel": "email",
"lastEngagementHours": 4
},
"candidateJourneys": ["winback-vip", "winback-standard", "nurture-low-intent"]
}The response names the selected journey and a confidence score, so you stay in control: you can log every decision, audit it, and replay it when needed.
{
"selectedJourney": "winback-vip",
"confidence": 0.82,
"reasonCodes": ["high_cart_value", "recent_engagement"]
}The real shift is not that AI decides for you. It is that it decides at every moment, for every contact, with context your hand-built branches could never have modeled.
Staying in control: governance and guardrails
Handing orchestration to an agent does not mean giving up control. Three guardrails are non-negotiable.
1. A small, explicit set of candidate journeys
Do not let the agent choose from fifty journeys. Start with three to five clearly differentiated candidates. You cut the risk of bad calls and make the decisions far easier to analyze.
2. Non-negotiable suppression rules
Some exclusions are not up for debate: unsubscribes, contacts in dispute, frequency caps already hit. Enforce them upstream of the agent, never as just another signal in the mix.
3. Systematic logging
Store every decision (selected journey, score, reason codes) in a dedicated Data Extension. It is your safety net for debugging, GDPR audits, and continuous improvement.
UPDATE DecisionLog
SET SelectedJourney = @journey,
Confidence = @score,
DecidedAt = GETDATE()
WHERE SubscriberKey = @subscriberKeyWhere to actually start
There is no need to convert every journey at once. Pick one high-stakes, well-instrumented use case: abandoned-cart winback is ideal. Build two or three candidate journeys, define the goal (conversion within seven days), turn the agent on for a slice of your audience, and compare its decisions to your historical logic for a few weeks before you scale.
If you want help framing your data model, designing candidate journeys, or setting up governance, talk to the CGC-Agency team.
Measuring and improving over time
A decisioning agent is not a set-and-forget switch. Its value compounds inside the feedback loop: every logged decision becomes a learning signal. Track three metrics first. Start with conversion rate per candidate journey, to confirm the agent really does favor the journeys that perform. Next, watch the distribution of decisions: if 95% of contacts land in a single journey, your candidates are poorly differentiated or your signals are too thin. Finally, measure the gap against your historical logic, which surfaces the cases where the agent sees something your rules missed.
Review these numbers with your business team every week during the pilot. Adjust the candidate pool, enrich the missing signals, tighten suppression rules where needed. It is that regular dialogue, not the agent on its own, that produces genuinely adaptive journeys.
Key takeaways
1. Continuous decisions, not frozen branches. The Journey Decisioning Agent recomputes the best journey on every entry, from the real-time profile in Data 360.
2. Data comes first. Decision quality depends on the freshness and cleanliness of your unified signals, so invest in Data 360 before you activate the agent.
3. Keep the candidate pool small. Three to five well-differentiated journeys are enough to start and keep decisions analyzable.
4. Keep your guardrails. Suppressions, frequency caps, and logging stay under your control, never delegated to the agent.
5. Pilot by use case. Start on one high-stakes journey, benchmark against your current logic, then scale.
