One toolkit for everything your Org needs doing.
Single plugin for your coding agents: one MCP server, metadata graph database, playbooks. What changes is the size of the job you point it at.
What it is: a metadata graph database, skills and playbooks.
The metadata graph database is the as-built drawing. The playbooks are the schedule of works. An agent holding neither is just a sledgehammer with an opinion. Elements ships as an MCP server with the skills and sub-agents bundled in, rather than a bare set of APIs your agent has to learn.
Tools
The calls that read your Org: metadata, dependencies, permissions, change history, process. Grounded in the graph database, so answers are resolved rather than inferred.
Skills
How our architects use those tools. Which one to reach for, in what order, and what good looks like. A tool tells an agent what it can do. A skill tells it when.
Sub-agents and phases
Long jobs run in phases with isolated context and state written to disk, so hour six is as reliable as hour one, and a fresh agent picks up where the last one stopped.
Where the Org context comes from, and where it goes.
One place holds the model of your Org. One server exposes it. Everything else, including the tools your team already works in, asks that server rather than reading your Org itself.
with a change log
document
- Claude Code
- Cursor
- Copilot
- Agentforce
attached
One conversation, grounded in your actual Org, that can explain a component, assess a change and open the work item, without leaving the tool you were already in.
Same tools. Two very different sized jobs.
Most days you are answering questions about an Org that keeps moving. Occasionally you are taking on something that has been sitting in the too-hard pile for two years. Both are Org management. Both run on the same metadata graph database.
Managing change, day to day
The questions that used to become tickets, answered while you are still asking them.
- What does this field actually do, and who is using it
- What will this change break, resolved rather than guessed
- Who can see and do what, across profiles and permission sets
- What changed last week, and who changed it
- Requirements and user stories, validated against the real Org
The projects you have been avoiding
The programmes that never make it onto the backlog, because each one is two quarters and an SI.
- Post-acquisition Org merges
- Data migrations, and core to Education or Revenue Cloud moves
- Unpicking Steelbrick CPQ and years of accumulated debt
- A SOX or compliance audit you can pass without a fire drill
- Agentforce readiness, which is mostly the debt work anyway
The difference is duration, not toolkit. A daily question is one skill and a few seconds. A merge is dozens of skills, sequenced, running for hours with the phase state held on disk.
And this is what answering them costs you today.
Not a feature list. These are the eight things a Salesforce architect gets asked in a normal month, what it takes to answer each one honestly right now, and what you stop doing.
| What you get asked | How you answer it today | What you stop doing |
|---|---|---|
| "If I delete this field, what breaks?" | Grep the repo. Query MetadataComponentDependency, still beta at v67, 2,000 records a query, direct dependencies only, no reports. Reports are not source-controlled, list views live inside object metadata, and managed package components cannot be retrieved at all. Two days, and you are still not certain. | Guessing, then finding out in production |
| "Who can see this data, and why?" | Export every profile and permission set, cross-reference by hand in a spreadsheet, six weeks, and nobody quite trusts the result including you. | Rebuilding the same spreadsheet every audit |
| "What does this flow actually do?" | Open it. Trace it. Open the three subflows. Find the Apex it calls. Read the Apex. Discover it fires a second flow on update. | Reverse-engineering code to answer a business question |
| "What changed last week, and who did it?" | Setup Audit Trail gives you six months, no metadata detail, and nothing about why. Then you ask around. | Reconstructing history from people's memory |
| "Which of these 400 fields is anyone using?" | Sampled analysis, or a field trip through page layouts and reports. You get an answer that is directionally right and not defensible. | Sampling, and calling it coverage |
| "What is safe to delete?" | Nobody can prove it, so nothing gets deleted, so next year there is more of it. | Carrying debt because removing it feels riskier than keeping it |
| "Is this Org ready for Agentforce?" | An opinion, formed by whoever knows the Org best, who is usually the person about to leave. | Grounding an agent on metadata nobody has checked |
| "Can you write up this change?" | An hour a story if you are quick, then rework when the impact turns out to be different from what you assumed. | Writing stories that do not survive contact with the Org |
You do not need an AI agent to use any of this.
The metadata graph database, the skills and the playbooks are the product. MCP is one of the ways you reach them, and it is the newest one. Most of our 1,500 teams have never opened Claude Code.
The app
Metadata dictionary, dependency trees, process diagrams, permissions explorer, change logs. Point and click, no agent involved, and this is what most customers use every day.
The Chrome extension
Answers next to the Setup screen you are already looking at, so you do not context-switch to ask what a field is used for.
The MCP server
For teams already living in Claude Code, Cursor or another MCP client. Same graph database, same skills, reached by typing instead of clicking.
Agentforce
Ground your own agents on the same resolved model, so their answers are based on your actual Org rather than on a guess at it.
Pick the one that matches how your team already works. Nothing here is agent-only, and adopting the MCP later does not mean redoing anything.
Nine Salesforce engagements, composed from the same skills
These are not separate products. Each one is a sequence of the skills above, in the order our architects run them. A permissions audit and a post-merge rationalisation share most of their skills and none of their sequence.
Org discovery
A baseline nobody has had before: structure, automation, tech debt, compliance and governance, ranked by risk.
Agentic roadmap
Where agents actually pay off, scored by effort and impact, with the topic specs drafted before anything is built.
Impact assessment
Every dependency for a proposed change, resolved rather than inferred, with the blast radius sized.
Org merge / split
Two Orgs reconciled after an acquisition, or one separated cleanly, with the conflicts surfaced first.
CPQ to Revenue Cloud
Steelbrick unpicked, calculation order surfaced, and the migration path mapped before you commit.
Data Cloud set-up
The metadata and process picture Data Cloud needs, established before the implementation starts.
Data corruption
Find where the data went wrong, trace it back to the automation that did it, and stop it recurring.
Access audit
Every Profile, Permission Set and Group traced to what it grants, in a form legal will accept.
Clean up and agentify
Remove the debt, recover the process, then build the agents on something that is actually true.
Every capability, on its own page
If you want the detail on any one of these rather than the whole picture, each has its own page.
See it running against a real Salesforce Org.
The demo agent is signed into a connected Elements Org. Ask it about the job you are actually facing.