Agentic coding tools have changed how people work with software. Claude Code and Cursor are becoming the one interface people sit in all day, with email, Slack, Jira, and Salesforce behind them through MCP servers. But connecting a server is not the same as ‘agentifying’ your work, and the gap between the two lies in building or installing custom workflows.
That gap matters now for one reason: the teams that crack the autonomous org analysis, build and deploy lifecycle will outcompete and outclass the competition. Projects that used to cost $500,000 and take 6-12 months can be delivered in days or weeks. And while your agents need access to the right tooling, access is (almost) the easy part. We will break down what MCP servers give you, why workflows make agents useful at project scale, and what the last missing ingredient is to unlock autonomous org management.
What MCP Changed
Let’s start with what MCP is, because the acronym gets used more than explained. The Model Context Protocol is a standard way to plug a system into an AI model. A server exposes tools, the calls that read, write, or trigger, and resources, the context the model reasons over. Salesforce built theirs, and any agent that speaks the protocol can reach your org without a bespoke integration.
That is a real unlock: systems of record became directly queryable, with no interface to learn and no ticket to file. But ask an org with 900 flows and 40 profiles what a field is used for, and the answer comes back fast, confident, and incomplete.
Not all MCP servers are equal.
A tool tells an agent what it can do. It does not tell it when, in what order, or what good looks like. Skills and workflows carry that, and the protocol leaves them to the client. Which is where a good vendor steps in. Claude Code lets you ship a plugin rather than a bare server, so the MCP server arrives bundled with the skills and sub-agents that know how to drive it. One is a set of APIs you have to learn. The other turns up knowing how the work is done.
Most servers are still the first kind. Some ship prompt templates: Salesforce’s own hosted MCP servers went GA in April 2026 with them, alongside tools for Flows and Apex actions. That helps, but a prompt template is a canned question. Without workflows, every MCP tool becomes a one-step action. The agent does what you asked and stops. Nobody has told it what step two is. Or that there are a hundred steps for a particular job.
Why You Need Agentic Workflows
Coding Agents Run for Minutes. You Need Them Running for Hours.
Hand an agent a prompt, and it does the simple version of the job and stops. Thirty minutes, maybe an hour. For a permissions audit across 40 profiles and 200 permission sets, that is nowhere close, so you prompt and re-prompt your way through it. A tool sold as ‘autonomous’ still needs you in the chair all day. The gap opening up between practitioners is not talent – it is tooling.
Context Rot Is Killing Your Reliability
Context rot, a term Chroma’s researchers named, is the slow drop in quality when a model processes a long conversation or too much data. It loses the rules you set at the start, repeats mistakes, and gets distracted by detail that does not matter. A one-million-token window is a budget, not a memory.
Developers have largely mitigated this, and not with better prompts. Their orchestration layers enforce phase management, markdown state files that survive a restart, and isolated context windows for sub-tasks, so the noise of hour one never reaches hour six. Superpowers (obra/superpowers), GSD Core (open-gsd/gsd-core), and gstack (garrytan/gstack) are worth a look.
None of them knows anything about Salesforce. But they proved the unit of work is not one long conversation, and that part transfers.
What an Agent Can Do With the Right Context
Without a Dependency Graph, Your Agent Is Guessing
Take the question you get every week: what is the impact of deleting Region__c on Account, in an org ten people built over ten years? Point an agent at your repo, or at the Metadata API, and four minutes later you have an answer that reads complete: an Apex class, a validation rule.
It will miss the rest, for reasons unrelated to cleverness. Almost nobody source-controls reports, so the 14 that filter on the field are not in your repo; standard reports cannot be retrieved at all, and retrieval returns only the folders you name. The six list views sit inside object metadata. The managed package component reading it through an installed formula is not retrievable, full stop.
Then the harder problem. Name-matching is not dependency resolution. Region__c turns up in dynamic SOQL, in hardcoded IDs, in field names that collide across objects, and in a cross-object formula on Opportunity resolving two hops down through a lookup. A grep gives you candidates, and most orgs I come across have several. Not to mention that using LLMs to scan all Apex classes, flows, and other metadata will explode your budget and cost you a small fortune in token cost.
MetadataComponentDependency in the Tooling API gets you closer. It is also still beta at API v67.0, seven years in: 2,000 records per query, direct dependencies only, no reports. Salesforce archived its own CLI plugin in May 2025.
Deterministic, Not Probabilistic
Deleting Region__c is knocking out a wall. You can swing the sledgehammer and find out afterward which ones were load-bearing. An agent reasoning over a verified dependency graph behaves differently from one inferring meaning from raw metadata. That is a reliability argument, not a documentation one.
Building that graph is what Elements.cloud does. Every component in your org and every relationship between them, resolved rather than inferred, including the ones the APIs will not give you: reports, list views, the formula field two hops down, and full cross-org automation path tracing.
Alongside it, the change history and a model of who can see and do what. So when an agent asks what depends on Region__c, it gets an answer rather than a directory to interpret, with code size so large, it will inevitably rot your context window and leak important information from its memory.
Plugins, Not Prompts
A graph still waits to be asked. So we are packaging the method with it, as plugins: our MCP server bundled with the skills and sub-agents that know which tool to reach for, and in what order. Not one workflow but dozens, because a permissions audit and a post-merge field rationalization share skills but not a sequence.
Phases run in order: find every candidate reference to Region__c, resolve each against the graph, size the blast radius, draft the remediation. When a phase ends, its state is on disk, so a fresh agent picks up at phase three without hour one explained again. If it cannot resolve something, it says so rather than guessing.
Findings get re-checked against the graph before a human sees them, so what lands on your desk is evidence rather than assertion. Decisions that are yours wait for a named person, enforced in software. What legal receives is a dated impact assessment with a named approver. Nobody signs off a chat transcript.
The content of those workflows took a decade: how our architects and our customers unpick CPQ, merge two orgs, or rationalize fields after an acquisition, written down as instructions an agent can follow. Hundreds of years of combined Salesforce experience, encoded. You do not prompt your way to that on a Tuesday afternoon.
The Problems This Makes Tractable
The jobs that never get done. A post-acquisition merge, a permissions audit legal will sign, a data migration, or years of different people building in different ways and then leaving.
Why are those still sitting in your backlog? Cost, mostly. Each one is six figures with a consultancy, or six weeks of internal work that never survives an urgent quarter. So they queue, and the queue is measured in years. The permissions audit is the clean example: six weeks and a spreadsheet nobody trusts, or a run that starts on Friday and lands on your desk on Monday as evidence you can sign.
The Agentforce rollout then arrives on top of it, assuming clean data and automation somebody can explain. Grounding an agent needs what a well-architected org needs: accurate metadata, resolved dependencies, an access model somebody has read. Do the debt work and most of the Agentforce work is done. Skip it, and you are pointing an agent at the mess.
Final Thoughts
MCP gave agents access. Workflows tell them how the work is done. The last ingredient is the one you cannot prompt your way to: something true to work from. A sequence of phases cannot tell an agent what is in your org.
The method is the schedule of works. The graph is the as-built drawing. An agent with neither is still holding the sledgehammer.
None of this is a bespoke build or a consulting engagement. It ships in the product, exposed through our MCP server, so any Elements space can point an agent at it. Find our documentation here.
