AI agentsAPIstool useFileMaker Data APIREST APIbusiness automationAI integrationworkflow automationERP connectorsLLM tools

Hoe gebruiken AI-agents API's en tools?

Jeroen·

AI-agents worden pas echt nuttig wanneer ze kunnen handelen — niet alleen antwoorden. Zo geven API's en tools hen die mogelijkheid, en wat dat betekent voor uw bedrijf.

Uw bedrijf heeft een AI-assistent ingezet. Die beantwoordt vragen, vat documenten samen en stelt antwoorden op. Maar als een klant vraagt "Is dit artikel op voorraad?", moet er nog altijd iemand het ERP openen, het aantal controleren en het terugtypen. Als een prospect een contactformulier invult, moet er nog altijd iemand een record aanmaken in uw CRM. De AI praat. Iedereen else doet nog steeds het werk.

Dit is de kloof die APIs en tools dichten. Dit artikel legt precies uit hoe AI-agents verbinding maken met externe systemen, hoe dat er in de praktijk uitziet, en wat u moet overwegen voordat u een agent met tools bouwt of aanschaft voor uw bedrijf.

Wat is het verschil tussen een AI-chatbot en een AI-agent?

Een chatbot genereert tekst. Hij neemt een vraag en produceert een antwoord op basis van patronen in zijn trainingsdata of een document dat u hem hebt aangereikt. Hij heeft geen geheugen tussen sessies, geen inzicht in uw live data en geen mogelijkheid om ergens iets te wijzigen.

Een AI-agent is op één cruciaal punt anders: hij kan handelen. Hij bepaalt welke stappen hij neemt, roept externe tools aan om informatie te verzamelen of wijzigingen te activeren, evalueert het resultaat en gaat verder of probeert opnieuw. De redeneerloop — plan, handel, observeer, herhaal — is wat een agent onderscheidt van een eenvoudig taalmodelantwoord.

Tools zijn het mechanisme dat handelen mogelijk maakt. Zonder tools zit zelfs het meest capabele taalmodel gevangen in een gespreksvenster.

Wat is precies een "tool" in de context van AI-agents?

In AI-agentarchitectuur is een tool een gedefinieerde functie die de agent mag aanroepen. Elke tool heeft:

  • Een naam (bijv. get_stock_level)
  • Een beschrijving die de agent leest om te begrijpen wat de tool doet
  • Een set invoerparameters (bijv. product_id, warehouse_location)
  • Een terugkeerwaarde die de agent kan lezen en over kan redeneren

De agent codeert niet hard wanneer hij een tool gebruikt. Hij leest de beschrijving, leidt af of die tool relevant is voor de huidige taak, vormt de juiste invoer, roept de tool aan en verwerkt het resultaat in zijn volgende redeneer stap. Daarom zijn goede toolbeschrijvingen net zo belangrijk als goede toolcode.

Veelvoorkomende toolcategorieën die uw agents daadwerkelijk zullen gebruiken:

Tooltype Voorbeeldactie
REST API-aanroep Een klantrecord ophalen uit uw CRM
Databasequery Voorraadniveaus opzoeken in FileMaker of SQL
Webzoekopdracht Actuele verzendtarieven of regelgeving opzoeken
E-mail / agenda Een opvolgmail sturen, een vergadering inplannen
Bestand lezen/schrijven Een PDF-offerte genereren, een geüpload contract lezen
Bedrijfssysteemconnector Een factuur aanmaken in Exact Online, een project bijwerken in Jira
Codeuitvoering Een berekening uitvoeren, een CSV verwerken, een btw-nummer valideren

Hoe roept een AI-agent daadwerkelijk een API aan?

Onder de motorkap lossen de meeste toolaanroepen op in een HTTP-verzoek naar een REST API. De stroom ziet er als volgt uit:

  1. Gebruikersinvoer komt binnen. Een verkoper typt: "Controleer of we 50 stuks van SKU-7821 beschikbaar hebben en maak, indien ja, een offerte aan voor klant Martens B.V."
  2. Agent analyseert de intentie. Hij identificeert twee deeltaken: voorraad controleren, dan voorwaardelijk een offerte aanmaken.
  3. Agent roept check_stock(sku="SKU-7821", quantity=50) aan. Dit activeert een GET-verzoek naar uw voorraad-API of FileMaker Data API-eindpunt. Het antwoord komt terug: {"available": 73}.
  4. Agent redeneert over het resultaat. De voorraad is voldoende. Hij gaat door naar de tweede deeltaak.
  5. Agent roept create_quote(customer_id="martens-bv", sku="SKU-7821", qty=50) aan. Een POST-verzoek wordt verzonden naar uw offertebeheersysteem. Een conceptofferte wordt aangemaakt en het ID wordt teruggegeven.
  6. Agent rapporteert terug. "Ik heb bevestigd dat er 73 stuks van SKU-7821 op voorraad zijn en conceptofferte #Q-2024-0391 voor Martens B.V. aangemaakt. Wilt u dat ik deze ter goedkeuring doorstuur?"

De verkoper hoefde alleen maar één zin te typen. De agent verwerkte twee systeeminteracties, controleerde tussentijds op fouten en leverde een voor mensen leesbare bevestiging op.

Welke rol speelt de FileMaker Data API in agentworkflows?

Voor bedrijven die FileMaker als hun kernoperatieplatform gebruiken, is de FileMaker Data API de brug waarmee een AI-agent live bedrijfsdata kan lezen en schrijven. Hij stelt FileMaker-lay-outs beschikbaar als REST-eindpunten — wat betekent dat elk agentframework dat HTTP-aanroepen kan doen, records kan opvragen, vermeldingen kan aanmaken, scripts kan uitvoeren en zoekopdrachten kan uitvoeren.

In de praktijk betekent dit dat u een agent tools kunt geven zoals:

  • find_order(order_number) — bevraagt een FileMaker-lay-out en geeft de orderstatus, regelitems en leverdatum terug
  • update_order_status(order_id, new_status) — schrijft een statuswijziging rechtstreeks in FileMaker
  • run_invoice_script(order_id) — activeert een FileMaker-script dat een factuur genereert en per e-mail verzendt

Omdat het datamodel van FileMaker vaak diep is aangepast aan de werkelijke bedrijfslogica — en niet aan een generiek schema — bevatten deze tools de context van hoe uw bedrijf daadwerkelijk werkt, niet alleen hoe een standaard ERP is ontworpen. Die specificiteit maakt het agentgedrag merkbaar nauwkeuriger.

Hoe gaan agents om met tools die van elkaar afhankelijk zijn?

Echte workflows bestaan zelden uit één toolaanroep. Een agent die een inkooporder verwerkt, moet mogelijk:

  1. De leverancier opzoeken (CRM API)
  2. De actuele prijslijst controleren (databasequery)
  3. De budgetbeschikbaarheid verifiëren (ERP-connector)
  4. De inkooporder aanmaken (ERP schrijf-API)
  5. De leverancierscontactpersoon informeren (e-mailtool)

Een goed ontworpen agent verwerkt dit sequentieel, waarbij elk resultaat als invoer voor de volgende stap dient. Meer geavanceerde agentarchitecturen — soms multi-agent- of orchestrator-worker-patronen genoemd — verdelen taken over gespecialiseerde sub-agents: één voor data-opzoekingen, één voor communicatie, één voor goedkeuringen. De orchestrator coördineert. Dit wordt uitgebreider uitgelegd in A practical guide to AI agents in business operations.

Het kernontwerprincipe: elke tool moet één ding goed doen. Een agent met één doe_alles-tool zal invoer hallucineren en onvoorspelbare uitvoer produceren. Smalle, goed beschreven tools met heldere terugkeerwaarden leveren consistent en controleerbaar agentgedrag op.

Wat kan er misgaan als AI-agents tools gebruiken?

Agents met tools introduceren foutmodi die pure taalmodellen niet hebben. Ken deze voordat u begint te bouwen:

Gehallucineerde toolinvoer. Als de parameterbeschrijving van een tool ambigu is, kan de agent een aannemelijk maar onjuist klinkende waarde afleiden. Een customer_id die eruitziet als CUS-1042 kan worden uitgevonden als CUS-1024. Oplossing: valideer invoer op de toollaag, niet alleen op de agentlaag.

Cascadefouten. Als stap 2 van een workflow met 5 stappen stilzwijgend slechte data teruggeeft, worden stappen 3 tot en met 5 uitgevoerd op basis van een verkeerde aanname. Oplossing: voeg expliciete resultaatvalidatie toe tussen stappen en toon fouten aan de gebruiker in plaats van door te gaan.

Onomkeerbare acties. Een agent die e-mails kan versturen, records kan verwijderen of transacties kan boeken, kan echte schade aanrichten als hij een verzoek verkeerd interpreteert. Oplossing: implementeer een bevestigingsstap voor elke destructieve of naar buiten gerichte actie. Behandel door agents geactiveerde schrijfacties naar productiesystemen zoals u een onbegeleid junior medewerker zou behandelen — nuttig, maar nog niet autonoom bij consequente taken.

Limieten en verlopen authenticatie. APIs hebben limieten. OAuth-tokens verlopen. De agent zal stil falen of in een loop terechtkomen als hij 429- en 401-reacties niet correct afhandelt. Oplossing: bouw herhaalpogingen, tokenvernieuwing en duidelijke foutmeldingen in elke toolwrapper.

Toolovervloed. Een agent 40 tools geven in de hoop dat hij uitvogelt welke hij moet gebruiken, is een veelgemaakte beginnersfout. Te veel tools verhogen de redeneerkosten, vertragen reacties en verminderen de betrouwbaarheid. Oplossing: stel tools per agentgebruiksscenario samen. Een klantenserviceagent heeft geen toegang nodig tot salarisverwerkingstools.

Hoe ziet een minimale werkende toolopzet eruit?

Als u evalueert of u een agent met tools wilt bouwen, volgt hier een praktische starterscontrolelijst:

Voordat u begint te bouwen:

  • Breng de exacte workflow in kaart die de agent zal verwerken — stap voor stap, systeem voor systeem
  • Identificeer welke stappen data lezen, data schrijven of externe gebeurtenissen activeren vereisen
  • Controleer of elk doelsysteem een bruikbare API heeft (REST heeft de voorkeur) met gedocumenteerde authenticatie
  • Bepaal welke acties menselijke bevestiging vereisen vóór uitvoering
  • Definieer hoe een "mislukte" toolaanroep eruitziet en hoe de agent daarop moet reageren

Bij het ontwerpen van tools:

  • Één tool, één actie — geen gecombineerde lees/schrijf-tools
  • Schrijf toolbeschrijvingen alsof een slimme maar ongeïnformeerde collega ze zal lezen
  • Geef gestructureerde data terug (JSON), geen ruwe HTML of ongeformatteerde tekst
  • Neem foutstatussen op in het terugkeerschema, niet alleen successtatussen
  • Leg elke toolaanroep vast met invoer, uitvoer en tijdstempels voor controleerbaarheid

Voordat u live gaat:

  • Test met adversariële invoer (ambigue verzoeken, ontbrekende velden, verkeerde datatypes)
  • Bevestig dat limieten correct worden afgehandeld
  • Verifieer dat schrijfacties expliciete bevestiging vereisen in situaties met grote gevolgen
  • Stel monitoring in — toolaanroepen van agents moeten observeerbaar zijn, geen zwarte doos

Veelgestelde vragen

Kan een AI-agent tools gebruiken zonder te programmeren? Sommige no-codeplatforms (Zapier, Make, n8n) bieden de mogelijkheid om eenvoudige automatiseringen met tools te bouwen via een visuele interface. Voor complexe workflows — met name wanneer de bedrijfslogica voorwaardelijk is, het datamodel op maat is gemaakt, of de agent over meerdere stappen moet redeneren — hebt u code nodig, of een ontwikkelaar die schone toolwrappers rond uw APIs kan schrijven.

Is het veilig om een AI-agent schrijftoegang te geven tot productiesystemen? Ja, met de juiste beveiligingen. De standaardbenadering is om te beginnen in de alleen-lezenmodus, te bewijzen dat de agent correct leest en redeneert, en vervolgens schrijftoegang stap voor stap toe te voegen met een bevestigingsstap waarbij een mens betrokken is voor elke nieuwe schrijfactie. Geef een nieuwe agent op de eerste dag nooit onbeperkte schrijftoegang.

Welke agentframeworks ondersteunen het gebruik van tools? De meest gebruikte frameworks vanaf 2025 zijn LangChain, LlamaIndex, AutoGen (Microsoft) en de OpenAI Assistants API met function calling. Ze implementeren allemaal het gebruik van tools via variaties op hetzelfde patroon: beschrijf de tool in een schema, laat het model beslissen wanneer het hem aanroept, geef het resultaat terug in de context. De frameworks verschillen in de manier waarop ze omgaan met meerstaps-redenering, geheugen en multi-agentcoördinatie.

Moet de AI-agent de API begrijpen, of alleen aanroepen? Alleen aanroepen — maar de toolbeschrijving moet voldoende context bevatten zodat de agent de juiste invoer kan vormen. De agent leest nooit rechtstreeks API-documentatie. Alles wat hij over een tool weet, komt van de naam, de beschrijving en het parameterschema dat u definieert. Daarom is toolontwerp een productontwerpstaak, niet alleen een engineeringstaak.

Wat is het verschil tussen een toolaanroep en een plugin? Terminologie verschilt per platform. OpenAI's "plugins" (inmiddels grotendeels vervangen door de Assistants API) waren gehoste tools die toegankelijk waren via de ChatGPT-interface. "Function calling" en "tool use" zijn de huidige standaardtermen in de meeste frameworks. Ze verwijzen naar hetzelfde onderliggende mechanisme: het model geeft een gestructureerde aanroep af, uw code voert die uit en het resultaat gaat terug naar het model.


Als uw bedrijf workflows heeft waarbij mensen fungeren als de schakel tussen de uitvoer van een AI en de systemen die bijgewerkt moeten worden, is die kloof precies waar Loggix actief is. Of het nu gaat om het bouwen van agents met tools bovenop een FileMaker-omgeving, het ontwerpen van API-connectors om uw bedrijfssystemen te koppelen, of het in kaart brengen van welke workflows werkelijk klaar zijn voor agentautomatisering — dat is het soort praktisch werk dat wij elke dag doen. Als u op het punt staat te beslissen wat u als eerste wilt bouwen, is een gesprek met ons waardevol.