Building an AI Email Agent with Agentforce + MCP: From 3 Hours to Minutes

Traditional email marketing production is painful. A single email build involves three teams — creative, email development, and marketing — across six manual handoffs, takes 3 to 6 hours of hands-on build time per email, and often stretches one to two weeks from brief to launch. Devin Gisonno, Under Armour's Global Salesforce Marketing Cloud Lead Architect, broke this process with an AI email agent — drop an email design image into Agentforce, and within minutes you get a fully rendered email.

She first shared the project at Dreamforce, then broke down the technical implementation in detail during an online event hosted by the Prague Salesforce Marketing Cloud Community Group. What makes this project unusual: it connects Marketing Cloud Engagement (not MC Next) with Agentforce through an MCP server — a setup that was rare at the time.

Pain points of the traditional email production workflow

In her talk, Devin laid out the full existing pipeline: the team first receives creative handoff files, design mockups, and campaign briefs; after collecting all metadata, email developers build content in Content Builder using HTML, CSS, and AMScript. Depending on the number of assets, this typically takes several days. Then come three to six rounds of content updates and QA reviews before final approval.

The whole process spans three teams and six manual handoff points. Hands-on build time per email ranges from 3 to 6 hours, and the timeline from brief to campaign launch ranges from days to weeks. Devin's verdict was blunt: engineers were spending too much valuable time on repetitive tasks — exactly where an AI agent can step in.

How the AI email agent works

The agent's core logic isn't complicated: the user uploads an email design image to Agentforce, fills in basic campaign metadata (email name, subject line, preheader, and links), and the agent gets to work.

The agent reads the uploaded image, cross-references it against the pre-built Content Block inventory in Marketing Cloud Engagement (reusable content blocks and content fragments), and maps each block to the corresponding area in the image. Devin emphasized that this system relies on Salesforce Marketing Cloud's Content Block Catalog — context supplied to the agent through the MCP server.

Once mapping is complete, the agent generates the content block structure for human confirmation. In the demo, Devin reviewed the formatting, approved it, and prompted the agent to create a draft and send a test email via Agent Test. The system uses a test Data Extension configured in Marketing Cloud Engagement to send the test email to designated recipients, generates a browser preview link, and returns it to the agent. Finally, the fully rendered email can be previewed directly inside the Agentforce app — all steps handled through APIs.

According to Devin, the entire build used Factory AI as the AI application orchestration platform, which connects all major AI models including Claude and ChatGPT.

How the MCP server bridges both platforms

Architecturally, the most notable aspect of this project is the MCP server acting as a bridge between Marketing Cloud Engagement and Agentforce.

Devin explained in her talk that she connected the MCE MCP server on the Marketing Cloud Engagement side and the Salesforce MCP server on the Salesforce side. All content blocks, shared content blocks, test Data Extensions, tracking, and rendering data live in Marketing Cloud Engagement, while agent orchestration and execution happen on the Agentforce side.

The specific connection process: create an installed package in Marketing Cloud Engagement (she used the server-to-server mode), obtain the Client ID and Client Secret, and complete the authenticated connection through Factory AI. On the Salesforce side, she connected to a SIT sandbox environment and also integrated Salesforce Skills from Salesforce's GitHub repository, which enabled her to build the agent headlessly in Salesforce.

Devin noted that the entire project was built in sandbox environments — she created a UAT business unit in Marketing Cloud Engagement, and the agent was built in the Salesforce SIT environment, ensuring customer data would not be touched until everything was fully ready.

MCP (Model Context Protocol) is an open-source protocol standard proposed by Anthropic, designed to unify how AI models interact with external tools and data sources. In traditional architectures, every new data source or tool requires custom integration code; MCP standardizes the interface so AI agents can access external resources as plug-and-play as USB devices. In this project, MCP servers act as "capability providers": the MCP server on the Marketing Cloud Engagement side exposes marketing assets like content blocks, Data Extensions, and rendering data, while the MCP server on the Salesforce side provides agent orchestration and Agent Test capabilities. Agentforce acts as the "client," calling both servers via the MCP protocol — connecting two heterogeneous platforms without writing lots of glue code. This is why Devin emphasized that the project's approach of "bridging both sides through MCP servers" was uncommon at the time — the MCP ecosystem was still in its early days, with limited official and community servers available.

Two builds: lessons learned

Devin admitted she built the agent twice. The first failure had a specific cause: she tried to build on top of the existing architecture but didn't leverage reusable content blocks, which led to inconsistent agent responses.

The turning point came after Salesforce released the image upload feature for Employee Agent. Devin said this feature only became available weeks before Dreamforce, and it was precisely the combination of image upload plus Employee Agent that made her second agent truly work end-to-end.

During the first build, she had tried integrating Figma and campaign brief platforms through MCP servers to gather design and campaign information, but those MCP servers had limitations and couldn't fully achieve what she wanted. She spent about three and a half months figuring out the first agent; the second came together much faster because the context had already been built up.

This experience reveals a reality: the AI tooling ecosystem is still evolving rapidly, and today's limitations may be solved by tomorrow's features — but the experience gained from early exploration is never wasted.

Employee Agent is a type of agent in the Salesforce Agentforce platform aimed at internal employees, as opposed to Service Agent for end customers. It's typically used to empower internal teams with repetitive work like report generation, case handling, and content creation. The image upload feature Devin used allows users to feed design mockups directly to the agent as input, with the agent parsing layout and elements through multimodal capabilities. This feature became the turning point because, before its release, converting visual designs into structured content blocks required API integrations with external tools like Figma — integrations limited by the capabilities of MCP servers and unable to reliably extract design intent. Image upload lets the agent directly "see" the design mockup, bypassing intermediate steps and achieving end-to-end mapping from visual to code. This also explains why Devin's first agent still fell short after three and a half months of exploration — the problem wasn't the agent's logic, but the missing visual channel on the input side.

From sandbox to production: next steps

The agent's top optimization priority right now is global expansion. The current version was built for only one use case and one language, while Under Armour's business spans North America, Latin America, EMEA, and APAC — the team needs to extend the agent to all regions and languages.

Devin also mentioned broader integration possibilities: bringing in Data Cloud segmentation and Flow for dynamic personalization; using the Analytics MCP server to monitor journey performance after campaign deployment; and migrating journeys from Marketing Cloud Engagement to MC Next Flow. She has already started experimenting with using MCP servers to migrate a complete journey from Marketing Cloud Engagement to MC Next — while some things need to be reconfigured after migrating to Flow (because Flow connects to Data Cloud objects rather than Data Extensions), the core structure of the journey mapping can be migrated successfully.

Data Extension vs. Data Cloud objects are two different levels of data storage abstraction in the Salesforce marketing ecosystem. Data Extension is the native data table structure of Marketing Cloud Engagement, used to store send lists, personalization fields, and test recipients — a relatively flat model suited to email sending scenarios. Objects in Data Cloud (formerly Customer 360 Audiences) are based on a richer customer data model, supporting real-time segmentation, identity resolution, and cross-channel activation. When a journey migrates from Marketing Cloud Engagement to MC Next Flow, Flow connects to Data Cloud objects rather than Data Extensions, so personalization logic, send flows, and testing mechanisms originally configured on Data Extensions need to be remapped. Devin's point that "the core structure of the journey mapping can migrate successfully" means the journey's node logic and branching conditions can be preserved, but the underlying data bindings need to be rebuilt. This is also an architectural adaptation challenge companies commonly face when transitioning from MCE to MC Next.

Organizational rollout and knowledge transfer

When it comes to moving from a personal project to team collaboration, Devin's approach is worth borrowing. She plans to have Factory AI generate a complete Markdown file documenting all implementation details of the agent, then hand it to the development team to import into their own AI platform for analysis, building localized versions for each global region on that foundation.

Devin also addressed the discussion about permission controls during the event. She emphasized the need to work with administrators on both platforms, define roles according to the principle of least privilege, and develop and test in sandbox environments. She noted that Salesforce and Marketing Cloud have different DevOps lifecycle management approaches, requiring a complete end-to-end process before production deployment.

Devin — an architect with 13 years of Marketing Cloud experience — gave the project high praise. She said it's one of the coolest projects she's ever worked on and was surprised by how well the two platforms worked together. For teams wanting to get started, her advice: start with a sandbox, pick one or two use cases to play with, and gradually build up your understanding of what MCP servers can do.