Your agentic operating level in Salesforce

Watch a Salesforce team run an agent-heavy sprint and ask one question afterward: where did the humans actually spend their attention? Most teams will find the answer uncomfortable. It went to the plan. The user story, the acceptance criteria, the Jira ticket. Then someone hands the story to an agent and checks the result the way a vibe coder does. They click through the org. Does the flow fire? Does the LWC render? If not, they re-prompt and click again.

The idea has a name in agentic engineering circles: the agentic operating level. Once you see it, you can’t unsee it in Salesforce work. An operating level is the altitude where you and your agents focus. The ladder runs from lines of Apex code at the bottom to the software factory at the top. Where you sit decides how much leverage you get and how much control you keep. Moving up trades control for speed. Moving down trades speed for understanding. Neither direction is “better.” The skill is knowing which one the problem in front of you calls for.

The ladder, translated

The framework lists about sixteen levels in five bands. Here is the same walk, band by band, on the Salesforce platform.

• Foundations. Lines, blocks, functions, types, and classes become Apex statements, SOQL queries, trigger handlers, classes, and custom metadata types.
• Code structure. Files, modules, and directories become the sfdx project layout, LWC bundles, meta.xml files, and permission set grouping.
• Data and execution. Databases and tables become the object model: objects, fields, relationships, record data, org shapes.
• Scripts and CLIs. Automation scripts and command-line tools become sf CLI commands, scripts/ automation, and CI jobs in GitHub Actions or Code Builder.
• Delivery and intent. Deployments and package management become metadata deployments, package.xml, change sets, pipelines, and validate deploys.
• Application. The running product is the org as users experience it: Lightning pages, flows, Agentforce conversations.
• Repository. The multi-app monorepo becomes the org strategy: production plus sandboxes, managed packages, multiple projects behind one org.
• Plan. Implementation plans become user stories, design docs, and statement-of-work sections.
• Documentation. Recorded knowledge becomes org documentation, architecture decision records, and runbooks.
• Agentic system. Agents, ADWs, and the software factory become your agent harness on the sf CLI, Agentforce agents in the product, and composed delivery workflows.

Two observations about this walk matter more than the rest.

First, the plan level is unusually strong in Salesforce. The platform is declarative, the metadata is machine-readable, and a capable agent can generate flows, permission sets, and Apex classes from a good plan. That is exactly why so many teams now live at the plan level. It works. Until it doesn’t.

Second, the data level deserves more attention than most Salesforce teams give it. The argument goes that the valuable thing you’re building is your relationship with your users, and the form that takes is data. In Salesforce that has always been true. The object model is the product. A wrong relationship or a text field doing a lookup’s job outlives every flow and class that touches it.

Higher is not better

The sharpest warning in this framework is aimed at people rushing upward, and the facts are blunt: you cannot scale something you do not understand. An engineer who goes straight to building software factories, with no idea what the tables look like or how the system is organized, ends up somewhere bad.

For Salesforce teams this warning has a specific shape. The org knows things you don’t. There is a trigger handler that runs in an order someone chose for a reason in 2021. There is a custom setting that flips behavior in prod but not in the sandbox. There is a managed package that owns a field your agent just tried to write to. An agent operating at the plan level doesn’t see any of that. Neither does the human who only reads the plan.

Moving up also feels like becoming a lead, and I mean that as more than an analogy. A team lead gives up direct control of every line in exchange for output through other people. An architect operating at the plan and documentation levels makes the same trade with agents. The same rule applies in both cases: the trade only pays when you understand the work you delegated.

When to move up

The criteria for gaining leverage map cleanly onto Salesforce delivery.

The work is familiar and repeated. The rule of three applies hard here. The third CRUD screen for a third object, the fourth field-migration script, the fifth permission set update, yet another flow. If you’ve done it twice, the third time should trigger a question. Should this be a reusable workflow with agents and code attached to it?

The evidence is machine-checkable. Salesforce hands you something rare: an objective fitness function. A feature is done when the Apex tests pass, coverage clears the bar, and the deployment validates against the target org. Only thing left is the visual verification within the UI. You don’t have to argue about whether the agent succeeded. Run sf apex run test and read the result. That single fact makes the Salesforce ecosystem unusually good territory for agentic delivery.

You hold the domain skill. Governor limits, order of execution, sharing and visibility, the metadata model. If those are things you can reason about without looking them up, you can supervise an agent doing the typing, and moving up multiplies you.

The artifacts multiply. Migrations, test data factories, documentation, QA checklists. When one unit of work fans out into many generated artifacts, leverage wins.

When to move down

Moving down buys control and understanding, and it costs you time. Five signals say the trade is worth it.

The org or domain is new. First week supporting a production org you’ve never seen is not the time to operate at the plan level. Read the trigger framework. Query the custom settings. Walk the sharing model yourself before you let an agent touch anything. You can’t judge outputs you don’t understand.

The stakes are high. Production deploys, customer PII, an AppExchange security review. Rockets and biomedical software are the canonical examples. A Fortune 500 org with eleven million records qualifies.

The debugging evidence is weak. This one hides in plain sight. If the agent reports success and you can’t say what success should look like for a given input, you have no fitness function. Go down until you can define one: write the test first, or at least know the expected SOQL result, before you let the agent claim victory.

Performance and details matter. SOQL inside a loop, unbounded queries, queueable jobs chaining past their limits. The Apex compiles either way, and the failure shows up months later under load. UI taste works the same way: every AI-generated interface is starting to look the same because everyone vibe-slops them, and default Lightning pages carry the same signature. When a customer-facing experience matters, someone with taste has to go down into the details.

The work is out of distribution for the model. The model doesn’t know it, avoids it, or actively gets it wrong. This is the most Salesforce-specific signal in the whole framework, and it gets its own section below. Out of distribution means what the model doesn’t know, or actively avoids because its training punished it. Salesforce work sits out of distribution in three distinct ways.

Runtime semantics. Models write Apex that compiles and then fails at scale. They put DML inside loops, ignore mixed DML restrictions, and treat governor limits as folklore. The code looks right. It is wrong in ways only someone who has been paged at 2am for a limit exception will catch.

Drift and retirement. Models trained on years of Salesforce blog posts still recommend Workflow Rules and Process Builder, both retired. Salesforce’s own APIs move every release. The search API recently dropped GET-based queries in favor of POST with a JSON body, and plenty of agent-generated integration code still uses the old shape. Release notes are part of your job now, because the model’s training data isn’t.

Your org. No model knows why that handler runs third, what that custom setting does in prod, or which integration owns that field. This is tribal knowledge, and it lives nowhere the agent can read unless you put it somewhere: a context file for your agent harness, org documentation, metadata annotations. Your job at the out-of-distribution boundary is to extend the model with your expertise. The framing that sticks: don’t collaborate with someone who doesn’t know what you’re trying to do. Either teach them or go down to a level where you don’t need to.

No shortcut up the ladder

The least surprising and most resisted point in this whole framing is that expertise has no replacement. You build it from the atoms, and the atoms for Salesforce are specific. SOQL and SOSL. DML and limits. Order of execution. The metadata model. Sharing and visibility. You can outsource the typing to agents. You can’t outsource the understanding, because every failure mode that matters shows up as a judgment call the model can’t make.

So the recommendation applies directly to Salesforce practice: ban vibe coding on anything long-lived. Prototypes and throwaway spikes, fine. If the org holds customer data and the release goes to production, you should know what the agent changed and why. At minimum, know your object model, your directory structure, and the function signatures in the handlers you own.

Build toward the factory, one workflow at a time

The ladder ends at the software factory: composed AI developer workflows that cover the delivery lifecycle, running lanes for hotfixes, prototypes, and support tickets without a human shepherding each one. The path there is agent first, then one workflow, then composition.

The Salesforce-specific insight is that the platform already validates your work for you. Tests, coverage, validate deploys, and Code Analyzer make a story-to-production pipeline machine-checkable end to end. Most ecosystems have to invent their fitness functions. Salesforce ships them. That makes the case for building the workflow now unusually strong: story in, plan out, plan to implementation, Apex test run, validate deploy, done. Get one lane working, then compose the next.

The takeaway

Leverage without control and understanding is meaningless. Move up when the domain is known, the work repeats, and the evidence is checkable. Move down when the org is unfamiliar, the stakes are high, or the model is guessing. Keep both directions available, and pick the level the problem calls for.

Here’s the challenge I’d leave you with. Open your last three user stories and locate your operating level honestly. If you spent all three at the plan level clicking through the org afterward, hoping you’ve found the bug to fix this sprint. Then decide deliberately: what would moving up look like, and what would moving down cost?