Agentforce of een custom AI-agent: configureren of bouwen?

Kort antwoord: configureer Agentforce wanneer het werk een afgebakende set acties is op data die Salesforce al heeft. Bouw een eigen agent wanneer het redeneren het moeilijke deel is en niet de actie, of wanneer de doorslaggevende data buiten het CRM ligt. De meeste serieuze implementaties doen uiteindelijk allebei, met een bewuste naad ertussen.

Wat is het werkelijke verschil?

• Agentforce is de agentlaag van Salesforce. Hij draait op de Atlas Reasoning Engine, wordt geconfigureerd in plaats van geprogrammeerd, en erft het identiteits- en sharingmodel, het audit trail en de governor limits van het platform (Agentforce Developer Guide).
• Een custom AI-agent is software die jij bezit: jouw modelkeuze, jouw retrieval, jouw tools, jouw orkestratie, draaiend waar je wilt en tegen welke systemen je ook hebt.

De afweging is niet "makkelijk versus krachtig", maar afgebakend en beheerst tegenover onbegrensd en van jou. Allebei is ongeveer de helft van de tijd het juiste antwoord.

Wanneer configureer je Agentforce?

Configureer wanneer de meeste hiervan kloppen:

• De data die het antwoord bepaalt staat al in Salesforce, of landt in Data 360.
• Het werk heeft de vorm van CRM: case-deflectie en routering, serviceantwoorden, opportunityhygiene, plannen, begeleide salesacties.
• De acties zijn opsombaar. Je kunt opschrijven wat de agent mag doen, en die lijst past op een whiteboard.
• Governance is de harde eis. Rechten, sharing en audit krijg je gratis omdat de agent binnen het platform draait.
• Je hebt admincapaciteit. Iemand die vloeiend is in Flow, permission sets en het datamodel komt sneller verder dan een team engineers dat koud begint.

De reden die mensen missen: een agent binnen het platform erft het securitymodel van het platform. Dat nabouwen in een eigen stack is duur en subtiel makkelijk fout te doen.

Wanneer bouw je een eigen agent?

Bouw wanneer een van deze punten waar is, want elk punt alleen al diskwalificeert een pure configuratieaanpak:

• De doorslaggevende data zit niet in het CRM. Telemetrie, ERP, documenten, ticketing, een datawarehouse, een vloot apparaten. Moet de agent daarover redeneren, dan is het CRM een bron tussen vele.
• Het redeneren is het product. Analyse in meerdere stappen, planning, gerangschikte aanbevelingen met onderbouwing, of alles waarbij het antwoord verdedigd moet worden en niet alleen uitgevoerd.
• De workflow is geen CRM-workflow. Operations, engineering, supply chain, velddiagnostiek.
• Je wilt modelkeuze. Verschillende taken vragen verschillende modellen, en die keuze wil je niet uit handen geven.
• De agent moet draaien waar de gebruikers zijn, en die gebruikers zitten niet in Salesforce.

Welke test beslist de meeste gevallen?

Schrijf het werk van de agent op als een lijst acties. Lukt dat, en leest of schrijft elke actie iets dat Salesforce al weet, dan configureer je. Zit het moeilijke deel in het kiezen welke actie, op basis van bewijs uit meerdere systemen, dan bouw je.

Die test is sneller dan een bake-off en eerlijk over de faalwijzen. Pure configuratieprojecten stranden wanneer een afgebakende actielijst toch onbegrensd oordeel blijkt te vragen. Pure bouwprojecten stranden wanneer een team een kwartaal besteedt aan het opnieuw maken van sharing rules, audit trails en casebeheer die er al waren.

Waarom is het antwoord meestal allebei?

Omdat de twee lagen verschillende taken willen. Agentforce is een goed oppervlak: het zit waar service- en salesmensen al werken, met de governance van het platform eromheen. Een eigen agent is een goed brein voor alles wat over systemen heen moet redeneren. Verbind ze, en elk doet waar het goed in is.

Die naad is inmiddels een volwaardig platformonderwerp en geen hack meer. Salesforce levert Model Context Protocol-interfaces in de eigen tooling, waaronder een Salesforce DX MCP Server achter de nieuwe generatie DevOps Center (Salesforce Help). Agent-to-agent overdrachten en MCP action hubs zijn de manier waarop een beheerste CRM-agent gespecialiseerde agents aanroept zonder dat een van beide de ander opslokt.

Dit is de architectuur die wij bij Tekunda het vaakst bouwen. We zijn gecertificeerd Salesforce SI, ISV en PDO en Anthropic-partner, we brachten als eerste Agentforce agent-to-agent orkestratie en SWARM-architectuur in productie, en we bouwen headless CRM en MCP action hubs zodat agents vanuit een plek over systemen heen kunnen handelen. Aan de kant van connected devices bracht ons werk voor ASSA ABLOY het aantal cases per week terug van 3.000 naar 350, een reductie van 93% over 11.000 apparaten en tot 2,5 miljoen events per week, in drie markten zonder extra supportmensen. Bekijk hoe we werken.

Hoe beslis je zonder een bake-off van zes maanden?

1. Schrijf de actielijst. Tien minuten, op een whiteboard, met de mensen die het werk vandaag doen.
2. Zet de databron naast elke actie. Tel hoeveel ervan buiten Salesforce liggen.
3. Vraag wat er stukgaat als de agent het mis heeft. Een grote blast radius duwt richting de beheerste platformlaag.
4. Pilot eerst de kleinste helft. Welke kant ook afgebakend is, lever die op en laat de naad wachten tot de waarde bewezen is.

FAQ

Is Agentforce op zichzelf genoeg?

Voor CRM-afgebakend werk op Salesforce-data meestal wel. Het houdt op genoeg te zijn zodra het doorslaggevende bewijs in systemen zit die Salesforce niet bezit.

Kan een eigen AI-agent samenwerken met Agentforce in plaats van het te vervangen?

Ja, en dat is het gangbare patroon. Agentforce houdt het beheerste CRM-oppervlak, eigen agents doen het redeneren over systemen heen, en ze dragen aan elkaar over.

Geef je met zelf bouwen de Salesforce-governance op?

Alleen als je het zo ontwerpt. Laat je CRM-schrijfacties via platformacties lopen, dan blijven het sharingmodel en het audit trail intact.

Wat is de meest gemaakte fout in deze keuze?

Kiezen op kosten. De twee routes komen vaker dan verwacht op vergelijkbare totale kosten uit; het blijvende verschil is of het werk afgebakend is.

Waar begin je met een eerste project?

Bij een workflow met een duidelijke eigenaar en een meetbaar startgetal. Agentprojecten die als platformstrategie beginnen, worden zelden afgemaakt.