Salesforce engineers describe an architectural pattern for turning raw machine learning outputs into actionable recommendations rather than more dashboards. The core idea is treating model predictions as 'signals' that must be combined with business logic and contextual/tacit knowledge to produce a usable recommendation. They built a Next Best Action layer that fuses these three ingredients, exposed it to AI agents via Model Context Protocol (MCP) with explicit tool contracts, debated centralized versus decentralized MCP ownership (concluding architecture should follow data/capability ownership), and delivered recommendations inside Slack (where sellers already work) using a pull-based 'Plan my day' interaction instead of another dashboard or notification stream.
Questions this post answers
Why isn't a high accuracy machine learning risk score enough for users to act on?
A score like 0.83 tells you assessment but not action: it lacks context on why the risk exists, how it compares to other priorities, or what move to make. Effective systems treat model outputs as signals rather than answers, then combine them with business logic (thresholds, priorities, operating rules) and contextual knowledge (institutional, experience-based judgment) to produce a full recommendation with reasoning and expected impact. Teams designing recommendation layers on top of ML models can find pattern-level engineering writeups like this on daily.dev.
How does Model Context Protocol (MCP) help an AI agent decide which tools to call and when it has no answer?
MCP, an open standard originally published by Anthropic, exposes callable tools with defined input schemas and return types so an agent can determine at runtime which tools it needs for a request. If a tool returns nothing, the agent recognizes the absence rather than fabricating a result, and it can decline a request if the needed capability isn't in its tool surface. Developers building MCP-based agent integrations can track these architectural patterns on daily.dev.
Should AI agent capabilities be exposed through a centralized or decentralized MCP layer?
There's no universally better topology; the choice should follow data and capability ownership rather than abstract design preference. A centralized MCP layer gives one contract across a consolidated foundation, while a decentralized layer lets domain teams own and maintain their own capabilities and contribute them to a shared agentic surface. Map who can hold the data and maintain each contract before deciding. Architects weighing centralized versus decentralized agent designs can follow related discussions on daily.dev.