Every Salesforce implementation has a moment where the team realizes they’re solving a problem that has been solved a hundred times before. The data migration goes sideways because someone forgot to normalize phone numbers. The trigger logic becomes a tangled mess across six files. The AI prototype works great in a demo but blows through governor limits the second it touches real data.

I’ve done this long enough that the pattern is obvious. Three categories of work eat 40-60% of the engineering time on every project, and they’re rarely unique to the org. They’re common problems with common solutions that get rebuilt from scratch each time because there’s no good open source option in the Salesforce world.

Salesforce just open-sourced Agent Script and shipped Agentforce 2.0 with MCP support and multi-model tooling. The direction is clear: AI agents are becoming the primary way enterprises interact with CRM data. But there’s a gap between Salesforce’s native tooling and what independent teams need to build their own agents that work alongside (or instead of) Agentforce.

So I packaged up the patterns that actually worked in production and put them on GitHub. Three repos. All free.

If you’ve tried building AI agents that read and write Salesforce data, you know the gap. LangChain and CrewAI are powerful general-purpose tools, but they have no concept of governor limits, field-level security, or Salesforce object relationships. You end up writing hundreds of lines of glue code to make a simple agent that can score a lead.

SAAF is a Python framework where agents are Salesforce-native from the ground up. They know about SObjects, SOQL, Flows, Platform Events, and the Bulk API. They track API call usage automatically. They enforce FLS. And they log every action to a custom SAAF_Audit_Log__c object so you have a full trail of what the agent did and why.

The MCP Server Changes the Workflow

The piece I’m most interested in is the MCP Server. With Salesforce now supporting MCP natively in Agentforce, the protocol is becoming the standard for agent-to-tool communication. SAAF’s MCP Server works the other direction: it exposes your Salesforce org as a set of tools for any MCP-compatible AI client.

In practice, this means you can open Claude Desktop, type “show me all opportunities closing this month over $50K with no activity in the last 14 days,” and Claude writes the SOQL, runs it against your org, and gives you the results. No code, no middleware, no integration platform.

Pre-Built Agents

The framework ships with three production-ready agents you can use immediately. Each one handles the common patterns (batch processing, error handling, audit logging) and lets you customize the business logic through configuration.

Here’s the thing about data migrations: they’re not technically hard. They’re operationally brutal. The source system stores phone numbers in 15 different formats. State names are sometimes abbreviations, sometimes full names, sometimes misspelled. The picklist values between HubSpot and Salesforce don’t match. And there are always duplicate records.

This toolkit handles the unglamorous work. You define your field mappings, attach transforms, set up validators, and run the whole thing in dry-run mode to catch problems before a single record touches Salesforce.

The Validation Layer is the Point

The transforms are nice. The templates save time. But the real value is the validation framework. It runs every record through your rules before anything hits Salesforce, and gives you a clear report of exactly what would fail and why.

PYTHONfrom crm_migrate.validators import (
    RequiredFieldValidator,
    EmailFormatValidator,
    FieldLengthValidator,
    DuplicateCheckValidator,
)

validators = [
    RequiredFieldValidator(fields=["Name", "Email"]),
    EmailFormatValidator(field="Email"),
    FieldLengthValidator(sobject="Account"),
    DuplicateCheckValidator(match_fields=["Name", "Website"]),
]

# Catches 156 validation errors BEFORE you load

Every migration runs in dry-run mode by default. You see exactly how many records would be created, how many fail validation, and how many duplicates were found. Then you fix the mapping, run it again, and only commit when the numbers look right.

This one is less of a tool and more of a reference library. It’s a collection of automation patterns I’ve used across different orgs, documented with the actual business scenario, the code, and the production gotchas that only show up at scale.

The Salesforce community has tons of “how to build a Flow” tutorials. What it lacks is documented patterns for the hard stuff: how to do round-robin lead assignment with timezone awareness, how to chain Queueable jobs to process 500K records, how to build a circuit breaker around an unreliable external API.

These tools solve real problems, but they’re not finished products. Here’s what you should know before depending on them.

None of these are showstoppers, but I’d rather be upfront about them than have someone find out the hard way. Open source means you can see everything, fix anything, and contribute back.