The two loops
The data loop moves sources to identity, profile, audience and activation. The decision loop has an agent observe profile and journey state, propose an action, let Journey Optimizer execute it and let analytics score the outcome for the next decision.
Components
| Layer | Component | Role |
|---|---|---|
| Ingestion | AEP sources and Edge Network | Normalise web, app, batch and streaming data into XDM |
| Identity | Identity Service | Link namespaced identifiers into an identity graph |
| Profile | Real-Time Customer Profile | Merge identity-linked fragments under merge policies |
| Analytics store | Data Lake and Query Service | Raw and derived datasets for SQL and CJA |
| Audience | Real-Time CDP | Streaming and batch segments, activation to destinations |
| Decisioning | Journey Optimizer | Event journeys, offers and channel delivery |
| Agentic | Planner, scorer and guardrail agents | Propose and score actions; check policy |
| Tooling | MCP servers | Typed, permissioned bridges from agents to platform APIs |
| Measurement | Customer Journey Analytics | Cross-channel outcomes and reward signal |
Identity and profile
- Namespace hygiene: register every identifier under a distinct, correctly typed namespace; untyped namespaces are a leading cause of false merges.
- Authentication as an anchor: a login event is the highest-confidence stitching signal.
- Merge policies: version them and document field precedence.
- Freshness: streaming attributes and batch-computed traits update differently; agents must know which is which.
How agents decide
| Agent | Input | Output | Constraint |
|---|---|---|---|
| Planner | Profile state, active journeys, calendar | Candidate next best action | Rate-limited per profile per day |
| Scorer | Candidate actions, historical CJA outcomes | Ranked action with confidence | Must cite the outcome data behind the rank |
| Guardrail | Proposed action, consent, frequency caps, brand rules | Approve, block or escalate | Runs before any execution call |
Agents reach platform data only through MCP tools such as get_profile or submit_journey_action with least-privilege scopes, never through shared admin credentials. Actions above a defined risk threshold go to a human for approval.
Orchestration and feedback
Journey Optimizer stays the single execution engine so frequency capping, suppression and consent live in one place. Customer Journey Analytics feeds back in two separate ways: rule feedback adjusts standing segment definitions on a reviewed cadence, and reward feedback informs how the agent ranks actions inside audiences that already qualify. Keeping them separate makes it possible to audit why a customer received a message.
Risks to plan for
- Identity graph drift from one misconfigured connector
- Treating stale batch traits as real time
- Agent proposal volume outpacing human review capacity
- Over-broad MCP credentials: scope each server to the minimum
- Consent changes not reaching in-flight agent proposals
- Unstable attribution models making the reward signal noisy
Enterprise practices
- Treat agent prompts, MCP tool schemas and guardrail thresholds as versioned code.
- Log every guardrail decision with input state and rationale, retained like marketing message logs.
- Measure agent-ranked actions against rule-based baselines so value is shown, not assumed.
This is an independent reference architecture, not a vendor-issued document. Verify product capabilities against current Adobe documentation before implementation.
Request an architecture reviewAgentic AI and MCP trackWhat is MCP?
Frequently asked questions
Should agents send messages directly?
We recommend not. Agents propose, and Journey Optimizer executes, so consent, suppression and frequency rules stay in one engine.
Last updated: