Here is what happened. For the last two years, the entire Salesforce ecosystem has been sprinting toward AI. Agentforce. Einstein. Data Cloud. Copilots. Agents. The C-suite heard “AI” and approved budgets. The implementation teams heard “Agentforce” and started building agents.

Then they hit the wall.

The Agentforce agent could not find the right customer record because the same person existed as three different Contacts with slightly different email addresses. The Einstein prediction model produced nonsense because 30% of the Opportunity Amount fields were blank or contained placeholder data. The Flow that the agent triggered to process a return also triggered a deprecated Process Builder on the same object, which fired an Outbound Message to a URL that no longer existed, which threw 47,000 errors overnight.

These are not AI problems. They are technical debt problems. And they have been building quietly for years, waiting for something complex enough to expose them. AI is that something.

Not all technical debt is created equal. Some slows you down. Some blocks AI adoption entirely. Some leaves you vulnerable to a data breach. I categorize Salesforce technical debt into five layers, ordered by how directly each one undermines AI readiness.

I have a simple rule I apply in every org audit: run the test suite with seeAllData=false and see what breaks. In about 80% of the orgs I review, at least one critical test class relies on production data to pass. That means it is not actually testing the code. It is testing whether a specific record still exists. The moment someone deletes that record, the deployment pipeline breaks.

But code debt goes much deeper than bad tests.

The Four Code Debt Patterns That Block AI

// REAL EXAMPLE: This trigger exists in more orgs than I care to admit.
// It works perfectly... for 1 record. It hits governor limits at 50.

trigger UpdateAccountRating on Opportunity (after update) {
    for (Opportunity opp : Trigger.new) {
        // SOQL INSIDE A LOOP. This is the #1 governor limit violation.
        Account acc = [SELECT Id, Rating FROM Account
                        WHERE Id = :opp.AccountId];

        // Hard-coded Record Type ID. Breaks in every environment except prod.
        if (opp.RecordTypeId == '012000000000ABC') {
            acc.Rating = 'Hot';
            update acc; // DML INSIDE A LOOP. Second governor limit bomb.
        }
    }
}
Apex · Anti-Pattern (Real Example)

I audited an org last quarter that had, on the Opportunity object alone: 4 Apex triggers, 3 Process Builders, 2 Workflow Rules, and 6 Record-Triggered Flows. Some of them did the same thing. Some conflicted. Nobody had a complete map of what happened when an Opportunity record was saved.

This is automation debt. It accumulates when teams build new automations without retiring old ones, when Salesforce releases new automation tools (Flows) without automatically migrating the deprecated ones (Process Builders, Workflow Rules), and when multiple admins build solutions in parallel without coordinating.

I will say this as directly as I can: you cannot run clean AI on dirty data. It does not matter how good the Agentforce agent is, how well you configure your topics and instructions, or how much you spend on Data Cloud licenses. If the data underneath is fragmented, duplicated, incomplete, or stale, the AI will produce outputs that are confidently, persuasively wrong.

Data debt is the most dangerous form of technical debt for AI because it directly corrupts the grounding that makes AI agents useful. When Agentforce queries a unified customer profile in Data Cloud, it trusts that profile. If the profile merges three duplicate Contact records with conflicting email addresses and phone numbers, the agent does not know which one is correct. It picks one. Sometimes it picks the wrong one. And the customer gets a response addressed to the wrong name, referencing the wrong order, sent to the wrong email.

The Data Debt Inventory

Open any Salesforce org that has been running for more than five years and go to the Object Manager. Count the custom fields on the Account object. I have seen orgs with 400+ custom fields on Account. At least 150 of them had 0% population. Nobody knew what they were for. Nobody was willing to delete them because “maybe someone uses that for a report.”

Configuration debt does not crash your org. It does not throw errors. It silently increases cognitive load for every admin, developer, and AI agent that has to navigate your data model. When Agentforce tries to determine which fields are relevant to answer a customer question, a clean object with 30 well-named fields is a simple problem. An object with 400 fields, half of them blank, many with ambiguous names like Custom_Flag__c and Legacy_Status_Old__c, is a much harder problem for any reasoning engine.

In 2025, a series of coordinated cyberattacks targeted Salesforce customers through malicious connected applications and social engineering of admins. Customer data was exfiltrated. Org secrets were compromised. Several ISV partner orgs were temporarily disabled from accessing Salesforce entirely. The breaches exposed a painful truth: most orgs had security configurations that were years out of date.

AI compounds the security problem. Agentforce agents run as a specific user in your org. They inherit that user’s profile, permission sets, and field-level security. If your permission model is overly broad (which most are, because restricting permissions is tedious and nobody prioritized it), then an AI agent has access to data it should never see. A customer-facing service agent that can read the Annual Revenue field on Account, or the Discount Percentage on Opportunity, is a data leak waiting to happen.

Three Security Fixes Before You Deploy Any AI Agent

I have watched companies spend six months building an Agentforce agent, only to discover at launch that the agent could not reliably identify which customer it was talking to because the Contact database had 30% duplicate records. I have seen Einstein forecasting models produce absurd pipeline projections because half the Opportunity Amount fields contained placeholder values from a 2019 data migration that nobody cleaned up.

The pattern is always the same. The AI is fine. The data is not. The automations are not. The security model is not. The org was built for a world where a human could look at a messy record and use judgment. AI does not have that luxury. It trusts the data. It trusts the permissions. It trusts the automation output. If any of those are wrong, the AI is wrong too, with total confidence.

Run the audit. Fix the foundation. Then deploy the AI. That order matters more than any other architectural decision you will make this year.