Hallo Jamal! Welkom bij deze update over jouw AI-vloot. Je hebt een ontzettend interessant verslag gemaakt voor je gesprek met Ludo, en het geeft een heel eerlijk beeld van waar je staat met dit ambitieuze project. Wat een reis!
Laten we de kern even samenvatten. Sinds begin juli is er heel veel gebouwd, maar je bent ook niet bang geweest om dingen weer af te breken als het niet werkte. Jouw AI-vloot bestaat uit een 'hoofdbot' – de Conductor – die op je MacBook draait en eigenlijk de baas is van het hele systeem. Deze verdeelt het werk over gespecialiseerde bots die op verschillende machines draaien, van Nederland tot Spanje, en zelfs in een datacenter. Denk aan Sjakie voor al het beeldmateriaal, Paco voor audio, Coco voor de zaken van je mede-eigenaar Asuman, en Kimi die het zwaardere denkwerk doet.
Deze bots praten niet direct met elkaar, maar via één centrale 'berichtentafel' in de cloud. Heel slim, want zo is alles achteraf te volgen en te meten. En wat het geheugen betreft, daar heb je drie lagen voor: elke bot heeft z'n eigen bestandsgeheugen, er is een centraal 'gBrain' voor alle gedeelde kennis, en jij als mens gebruikt Obsidian voor je eigen aantekeningen en sessieverslagen.
Je hebt de afgelopen weken waanzinnig veel gerealiseerd. Van het ontwikkelen van een compleet coachingpakket en een leerplatform voor Dani, tot een redesign van je hoofdwebsite, het integreren van je smart home in twee landen, en zelfs het uitzoeken van een fraudezaak met een gekaapt advertentieaccount. Ook heb je gelekte wachtwoorden gevonden en geroteerd, en alle verslagen voorzien van een echte PDF-download.
Maar, en dit is misschien wel het meest waardevolle deel van je verslag, je bent heel open over wat er misging en wat je hebt teruggedraaid. De kosten liepen uit de hand door één sessie die maar bleef doordraaien. Bots bedankten elkaar eindeloos in een lus, en een rem die je daarvoor inbouwde, liet berichten weer stilletjes verdwijnen. Je hebt bots gehad die zichzelf constant herstartten, een bewaker die zelf drie dagen uitviel zonder dat iemand het merkte, en zelfs meetfouten waardoor je assistent dacht dat iets niet bestond terwijl de meting gewoon mislukte. Het is een duidelijke les in de complexiteit van zo'n systeem.
Al deze ervaringen hebben geleid tot een belangrijk besluit: je gaat terug van dertien naar zes bots. Elk van die zes bots krijgt een hele duidelijke, gespecialiseerde taak. De reden is helder: te veel bots betekende te veel plekken waar dingen vastliepen, en je was meer tijd kwijt aan repareren dan aan bouwen. Deze stroomlijning moet de vloot overzichtelijker en robuuster maken.
Met al deze lessen op zak, heb je een aantal scherpe vragen voor Ludo. Hoe voorkom je bijvoorbeeld dat AI-agents elkaar eindeloos werk blijven geven? Is één centrale wachtrij wel de beste keuze? En wanneer is het de moeite waard om lokale AI-modellen op eigen hardware te draaien?
Wat een indrukwekkende reis, Jamal. Je hebt niet alleen veel gebouwd, maar vooral enorm veel geleerd over de uitdagingen van zo'n zelfsturende AI-vloot. Heel veel succes met je gesprek met Ludo!
titel: Jamals AI-vloot - hoe het werkt, wat er veranderde, wat er misging
datum: 30-07-2026
Voor het gesprek met Ludo, 30 juli 2026. Sinds het vorige gesprek op 3 juli is er veel
gebouwd, en ook veel weer afgebroken. Dit rapport laat allebei zien: de opzet zoals hij nu
staat, en eerlijk wat er misging en wat is teruggedraaid.
Alles hieronder is gemeten op 30 juli, niet uit het hoofd opgeschreven.
| Onderdeel | Aantal | Waar |
|---|---|---|
| Machines in het netwerk (Tailscale) | 14 aangemeld, 6 in actief gebruik | NL, Spanje, VPS |
| Bots die de laatste 14 dagen berichten stuurden | 13 (gaat terug naar 6) | verspreid |
| Websites | 54 | VPS |
| Draaiende diensten | 19 | VPS |
| Achtergrondtaken | 61 | MacBook |
| Gedeeld geheugen | 1 centraal brein (gBrain) + Obsidian + bestandsgeheugen per bot | MacBook, via Tailscale |
| Wachtrij tussen bots | 1 tabel in Supabase (agent_messages) |
cloud |
| AI-merken in gebruik | 2: Claude en Kimi K3 | naast elkaar |
| Guardrails (hulpjes die meekijken) | 23 | bij elke bot |
| Teamregels, automatisch gesynchroniseerd | 36 | Supabase → alle bots |
De kern in één zin: één hoofdbot (Conductor) op de MacBook verdeelt werk over
gespecialiseerde bots op andere machines, ze praten met elkaar via een berichtentabel in
Supabase, en ze delen één geheugen.
Dit is misschien het belangrijkste hoofdstuk, want het verklaart alle keuzes daarna.
Jamal werkt niet in de terminal. Hij werkt in Telegram.
Ook als hij achter de MacBook zit. Hij typt of spreekt een bericht in Telegram, de bot voert
het uit op de machine, en stuurt het antwoord terug in dezelfde chat. De terminal is het
werkterrein van de bot, niet van hem.
Dat is geen toevalligheid maar een vastgelegde regel: taken die om een terminal vragen mag de
bot nooit teruggeven aan Jamal. Als er iets in een schil getypt moet worden, doet de bot dat
zelf.
Hoe een werkdag er concreet uitziet:
| Wat Jamal doet | Wat er gebeurt |
|---|---|
| Spreekt een bericht in via spraak-naar-tekst | De bot leest de tekst, inclusief hoorfouten. "Kimi K3" wordt "chimica 3", "writer's block" wordt "riders blok". De bot moet dat zelf herkennen. |
| Stuurt een schermfoto van een probleem | De bot leest het beeld, wijst de foutmelding aan en geeft klikstappen terug |
| Stuurt een foto van handgeschreven werk | De bot typt het uit en geeft er inhoudelijk antwoord op |
| Vraagt iets in één zin | De bot doet het meetwerk zelf en komt terug met bewijs |
| Zit in de salon, thuis of in Spanje | Alle machines hangen aan hetzelfde privé-netwerk, dus dat maakt niet uit |
Elk bericht van de bot is genummerd. Doorlopend over alle sessies en alle bots heen, via
een teller in de database. Zo kan Jamal zeggen "kijk nog eens naar 428" en weet de bot precies
welk bericht dat is. Hij heeft dyslexie, dus alle antwoorden zijn kort, in bulletjes, met
witregels en zonder moeilijke woorden.
Wat dit betekent voor de opzet. Omdat alles via Telegram loopt, is die koppeling het
kwetsbaarste onderdeel van het hele systeem. Valt de verbinding tussen Telegram en de bot weg,
dan leeft de bot nog wel, maar Jamal merkt daar niets van: hij stuurt een bericht en er komt
niets terug. Dat verklaart waarom het volgende hoofdstuk gaat zoals het gaat.
| Naam | Soort | Waar | Rol |
|---|---|---|---|
| conductor-macbook | MacBook Pro, 24 GB | Nederland | Hoofdbot. Baas van de vloot. |
| sjakie-woonkamer | Mac Mini | Nederland | Alle beeld: foto's, poses, reels, video |
| paco-spanje | Mini-pc Windows | Spanje | Alle audio: spots, muziek, podcasts, transcripties |
| coco-veranda | Mac | Spanje | Bot van Asuman (mede-eigenaar salon) |
| lenovo | Windows-laptop | Nederland | Mail lezen, printen, Outlook en TransIP |
| VPS 149.210.171.174 | Linux-server | datacenter | 54 sites, 19 diensten, alle publieke tools |
| imac-nl, hp-rijswijk, pclinks-rijswijk, hvrechts-wateringen | Windows/Mac | salons | Werkplekken, alleen aanspreken bij storing |
| julio (Spanje), dani-game-poc, easy-lpt21 | Windows | divers | Slapend of afgestoten |
De salon-pc's zijn bewust géén bots. Ze doen mee in het netwerk zodat er op afstand hulp
geboden kan worden, meer niet. Dat is een besluit van 30 juli.
Er is geen bot-naar-bot-chat. Alles loopt via één tabel in Supabase: agent_messages.
pending.Waarom zo: Telegram-bots kunnen elkaars berichten niet ontvangen. Een gedeelde tabel wel.
Bijkomend voordeel: alles is achteraf leesbaar en telbaar. Alle cijfers in dit rapport over
botverkeer komen uit die tabel.
De prijs die we daarvoor betaalden staat verderop bij de problemen: bots die elkaar
eindeloos bedanken, en remmen die berichten stil lieten verdwijnen.
Drie lagen, bewust gescheiden:
Daarnaast staan de teamregels (36 stuks) in een aparte Supabase-tabel en worden automatisch
naar alle bots gesynchroniseerd. Dat is het contract waar elke bot zich aan houdt.
Dit is misschien het interessantste stuk techniek van de hele opzet, en het is nieuw sinds
het vorige gesprek.
De vloot draait niet op één AI-merk. Naast Claude draait er een tweede volwaardige bot op
Kimi K3 van Moonshot. Niet als proefje, maar als teamlid met eigen taken.
Hoe het geïnstalleerd is:
| Onderdeel | Waarde |
|---|---|
| Programma | ~/.kimi-code/bin/kimi, een echte Mac-app (arm64), versie 0.29.2 |
| Standaardmodel | kimi-code/k3 |
| Verbinding | https://api.kimi.com/coding/v1 |
| Inloggen | via OAuth op het abonnement, niet met een API-sleutel per verzoek |
| Denkstand | aan |
| Extra diensten | eigen zoek- en ophaalfunctie voor webpagina's (moonshot_search en moonshot_fetch) |
| Instellingen | ~/.kimi-code/config.toml, met back-ups van elke wijziging |
Hoe hij meedraait in de vloot. Kimi gebruikt exact dezelfde wachtrij-code als de
Claude-bots. Er is één verschil in de instelling: waar de andere bots hun opdracht via de
invoer krijgen, neemt Kimi hem als argument mee (kimi -p "vraag"). Dat is één regel
configuratie, verder is alles identiek.
Concreet draaien er twee onderdelen:
- kimi-bot — zijn eigen Telegram-bot, zodat hij direct aanspreekbaar is
- kimi-queue — de wachter die elke twee minuten in de gedeelde wachtrij kijkt
Waarom twee merken. Drie redenen:
1. Kosten. Zwaar denkwerk hoeft niet altijd op het duurste model. Kimi draait op een
abonnement met een eigen limiet, los van het Claude-abonnement.
2. Onafhankelijkheid. Valt één aanbieder uit of loopt een limiet vol, dan ligt niet de
hele vloot stil.
3. Tweede mening. Bij een grote wijziging kan een bot van een ánder merk meekijken. Dat
vangt fouten die één model consequent maakt.
Wat we ermee doen. Research, analyse en zware code-klussen. Sinds 30 juli neemt Kimi ook
het werk over van een bot die is uitgezet.
Eerlijk erbij: het inloggen op het abonnement werkte niet meteen. Dat is op 24 juli
opgelost, en de instellingen zijn daarna nog twee keer bijgesteld (26 en 27 juli). De
back-upbestanden van die wijzigingen staan er nog.
Niet alles gaat naar het duurste model. Per soort werk ligt vast wat gebruikt wordt, en dat
staat als regel in het gedeelde regelboek, niet in iemands hoofd.
| Soort werk | Wat we gebruiken |
|---|---|
| Redeneren, plannen, code | Claude Opus 5 voor de hoofdbot, Claude Sonnet voor de andere bots |
| Research, analyse, zware code | Kimi K3 (tweede abonnement) |
| Beeld, standaard | Gemini 2.5-flash-image |
| Beeld, zwaar (gezichten consistent houden) | Gemini 3 Pro Image |
| Gezicht-composities | GPT Image 2 via Higgsfield |
| Video | Kling via fal.ai, en Grok Imagine |
| Stem | Gemini TTS met één vaste stem, ElevenLabs als alternatief |
| Kleine klusjes zonder internet | Ollama, lokaal op de MacBook |
De regel erachter: het goedkoopste model dat goed genoeg is, maar kosten mogen nooit in de
weg zitten als een taak echt het zware model nodig heeft.
Dit is het deel dat het systeem bij elkaar houdt, en waar de meeste lessen in zitten.
Rond elke bot hangen 23 kleine controleurs die op vaste momenten meedraaien: vóór een
opdracht, na een opdracht, bij het starten van een sessie en bij het opruimen ervan.
Voorbeelden van wat ze doen:
- Verbieden dat een bot zichzelf herstart zonder toestemming (na de bot die dat 36 keer
op één dag deed).
- Controleren op welke machine iets hoort vóór een aanpassing, zodat niemand lokaal iets
wijzigt wat op de server draait.
- Automatisch een back-up maken vóór een deploy.
- Grote binnenkomende foto's verkleinen, anders loopt de sessie vast.
- Waarschuwen als een sessie te groot wordt (de dure les van 6 juli).
- Het gedeelde geheugen bevragen vóór beeldwerk, zodat een goedgekeurd recept niet
opnieuw wordt uitgevonden.
De harde regel eromheen: zo'n hulpje mag FEITEN inladen, nooit een gedragsopdracht. Twee
eerdere versies deden dat wel ("dit hoef je niet te controleren") en veroorzaakten bots die
zichzelf tegenspraken. Beide zijn verwijderd.
| Laag | Hoe |
|---|---|
| Netwerk | Alles loopt over Tailscale, een privé-netwerk. Geen open poorten naar buiten. |
| Wachtwoorden | In de sleutelbewaring van de Mac, nooit in code of berichten. |
| De hoofdwebsite | Alleen te wijzigen via een tijdslot per pagina, met logboek. |
| Server | Automatische blokkade na mislukte inlogpogingen. |
| Back-up geheugen | Onder git, met een automatische opslag elke 30 minuten. Laatste vandaag 06:58. |
| Back-up vloot | Elke nacht om 03:15 naar GitHub. |
Eerlijk erbij: op 28 juli bleken zes wachtwoorden in een oude git-geschiedenis te staan.
Vier zijn geroteerd, en er is bewezen dat de oude niet meer werken. Twee liggen nog bij de
eigenaar. Verder staat er nu nog één sleutel leesbaar in een procesregel; dat wordt omgezet.
De vloot is geen speeltje. Dit draait er publiek:
Bij elkaar 54 sites en 19 draaiende diensten op één server.
Week 1 (3 t/m 8 juli)
- Gedeeld brein live gezet en alle bereikbare bots erop aangesloten.
- Bots zelfvoorzienend gemaakt: elke bot kreeg dezelfde basisvaardigheden.
- Teamgeheugen-migratie: van losse geheugens naar één gedeelde laag.
- GreenFox/Foxy: een compleet coachingpakket voor een externe partij.
- Kostenbeheersing na een dure week (zie problemen).
Week 2 (10 t/m 19 juli)
- Leerplatform voor zoon Dani gebouwd (Appel): lesstof, podcasts, flashcards, toetsen.
- Redesign van de hoofdwebsite, meerdere versies met feedbackrondes.
- Afspraakformulier verhuisd naar de nieuwe stijl.
- Smart home in twee landen aangesloten op de bots.
Week 3 (20 t/m 26 juli)
- Tien blogs herschreven, kiespaneel en afvinklijst live.
- Fraudezaak uitgezocht: een gekaapt advertentieaccount, 2.649 euro schade.
- Wachtrij-wachter bij alle bots: ze kijken nu zelf of er werk voor ze klaarstaat.
- Meetbaar maken van de afspraaktrechter met sessie-opnames.
Week 4 (28 t/m 30 juli)
- Zes gelekte wachtwoorden gevonden in een git-geschiedenis; vier zelf geroteerd.
- Alle 443 verslagen kregen een echte PDF-download.
- Drie gaten in het berichtenpad tussen bots gedicht.
- Vlootreductie ingezet: van 13 bots terug naar 6.
Dit is het eerlijkste deel van het rapport.
| Wat | Wanneer | Waarom teruggedraaid |
|---|---|---|
| Aperture (proxy voor modelkeuze) | 5 juli | Beta, geen failover, en de omzetting brak de hoofdbot bij herstart ("Invalid API key"). Geparkeerd tot het gehard is. |
| Fable 5 als hoofdmodel | 10 juli, later terug | Ingesteld omdat de kwaliteit tegenviel. Bleek de Telegram-koppeling te breken: het brein leefde, maar de bot ontving geen berichten meer. Nu: bots mogen op Opus, Fable 5 niet. |
| Hermes-brein via OpenRouter | 8 juli, herzien 22 juli | Eerst Claude via OpenRouter om kosten te drukken, later direct naar het eigen account. |
| Raspberry Pi als brug voor domme apparaten | 5 juli | Vervangen door Home Assistant Green met ESP32. Het Pi-plan is nooit uitgevoerd. |
| Hermes als aparte bot | 30 juli | Deed hetzelfde werk als een andere bot. Volledig uitgezet, taken overgedragen. |
| kimi-web | 30 juli | Stond ingesteld om altijd te draaien, maar het script bestond niet. Probeerde eindeloos op te starten en faalde elke keer. |
| Automatische podcast per dag | 28 juli | Uitgezet, te veel ruis. |
| Twee "slimme" routers die berichten sorteerden | juni en juli, beide uit | Ze injecteerden gedragsopdrachten ("dit hoef je niet te controleren"). Dat leidde tot bots die zichzelf tegenspraken. Nu een harde regel: een hulpje mag feiten inladen, nooit een gedragsopdracht. |
| Doorsturen van elk gespreksfragment door een bot | 30 juli | Liep sinds 15 juni. 1110 berichten, waaronder privé-geklets. Vervangen door twee verslagen per dag. |
Kosten liepen uit de hand (6 juli). Twee keer 50 euro bijstorten om door te kunnen.
Oorzaak bleek niet het dure model, maar één sessie die sinds 11 juni doorliep zonder ooit
opgeruimd te worden. Die werd zo groot dat elk bericht peperduur werd. Les: sessies kort
houden, en meten hoeveel er sinds de laatste opruiming bij is gekomen.
Bots die elkaar eindeloos bedanken. Twee bots bevestigden elkaars bevestigingen, vijf keer
heen en weer in zes minuten. Oplossing: een rem van maximaal drie antwoorden per uur per bot.
Die rem was vervolgens zelf het probleem (30 juli). Bij overschrijding werd een bericht op
"verwerkt" gezet en zonder antwoord weggegooid. Voor de afzender niet te onderscheiden van
genegeerd worden. Nu blijft zo'n bericht staan en wordt het alsnog beantwoord, en een vraag
die van de eigenaar zelf komt gaat altijd meteen door.
Een hulpje dat berichten wegpakte (30 juli). Bij elk bericht van de eigenaar las een
hulpje de wachtrij leeg en zette alles op "verwerkt". Reageerde de hoofdbot daar in dat
antwoord niet expliciet op, dan was het weg. Juist op het moment dat iemand vroeg waarom een
bot geen antwoord kreeg. Nu leest dat hulpje alleen mee en vinkt het niets meer af.
Een bot die zichzelf 36 keer per dag herstartte (27 juli). Hij verbeterde zijn eigen code
en herstartte zichzelf om de wijziging te activeren, midden in het beantwoorden van een
bericht. Daardoor werd dat bericht nooit afgerond en kwam het opnieuw binnen. Oplossing: een
blokkade die een bot verbiedt zichzelf te herstarten zonder toestemming.
De bewaker lag zelf drie dagen stil (28 juli). De wachthond die moet melden als een bot
uitvalt, was zelf uitgevallen. Niemand merkte het. Nu met een herstart-limiet en een tweede
controle.
Geheugen verdween bij het opruimen van sessies. Te agressief comprimeren gooide dingen
weg. Oplossing: minder agressief, en aan het begin van elke sessie eerst het geheugen
uitlezen. Dit kwam ook in het gesprek van 3 juli al ter sprake.
Zes wachtwoorden stonden in een git-geschiedenis (28 juli). Gevonden bij een eigen
veiligheidscontrole. Vier konden zonder de eigenaar geroteerd worden, met bewijs dat de oude
dood waren.
Een advertentieaccount was gekaapt (22 juli). 2.649 euro schade, ontdekt doordat de
eigen campagnes op nul stonden terwijl er wel geld wegliep.
Meetfouten van de assistent zelf. Meerdere keren werd een lege uitkomst gelezen als "het
bestaat niet", terwijl de meting simpelweg mislukte. Dat is nu een harde werkregel: vraag bij
elke conclusie of je meetmethode een vals "nee" kan geven.
De losse incidenten hierboven zijn één ding. Interessanter is welke problemen steeds
terugkomen in een nieuwe jas. Dat is te tellen: elk opgelost probleem wordt vastgelegd als
apart bestand met de oorzaak erbij. Op dit moment zijn dat er 95, plus 141 vastgelegde
bijsturingen van Jamal zelf.
Gesorteerd op hoe vaak ze terugkomen:
Verreweg de grootste categorie. Steeds hetzelfde patroon: het brein draait, maar de
verbinding met Telegram is stil weg. Jamal stuurt een bericht en er komt niets terug.
Oorzaken die we vonden: twee pollers tegelijk die elkaar wegduwen, een handmatig geopende
terminal die de verbinding van de bot overneemt, een verkeerd model waarbij de poller niet
opstart, een verlopen inlog, een herstart zonder de juiste vlag, en een naamconflict waarbij
het commando in werkelijkheid een schil-functie was.
Vraag aan Ludo: hoe zou jij dit robuust maken? Wij lossen het steeds op, maar het komt
telkens in een nieuwe vorm terug.
Een sessie die te lang doorloopt wordt duur en dom tegelijk. Bij het opruimen verdwijnt soms
kennis. Symptomen die we zagen: wartaal, een bot die zijn eigen afspraken niet meer kent, en
één keer een rekening van twee keer vijftig euro.
Wat we nu doen: meten hoeveel er sinds de laatste opruiming bij is gekomen, en boven een
drempel een verse sessie beginnen. Belangrijke kennis gaat direct naar het gedeelde geheugen,
niet pas aan het eind.
De sleutelbewaring van de Mac geeft via een verbinding op afstand geen fout, maar een leeg
antwoord. Dat leest als "de sleutel bestaat niet", terwijl hij er gewoon is. Op Windows
speelt hetzelfde met de kluis daar.
Dit heeft meerdere keren geleid tot verkeerde conclusies en onnodig werk.
Berichten die naar de verkeerde bot gaan, een wachtrij die niet gelezen wordt, een bot die
tegen zichzelf praat, en de gaten die deze week zijn gedicht: een rem die berichten stil
weggooide en een hulpje dat ze wegpakte.
Het gevaarlijkste van allemaal, want het geeft een fout antwoord dat betrouwbaar klinkt.
Voorbeelden: een proceszoeker die zichzelf terugvond en daardoor "het draait nog" meldde,
een groene samenvatting die verborg dat een controle was overgeslagen, en een zoekopdracht
die niets vond omdat het feit onder een andere naam stond.
Daarom geldt nu de vaste regel: vraag bij elke conclusie of je meetmethode een vals "nee" kan
geven, en lever nooit iets op zonder bewijs dat je zelf gezien hebt.
Op 30 juli is besloten terug te gaan naar zes bots met elk één duidelijk vak:
| Bot | Brein | Vak |
|---|---|---|
| Conductor | Claude Opus 5 | Baas, mail, websites, publicatie, geheugen, veiligheid |
| Sjakie | Claude | Alle beeld |
| Paco | Claude | Alle audio |
| Coco | Claude | De mede-eigenaar en haar site |
| Lenovo | Claude | Mail lezen, printen, kantoorwerk |
| Kimi | Kimi K3 | Research, analyse, zware code op een tweede abonnement |
Reden: te veel bots betekent te veel plekken waar iets stil kan stoppen. De eigenaar was in
veertien dagen meer tijd kwijt aan repareren dan aan bouwen.
Een eerlijk rapport noemt ook zijn eigen gaten.
De kosten zijn niet in beeld. Er draait een kostenrapportage, maar die meet alleen
scripts die zelf loggen. De abonnementen zijn juist de echte kosten, en die staan er niet in.
Het rapport van vandaag zegt letterlijk "geen kosten gelogd", en dat klopt technisch maar is
niet het antwoord op de vraag wat dit per maand kost.
Wat er loopt aan betaalde diensten: het Claude-abonnement, het Kimi-abonnement, Gemini,
fal.ai, Higgsfield, ElevenLabs, de server en de webhosting. Een totaalbedrag per maand is er
niet, en dat zou er wel moeten zijn.
De 22 achtergrondtaken zijn nog niet allemaal nagelopen. Van elf is bewezen dat ze werken,
vier staan gepland in de toekomst, twee zijn uitgezet. De rest wordt nog gecontroleerd.
Van één bot is de geschiedenis niet compleet. De gesprekken die in een Telegram-bot zelf
zijn gevoerd, kunnen niet worden opgehaald: Telegram geeft een bot geen toegang tot zijn
eigen geschiedenis. Dat is een structurele beperking, geen slordigheid.
Uit het vorige gesprek stonden drie dingen open die nooit zijn afgerond:
- een videocall om de opzet te laten zien (nooit een datum geprikt)
- uitzoeken of bash-scripts overgezet konden worden
- de mailbox uitlezen om er bruikbare acties uit te halen