Building a Salesforce Agent Using Model Context Protocol on AWS ECS
When integrating Salesforce with conversational interfaces like WhatsApp or Email, the challenge isn't just in exposing APIs — it's in orchestrating user interactions, managing authentication, and executing dynamic actions intelligently. This blog dives into how we implemented a working solution using Model Context Protocol (MCP) hosted on AWS ECS, enabling a Salesforce agent that talks to users via WhatsApp or Email and takes actions on their behalf — using remote tools over streaming HTTP.
Problem
Salesforce APIs require OAuth2 authentication, and most users interacting via chat/email won't be logged in in advance. We needed a system that:
Lets users interact with Salesforce from channels like WhatsApp or Email. Authenticates users only when needed. Stores and reuses tokens securely. Reads and writes data in Salesforce in real time. Uses modular tools to separate execution from orchestration.
Architecture Overview
Key Components:
Channels: WhatsApp & Email – user entry points. Salesforce Agent (Lambda): Receives user messages, manages session state, constructs logic, and invokes remote tools. OAuth2 Callback (Lambda): Stores Salesforce tokens after user login. Token Store (DynamoDB): Centralized place for token/session state. MCP Server (ECS): Hosts all tools and exposes them via streaming HTTP protocol. Salesforce: The backend system being queried and updated.
Streaming HTTP with MCP: Remote Tools, Local Logic
The MCP Server running on AWS ECS exposes tools like OAuth2, SOQL, and REST as remote, streaming-enabled services over HTTP. These tools are not smart — they don't reason or infer anything. Instead, they are execution environments for agent-generated logic.
Clarification: The agent itself constructs all SOQL queries and REST parameters. The tools do not generate queries. Their job is to run the agent's logic, not to create it.
This keeps the tools simple, composable, and interchangeable — and ensures that all the decision-making and contextual logic lives inside the agent.
Execution Flow
A user sends a message via WhatsApp or Email. The Salesforce Agent (running as an AWS Lambda) receives the message and checks the user's session/token in DynamoDB. The agent creates a SOQL query or REST payload based on user intent, and sends this logic to the remote tool via the MCP streaming HTTP protocol. If the user isn't logged in, the agent calls the OAuth2 tool to generate a login URL and sends the login link back to the user. When the user logs in, Salesforce redirects to the OAuth2 callback Lambda, which stores the token in DynamoDB. The next request proceeds with full access, and the agent continues issuing queries/actions.
Design Benefits
Agent constructs the logic: Tools don't generate queries — they just run what the agent sends. Channel-agnostic: Works seamlessly across WhatsApp, Email, or future channels. Streaming-enabled remote tools: Tools scale independently and communicate in real time. Stateless Lambda agent: All context is either stored or passed via messages — no memory between invocations. OAuth2 flow is on-demand: Only triggered if token is missing or expired.
Summary
This architecture shows how you can build a robust, intelligent Salesforce agent that works across messaging platforms — with a decoupled, scalable backend. By offloading tool execution to ECS using MCP over streaming HTTP, we've created a clean separation of concerns:
The agent thinks and plans. The tools execute. Everything is modular and composable.
If you're building complex backend agents for enterprise apps — this pattern is worth replicating.