Bijna elk bureau in onze markt verkoopt AI als product: een chatbot, een assistent, een automatisering. Bijna niemand vertelt of AI ook hun eigen manier van opleveren raakt. Bij Polargate is dat wel zo, op een concrete en tamelijk saaie manier. Deze pagina beschrijft de machinerie die we echt draaien, met de cijfers die we echt hebben, inclusief de delen die niet werken.
Wat er gebeurt als er een ticket binnenkomt
Polargate voert het onderhoud voor klanten uit via een multi-tenant ServiceDesk, sinds 17 juli 2026 in productie. Een klant stuurt een mail of opent een ticket in zijn portaal. Vanaf dat moment:
- De mail komt binnen via ons supportdomein, met DKIM- en DMARC-controles en ondertekende reply-tokens, zodat een antwoord vanuit de mailbox van de klant aan het juiste ticket hangt en aan geen enkel ander.
- Een triage-agent classificeert het ticket: wat voor wijziging het is, welke repository het raakt, hoe risicovol het lijkt en hoeveel uur het zou moeten kosten. Deze stap draait op een groot model en kost ongeveer 0,05 USD per ticket.
- Is het ticket kandidaat voor automatisering, dan start een fixtaak als GitHub Actions-run in de repository van die klant. De worker is één canonieke workflow in onze eigen repo, en elke klantrepo bevat een stub van vijftien regels die hem aanroept. De agent werkt via de Claude Code CLI met een harde limiet van 80 beurten.
- De taak stuurt een diff terug via een callback en stopt daar. Hij wacht.
- Een mens, vandaag de oprichter, beoordeelt die diff in Mission Control, onze interne console: goedkeuren, om een nieuw plan vragen, de uren- of risicoschatting bijstellen, een antwoord aan de klant opstellen of alles annuleren.
- Een mens merget en deployt de wijziging, achter de gebruikelijke poorten: typecheck, tests, build en de echte pagina bekijken op desktop en op een telefoon van 375 pixels.
De verbruikte uren gaan af van het contract van de klant, dat twee potten kent, onderhoud en spoed, waarbij het overschot naar proactieve verbeteringen gaat in plaats van te verdampen. De klant ziet zijn plan, zijn verbruik en zijn facturen in het portaal. Onze interne kennisbank ziet hij nooit: die toegangsregel staat in de database, niet in een beleidsdocument.
Eén ticket, twee uitvoerders
Elk ticket kan op twee manieren dicht: via de automatische baan, die API-krediet kost, of met de hand door een senior engineer in Claude Code, wat niets kost omdat het binnen een bestaand abonnement loopt. Dezelfde wachtrij, hetzelfde ticket, twee uitvoerders. In de praktijk gaan kleine, goed afgebakende wijzigingen automatisch, en gaat alles wat oordeel over het bedrijf van de klant vraagt met de hand.
Parallelle audits, en een scepticus bij elke bevinding
Bouwwerk kent een andere lus. Zodra een wijziging geschreven is, waaieren auditagents uit per dimensie: correctheid, architectuur en hergebruik, interface en platformrichtlijnen, toegankelijkheid, responsive gedrag, prestaties, en beveiliging inclusief row level security. Daarna gaat elke ruwe bevinding naar een aparte agent met maar één taak: hem onderuithalen.
Die weerleggingsronde is geen versiering. Cijfers uit onze eigen runs:
- Onderzoek naar een pushcrash op Android: 14 agents, 20 ruwe bevindingen, 8 geverifieerd, en geen enkele overleefde het contact met de code. De echte oorzaak lag elders.
- Site van een golfclub, twee rondes voor de merge: 37 ruwe bevindingen en 4 bevestigd, daarna 26 ruw en 3 bevestigd.
- Hotelsite in augustus 2026: 55 agents over 6 gebieden, 48 bevindingen, 48 bevestigd, 0 weerlegd. Zestien waren echte bugs, waaronder maar één van de twee kamertypes in de geprerenderde HTML, Engelse routes met lang="es" en bezoekerstellers die op nul stonden.
- Intern operationeel platform: een audit met 74 agents leverde 59 bevestigde bevindingen op, opgelost via een uitwaaiering van 11 agents.
- Een offline-first mobiele app had 11 auditrondes nodig, met bevindingen 42, 28, 9, 15, 11 en 4.
Twee lessen. Ruwe agentoutput heeft een hoog percentage vals alarm, dus pas de weerleggingsstap maakt hem bruikbaar. En het bevestigingspercentage schommelt enorm, van 48 op 48 in de ene codebase tot 4 op 37 in de andere. Een run die bijna alles bevestigt betekent meestal dat die code nog nooit geauditeerd was.
De stopregel is twee schone rondes achter elkaar zonder blockers. "Geverifieerd" betekent build, typecheck en tests groen plus de interface open in de browser, want groene poorten liegen: een tsconfig waarvan de root geen enkel bestand omvatte gaf een project maandenlang een geslaagde typecheck, en twee deploys gingen groen langs een lintstap die nooit een foutcode teruggaf.
De kennisbank eronder
Een agent is zo goed als zijn context. Polargate houdt per entiteit een kennisbank in Postgres bij: tekstfragmenten met embeddings en een HNSW-index, afgebakend per entiteit en project, met een gedeelde globale bibliotheek die in elke zoekopdracht meegaat en een muur tussen klantkennis, interne kennis en persoonlijke kennis. Onze eigen tools komen erbij via een MCP-server met meer dan 100 tools: kennis lezen en schrijven, tickets, urensaldi, facturen, contacten, releases en de fixwachtrij.
In de praktijk kent de triage-agent de stack van de klant al, de genomen beslissingen en wat de vorige keer stukging. Het betekent ook dat de gebruikelijke faalwijze kennis is en geen model: als een voorgestelde fix verkeerd terugkomt, ontbrak er bijna altijd een feit in de kennisbank.
Wat een fix kost
- Triage: ongeveer 0,05 USD per ticket.
- De eerste echte fix van begin tot eind via deze pijplijn, op een klantportaal in juli 2026, kostte 0,31 USD aan modelverbruik.
- Workerinfrastructuur: niets. GitHub Actions-minuten in repositories waar we toch al voor betalen. We hebben een aparte server overwogen en afgewezen als overmaat voor één of twee taken per week.
- In de database staat een dagelijkse uitgavenlimiet. Zodra die geraakt wordt, stopt de baan.
Het modelverbruik per fix is dus een kwestie van centen. Dat is de eerlijke kop en tegelijk het minst interessante getal, want de kosten die tellen zijn de reviewtijd van een senior, en die gaat niet naar nul. Iemand die begrijpt wat het bedrijf van de klant sloopt moet de diff nog steeds lezen. Wat de agent wegneemt is het opstelwerk: de code lezen, het probleem reproduceren, een eerste versie schrijven, het antwoord voorbereiden. Dat maakt seniorkwaliteit haalbaar op een retainer vanaf 850 EUR per maand, waar een bureau met loonlijst meer zou moeten rekenen of er junioren op zou moeten zetten.
Wat de agents niet mogen
Deze grenzen zitten vastgelast in de database, niet in een prompt:
- Nooit zelf een klant antwoorden. Elk bericht naar de klant wordt door een mens bekeken en verstuurd.
- Nooit deployen. Geen enkele agent heeft productiecredentials.
- Nooit de dagelijkse uitgavenlimiet overschrijden.
- Nooit destructieve migraties draaien of aan authenticatie, rollen of secrets komen.
De algemene grens: omkeerbare beslissingen zijn voor de agent, onomkeerbare stoppen en vragen. Een mens beoordeelt en merget elke wijziging. Dat is geen geruststellende slotzin, het is de reden dat je dit systeem überhaupt op de productierepo van een klant kunt richten.
Als je dit zelf wilt bouwen
- Begin bij de ticketdesk, niet bij de agent. Automatisering zonder ticketsysteem en zonder urenadministratie heeft nergens houvast.
- Bouw de weerlegger voordat je de auditor vertrouwt.
- Zet de limieten in data, niet in prompts. Een prompt is een suggestie, een databaseconstraint niet.
- Meet je valse groen. Een verificatiepoort die niet kan falen is erger dan geen poort.
- Begroot de menselijke review eerlijk. Dat is nu het dure deel, en het is het deel waarvoor de klant betaalt.
Polargate werkt zo op Care-retainers vanaf 850 EUR per maand, en nieuwe trajecten beginnen met een Discovery Sprint tegen vaste prijs vanaf 4.900 EUR.
