De standaard aanpak bij het bouwen van een AI-agent gaat zo: je bouwt de agent, krijgt hem werkend, en dan zegt iemand: "Mooi, nu moet hij ook via email werken." En dan begint de pijn.
Niet omdat email zo ingewikkeld is. Niet omdat de agent slecht gebouwd is. Maar omdat je een architectuurbeslissing hebt uitgesteld tot het moment dat uitstellen niet meer kan. En op dat moment betaal je rente.
Kanalen zijn geen integratie die je er later op schroeft. Kanalen zijn de eerste architectuurbeslissing.
Waarom kanalen zo lastig zijn
Elk kanaal heeft zijn eigen technische eisen, en die eisen gaan verder dan "hoe stuur ik een bericht."
Email via Microsoft 365 vereist webhook-validatie voordat je ook maar één bericht verwerkt. Je moet replay attacks detecteren, want een aanvaller die een oude webhook-payload opnieuw instuurt mag geen nieuwe actie triggeren. Bovendien moet je thread-context bijhouden: een antwoord op een email hoort bij de bestaande conversatie, niet bij een nieuwe.
Slack heeft signature verification via een gedeeld secret, en dat secret moet je valideren voordat je een response stuurt. Slash commands hebben een timeout van drie seconden. Als je agent langer nodig heeft, moet je een directe bevestiging sturen en de echte response later pushen via de response URL. En dan zijn er nog Block Kit-berichten, de opmaak die Slack gebruikt voor rijke content. Een plaintext antwoord is functioneel, maar voelt in Slack als een SMS in een WhatsApp-groep.
Microsoft Teams heeft weer een ander auth-model. De berichtlengtelimiet verschilt. De manier waarop je een conversatie adresseert is anders. En dan heb je nog Adaptive Cards, het Teams-equivalent van Block Kit.
Voice is een compleet ander verhaal. Geen HTTP-requests met een antwoord na een seconde of twee. Real-time streaming, waarbij de agent al begint te spreken terwijl hij nog denkt. Interrupt handling, waarbij een gebruiker midden in een antwoord iets zegt en de agent dat moet herkennen en verwerken. Latency-eisen in de orde van milliseconden, niet seconden.
Dit zijn geen details die je later kunt toevoegen. Ze bepalen hoe je agent denkt, hoe hij state beheert en hoe hij communiceert.
De fout die iedereen maakt
De meeste teams bouwen agent-logica eerst, kanalen later. Dat is begrijpelijk: je wilt snel een werkende agent, en de eerste kanaalintegratie is vaak één specifiek kanaal voor één specifieke klant.
Maar wat er vervolgens gebeurt is voorspelbaar. De agent raakt strak gekoppeld aan het eerste kanaal. De input/output-structuur weerspiegelt de aannames van dat kanaal. Berichtlengte, formatteringsopties, de manier waarop context wordt doorgegeven, de wijze waarop fouten worden gecommuniceerd: alles is geoptimaliseerd voor één omgeving.
Bij een tweede kanaal moet je kiezen: de agent aanpassen of een adapter schrijven. Beide opties zijn pijnlijk.
De agent aanpassen betekent dat je kanaalspecifieke logica in je agent-core introduceert. Je agent moet nu weten of hij in Slack, Teams of email praat. Elk kanaal voegt conditionele paden toe. Na drie kanalen is je codebase een wirwar van if-statements.
Een adapter schrijven lijkt schoner, maar als de interface van de agent zelf niet ontworpen is om kanaalonafhankelijk te zijn, dan is je adapter meer een vertaalbureau dat concepten probeert te vertalen die nooit bedoeld waren om vertaald te worden.
En elk kanaal dat je erbij voegt wordt moeilijker. Niet lineair moeilijker. Exponentieel moeilijker, omdat de technische schuld samengesteld rente draagt.
De kosten die je niet ziet
Wanneer je kanalen als afterthought bouwt, zijn er kosten die niet direct zichtbaar zijn.
Testing wordt complexer. Een bug die in één kanaal opduikt kan samenhangen met aannames die diep in de agent-logica zitten. Reproduceren vereist de juiste kanaalsimulatie. Fixen betekent aanpassingen die potentieel alle kanalen raken.
Onboarding van nieuwe teamleden duurt langer. "Hoe werkt onze email-integratie?" is geen vraag die je beantwoordt door naar één duidelijke plek te wijzen. Het antwoord is: "Kijk hier, en hier, en dan in de agent zelf ook nog even hier."
Monitoring wordt moeilijker. Als elk kanaal zijn eigen foutafhandeling heeft, zijn je logs een verzameling van kanaalsignalen die je handmatig moet correleren om te begrijpen wat er in de agent zelf fout ging.
En de time-to-market voor nieuwe kanalen is structureel hoog. Elke klant die een ander kanaal wil, is een mini-project.
Hoe wij het doen
In ons platform zijn channels first-class citizens. Dat betekent concreet drie dingen.
De agent weet niet via welk kanaal een bericht binnenkomt. Er is geen Slack-agent, geen email-agent, geen Teams-agent. Er is één agent die een genormaliseerd bericht ontvangt. Dat bericht heeft een consistente structuur: wie stuurde het, wat is de content, wat is de conversatie-context, welke metadata is relevant.
De agent geeft een genormaliseerd antwoord terug. Dat antwoord beschrijft wat gecommuniceerd moet worden, niet hoe. De channel adapter vertaalt dat antwoord naar het juiste formaat voor het juiste kanaal: Block Kit voor Slack, Adaptive Cards voor Teams, HTML voor email.
Channel adapters zijn uitwisselbaar. Ze implementeren een gedefinieerde interface. Een nieuwe adapter toevoegen is schrijven tegen die interface, niet aanpassen van de agent-core. Het is een verticale toevoeging, geen horizontale aanpassing.
Gedeelde state over kanalen
Een vierde aspect dat we bewust hebben ontworpen: kanalen delen state.
Als een gebruiker een vraag stelt via chat en vervolgens een follow-up stuurt via email, herkent het systeem dat dit dezelfde conversatie is. Context is niet gebonden aan een kanaal, maar aan de gebruiker en de sessie.
Dit klinkt als een detail, maar in de praktijk maakt het een groot verschil voor gebruikers die via meerdere kanalen werken. En dat zijn de meeste zakelijke gebruikers.
Wat de adapter doet en niet doet
De verantwoordelijkheid van een channel adapter is precies afgebakend. Hij converteert inkomende berichten naar het genormaliseerde formaat. Hij valideert de authenticiteit van het binnenkomende bericht via signature verification en replay protection. Hij converteert uitgaande antwoorden naar het kanaaleigen formaat.
Wat de adapter niet doet: business logica. Geen beslissingen over wat het antwoord moet zijn. Geen state management. Geen foutafhandeling op applicatieniveau.
Die scheiding is niet alleen elegant. Het is de reden dat het systeem schaalbaar blijft als je een tiende kanaal toevoegt.
Wat dit vraagt van je architectuur
Kanalen als first-class citizens ontwerpen vereist dat je vroeg nadenkt over normalisatie. Wat is het minimale, consistente berichtformaat dat betekenisvol is voor alle kanalen? Dat is niet triviaal. Voice heeft andere velden dan tekst. Rijke berichten met bijlagen vereisen andere metadata dan plaintext.
Het vereist ook dat je vroeg nadenkt over authenticatie. Wie stuurt dit bericht, en hoe verifieer ik dat? De identiteit van een gebruiker moet consistent zijn over kanalen heen, onafhankelijk van hoe elk kanaal authenticatie regelt.
En het vereist dat je kanaalspecifieke eigenaardigheden documenteert en isoleert. De drie-secondentimeout van Slack slash commands is iets wat de adapter moet afhandelen, niet de agent. Die kennis hoort in de adapter, niet in de business logica.
Waarom dit ertoe doet
Elke klant vraagt uiteindelijk meerdere kanalen. Dat is geen uitzondering. Dat is de norm.
Een klant begint met een chatbot op de website. Drie maanden later willen ze email-afhandeling. Zes maanden later komt er een voice-kanaal voor het callcenter. Een jaar later wil de interne helpdesk een Slack-integratie.
Als je kanalen als afterthought bouwt, is elk van die stappen een project. Schatting, planning, implementatie, testing, deployment. Vier keer. En de complexiteit stijgt elke keer, want elk nieuw kanaal interacteert met een systeem dat steeds meer kanaalspecifieke aannames bevat.
Als je kanalen als first-class citizen ontwerpt, is elke stap een configuratiewijziging en een nieuwe adapter. De agent zelf hoeft niet te worden aangepast. De bestaande kanalen blijven onaangetast. De tijdlijn compresseert van weken naar dagen.
Dat is het verschil tussen architectuur als fundament en architectuur als bijproduct.