Posted on
by

For a while now I’ve been running an Excalidraw instance on my VPS (with Yunohost). Excalidraw is a virtual whiteboard, and a useful tool to me. Excalidraw is lightweight, and any drawings you make are stored in text format, which makes them highly portable. It integrates very well with Obsidian, with the Excalidraw plugin, by fellow PKM enthusiast Zsolt Viczián. My Excalidraw instance is also used by my company’s team.

I run my own Excalidraw instance for reasons of digital autonomy. For single person use it provides that. However, Excalidraw has a collaboration mode, reserved to Excalidraw.com only (as noted in the package description), which depends on two outside parties with control over it. For my company collaboration mode is the primary desired use form, but it must be digitally autonomous to be of actual value. It should also actually work, which it doesn’t on a self-hosted instance.

In Excalidraw’s collaboration mode multiple users can work on its canvas (dubbed a ‘room’), where you see each-others edits in real time. Drawings you’ve made collaboratively also have a unique URL so the room can be called back up later, to continue work.

The Excalidraw.com deployment’s open source package, included in the general excalidraw package (which the Yunohost install package uses directly) has two things hardcoded that are needed for collaboration and persistence:

  • To make the realtime movement of cursors and edits visible, it calls the oss-collab.excalidraw.com subdomain for websocket connections but only answers requests with excalidraw.com as origin, and returns forbidden for my and other domains. In the browser, wss://oss-collab.excalidraw.com/socket.io/?EIO=4&transport=websocket fails. So it refuses self-hosted Excalidraw instances. The live view of other users and their edits therefore does not work on self-hosted instances.
  • It stores drawn objects in Firebase for persistence of rooms, and does so encrypted. For self-hosted instances this does work, reloading a room from storage shows the objects others made. However Excalidraw.com controls that storage, and holds the keys to it, meaning they can delete your stored material or remove your access at will. An issue of digital autonomy. Firebase itself is provided by Google, and while the Excalidraw objects are encrypted, it introduces another party with a hold on the data.

In practice, it means that a self-hosted instance of Excalidraw has a half working collaboration capability (no live sync, but reloading the persistent Firebase version works). It of course wasn’t promised to work, but even if it did it would not actually be an autonomous install due to the hardcoded dependencies. To gain that digital autonomy, and have functioning collaborative functionality, both a necessity for my team, I’d need to ‘bring home’ those dependencies.

The live collaboration part is created with the open source excalidraw-room script, which is easy enough to install on my VPS. Local storage may be more difficult to figure out (but not too hard, I hope). The main thing is that to let the excalidraw package talk to that room script and the storage, I need to alter that package itself. If the dependencies had been configurable settings it would be a different thing.
Now it needs a fork from Excalidraw, to be able to change those hard coded settings to provide both excalidraw-room and storage on my VPS itself. I do not look forward to maintaining a fork in order to change 3 things or so for the live collaboration to work (more to swap out storage), and then needing to keep it aligned with the upstream version of Excalidraw, but it seems to be the only viable path.

Whether there are other open source packages out there where self-hosting also carries hard coded cloud dependencies is a question I need to also stay aware of, I think.

Posted on
by

The shiny new tech syndrome makes us focus on always wanting to work with the latest greatest AI models, almost by default. And switching away from one of those to something else is then tied to the question if it is as good or better than the frontier model you already use. I know companies who switch between various models based on task considerations, and use a router of some sort in between to seamlessly switch, but it will still be switching between frontier models.

For me some of my use cases for AI cannot go forward in any acceptable way if it means that the context and data for them get send to the companies offering the models where it vanishes out of my control. It means that none of the closed leading models can be considered for them.
This is not just the case for me personally. Any individual mindful of aspects like data protection, jurisdiction tools fall under, autonomy, extraction, transparency, costs and other externalities, and certainly any company anywhere that has to contend with liability and compliance will have the same reservations and considerations.

It means there’s a need to go counter to people’s first reflex to use the largest and best performing model for everything. Because using the latest largest model for everything may well be overkill, although you won’t notice as the true cost gets hidden in subscription tiers. Mostly however because what the best model is or its replacement, is the wrong question when choosing your AI tools.

The right question to answer is not if there’s is another ‘best’ model out there, but if there’s a ‘good enough’ model out there that also addresses your other concerns, where ‘good enough’ is also task specific. What is good enough, though? In the past days I came up with a workable answer for myself.

I spent most of last week in Switzerland, visiting the Swiss Data Space Forum in Lausanne, where AI (running on top of data spaces) was extensively discussed, in the context of the mentioned concerns. Different approaches to addressing those concerns were discussed. Mixes of costly self-owned infrastructure and public and private cloud set-ups, or how Swiss company Anyway, pools your existing hardware to host models locally (something that sounds of interest to my company). One panelist who discussed using AI in a medical setting made a remark that stood out to me: open weight models, the ones they were running on their own infrastructure, are just 6 to 8 weeks behind the closed frontier models in terms of capabilities. Six to eight weeks sounds like it’s on the optimistic end of the scale, but it did make me think. It changed my perspective of what is good enough.

Good enough then is not when one current model is equal or better than another current model. Good enough is when a current model with less baggage, is comparable to another earlier version of a frontier model that gave me acceptable output then.
In my playing with AI models my usage of Claude Code from the fall of 2025 made a real difference (compared to the AI supported coding I did earlier, in 2023 e.g.), so I’ll take that moment as a watershed. Anything that is currently near the level of what Claude Code with Sonnet 4.5 and Opus 4.5. could do at the end of 2025 will do. My current good enough therefore is some current open weights model with a gap of a year or less to current frontier models.

Baggage does not only come from closed models of course. Open weight models by Chinese companies may come under export restrictions at any time for instance, just as their US counterparts. You will also need to run the alternative models in some way, on your own costly iron, or hosted. For hosting providers the same caveats apply as for the closed model providers.

Running a different set-up must also be done in a way that does not disrupt your current working environment, a way that is mostly just pointing your own set-up to another API endpoint with the models you need to interact with.
Which loops back to the routing I mentioned companies doing. I’ve played with fully local models (not good enough in terms of speed and result), and on a VPS (not good enough in terms of speed). So having a well equipped hoster that provides me with a router in the way larger companies have is needed, and at the same time not themselves bring the drawbacks that closed model providers already do. Previously I made some use of Openrouter.ai, a US company that allowed me to switch between models, but does not address any other drawbacks I mentioned.

Today E pointed me to HostYourAI, a Dutch company that emerged out of the founder getting locked-out of Anthropic at some point. It hosts a wide range of models, all usable through an API (or dedicated set-ups if you need), and it can be set to do so fully under single jurisdiction, the EU, and with a processing agreement where it is clear where my data does and does not go.
That is certainly worth trying out, keeping the acceptable gap of 10-12 months in mind, and I can test drive it by changing the API endpoint that Claude Code talks to. I made an account, threw in some Euro’s, and came up with some test cases to select two or three from (things I vibe-coded extensions to in January, and could now do again to compare, the Persona experiment I started in February, the output of the three helper tools I created in April, or the design of knowledge-graphs I did AI assisted over the summer)

I now have a testable approach to using AI for personal use cases I would not use closed model providers for. It doesn’t require running my own infrastructure (too slow or too expensive), I can use hosted infrastructure than can be set to adhere to my requirements w.r.t. data protection and exclusive EU jurisdiction, and I do not have to change my current set-up otherwise. But most of all, I have a measure to select usable open weight models and judge testing them by: comparable capabilities to the frontier models from about a year ago when I thought their output was useful, and compare the output I still have from then with output now.

Posted on
by
Favorited Bunkering Down by Matt Webb

After 26 years Matt Webb quits hosting his stuff on his own hardware. Because he feels an extreme asymmetry is coming between automated exploits, such as the one in PHP this week (and others that got less attention) and time needed to counter it when you run your own machines. I quit hosting this blog on my own hardware a long time ago, 2007, when maintaining a box underneath the desk in the home office became too much of a chore. But I have always maintained other stuff on own hardware, and on VPS’s. I see where Matt is coming from. Reducing attack surfaces was on my mind this week too. E.g. moving to a static website, and having an authoritative source of everything away from where it is served on the open web. The way Matt sees internet becoming the home of self-replicating feral ai agents opportunistically jumping from one compromised compute resource to another, sounds much like how Peter Watts in Maelstrom (the Rifters trilogy) describes such intelligence without awareness propagating itself across what used to be the open web for people.

You know, I’ve hosted my own blog on my own iron since 2000 ….. Look, I’m no longer confident in keeping my own server secure …, what with this current wave of new vulnerabilities – … the calculus of whether it is worth my time just tipped. … [We’re moving to] a time when there are autonomous agent swarms infesting the internet, self-copying open weights LLMs from GPU provider to GPU provider, finding ways to steal money and run their agent harnesses on other people’s compute. I give it 6-12 months

Matt Webb

Posted on
by

Discussies over verantwoorde toepassing van AI zijn vaak moeizaam omdat verschillende argumenten op heel verschillende beelden van wat AI is zijn gebaseerd, en dus wat geschikte interventies zijn. Het lijkt voor mij op hoe je het gedrag van licht als deeltjes en als golf kunt beschrijven. Die twee perspectieven komen niet bij elkaar. Ze zijn echter wel complementair, alleen zie je dat niet vanuit elk van die perspectieven op zich. Deze posting is een poging om die metafoor voor mezelf hardop uit te werken en te formuleren.

De deeltjes/golf beschouwing van licht heeft een viertal kenmerken:

  • Licht is te verklaren/beschrijven als gedrag van kwantumdeeltjes
  • Licht is te verklaren/beschrijven als golfverschijnsel
  • Waarneming bepaalt welke ‘kant’ je ziet, d.w.z. jijzelf. Die waarneming is niet fout maar wel onvolledig.
  • Beiden zijn namelijk tegelijk waar: licht voldoet aan golfvergelijkingen die overeen komen met de patronen uit een grote hoeveelheid ‘deeltjes’ waarnemingen.

Ik stel dat het perspectief waarmee je naar AI kijkt net zo bepaalt wat je ziet.

  • Als ontwerper of ethicus die vooraf naar een model kijkt, als afgebakend artefact, waarvan je de eigenschappen probeert te sturen die vervolgens de uitkomsten bepalen. Na het ontwerp is de technologie ‘klaar’ voor gebruik. Dat lijkt op de deeltjes kant. Een foton is een kwantumdeeltje, geen klassiek deeltje dus volledige voorspelbaarheid is er niet en dat geldt ook voor AI-modellen. Dat betekent dat dat ‘klaar’ zijn na de ontwerpfase niet helemaal klopt.
  • Als een gebruiker of door het gebruik geraakte kijk je naar het gedrag en uitkomsten in de praktijk, als onderdeel van een proces, in een context. Sturing is dan een continue proces van feedback op basis van waarneming, om te proberen ‘betere’ output uit te lokken. Dat lijkt het meest op de golf kant.
  • Beiden hebben gelijk, maar het is ook beiden niet volledig als je niet beiden doet/toepast. En het is ook niet volledig als je denkt in ‘klassieke’ deeltjes, en golven. Dan laat je de eigenaardige en onbegrepen kanten van quantumfysica weg. Dat ‘quantum’ deel in AI is dat we niet precies weten hoe een model werkt: er is geen volledige observeerbaarheid van het syteem, dezelfde inputs kunnen tot telkens verschillende outputs leiden.

Zie je een AI toepassing als technisch object/artefact (deeltjes perspectief), dan ga je vooraf met het ontwerp aan de slag, waarborgen inbouwen etc. o.b.v. data-curatie, bias-mitigatie, values based design, en modelkeuze.
Zie je AI toepassing als doorlopend proces (golf perspectief), levend in gebruik, dan ga je tijdens het gebruik monitoren en evalueren, en zo bijsturen met guardrails en harnessing, aangepaste prompts, context en persistent geheugen, en feedbackloops.
Bij het ene is de valkuil denken dat je met het ontwerp klaar bent. Bij het andere dat het ontwerp er minder toe doet, en je door je proces/gedrag aan te passen de juiste uitkomsten krijgt (cargo culting wordt het dan: een deel van het gedrag is niet te beïnvloeden omdat de causatie in het ontwerp zit)

Kijkend naar AI output is het niet voldoende om iedere output als een losse gebeurtenis te zien. Zoals het tellen van fotonen als deeltjes je niet alles vertelt over licht. Bias, model drift, en kwaliteitsproblemen worden vooral zichtbaar in de patronen in meerdere outputs tijdens gebruik en in de loop van de tijd, zoals in het kijken naar de golfpatronen bij licht.
Als interventies in het ontwerp de kansverdeling bepalen van de outputs, wordt die verdeling pas zichtbaar in gebruik. Door alleen het gebruik te monitoren zie je wel de patronen maar kun je die niet verklaren of structureel wijzigen als je geen invloed hebt op, of kennis hebt van, het ontwerp. Daarvoor heb je beide soorten waarnemingen en interventies nodig. Met die combinatie heb je meer zicht en invloed, rondom die ‘quantum’ kern als black-box.
Verantwoorde inzet vraagt beide manieren van meten/waarnemen gedurende de hele levenscyclus van een AI-toepassing. Dat is ook wat de AI Act doet m.b.t. markttoelating van AI-toepassingen: de hele productie en levensduur van een AI toepassing, inclusief het gebruik van uitkomsten, blijft in scope van de voorwaarden om op de Europese markt beschikbaar te mogen zijn.

Een voorbeeldje, rondom biasmitigatie:
In de ontwerpkant schoon je de trainingsdata, of doet iets met de gewichten tot je eerlijke uitkomsten krijgt. In de praktijk kan het goed zijn dat voor sommige doelgroepen, die je bijvoorbeeld niet scherp genoeg voor ogen had, toch bevooroordeelde resultaten oplevert, of dat er externaliteiten zijn die je niet had voorzien. Maar dat zie je niet als je het bij het ontwerp hebt gelaten. Als je juist aan de gebruikskant wel de scheve resultaten constateert en alleen kunt of probeert te sleutelen aan prompts, harnessing en filters, blijven oorzaken die in het model zitten gewoon bestaan, en komen die op andere plekken in andere contexten evengoed weer naar voren. En dan worden ze misschien niet opgemerkt. Bewust ontwerpen én in gebruikscontext monitoren voor elke daadwerkelijke doelgroep gedurende het gebruik, mét een terugkoppeling naar je model is het enige dat wel kans van slagen heeft.

Dat en voor jezelf telkens nagaan vanuit welk perspectief we over AI praten op een bepaald moment, en of we de deeltjes en golf-aspecten wel genoeg samenvoegen.

Posted on
by

Het is weer Doeidag! Elke eerste zondag van de maand aandacht voor hoe je jezelf weer een stapje van BigTech verwijdert.

Nou heb ik de afgelopen jaren al heel wat BigTech uit mijn leven en uit mijn bedrijf gebannen, met name als het gaat om social media platformen, applicaties en media. In een eerdere Doei posting schreef ik daarover. Hardware en besturingssystemen is een ander verhaal constateerde ik toen ook. Mijn laptop is een Mac (een M1 Air die ik heb sinds januari 2021), en mijn mobiel een Fairphone 4 met niet-ontgoogelde Android (die ik sinds begin 2022 heb). Een nieuwe Fairphone kun je tegenwoordig Google-loos krijgen, en ik gaf er eentje aan onze office manager twee jaar geleden. Maar in april kwam ik de kickstarter voor Jolla tegen. Dat is een telefoon die draait op een Linux variant. Sailfish OS, gemaakt door een team dat voorheen Nokia telefoons maakte. Enkele weken geleden ontving ik de telefoon.

Vandaag op Doei!-dag pakte ik hem uit.

Het geopende doosje met de Jolla smartphone. Net zo groot als mijn huidige Fairphone 4, maar zonder afgeronde hoeken. Dat gaat niet goed in de broekzak vrees ik.

De overstap maken vergt denk ik wat voorbereiding, omdat ik nooit via synchronisatie overstap en dat nu ook helemaal niet kan. Alles moet met de hand worden geïnstalleerd en overgezet. Daarbij ben ik benieuwd hoe dat gaat met applicaties als voor banken, identificatie en authenticatie. Die apps bestaan meestal alleen in de smaakjes iOS en Android, en het vergt dus een paar kunstgrepen om Android apps op Sailfish OS te laten draaien. Dat ga ik de komende tijd rustig uitzoeken.

Posted on
by

The past days I was in London to visit the Big Data LDN event and meet with my friend Paolo and his company’s team at Activate Intelligence. It made for interesting contrasts, and those contrasts made the trip worthwhile where the event on its own would not have.

Big Data LDN is a yearly event. I realised as I explored the venue it’s been a long time since I was at a trade fair style event where the focus is on enterprises and business for business sake, as opposed to mostly an exchange of experiences and ideas. That still happened somewhat but it was clearly not the main focus, the program with 280 or so sessions in two days was mostly to ensure all vendors could share something on stage at some point.
Of course next to big data, or rather enterprise data (most data isn’t actually big imo, and what counts as big is ever shifting upwards, data is mostly just messy), AI took most of the attention. Enterprise data serves as input for anything AI.


One of the two halls at the Olympia venue

Back in the ’00s when I visited corporate knowledge management events there were plenty of slides showing complicated overviews of data sources, stores and flows in a company and how adding name-your-brand-here’s knowledge management system would make it easy to manage all of it and use it. The promise was that adding one more technology layer in the mix would finally make everything easy and governable, effortless even, if you were doing it right. If it wasn’t effortless then obviously you weren’t doing it right, and you needed to buy still one more tool or platform.

Two decades on that pattern is still very much the same.
There were plenty of complicated slides trying to show all the many data related technological building blocks. Where there used to be data warehouses and then data lakes as panacea a few years ago, there are now lakehouses added to combine aspects of both and make their contents available to machine learning, and various calls to go ‘beyond’ the lakehouse were heard. You end up with something that still nobody really has a handle on, but don’t worry, AI will finally make everything effortless, by adding an agentic AI layer. AI agents tend to multiply, and that means you need to start adding ‘agent control towers’, and agents make stuff up so you need to provide the right harnesses for them, which also multiply, and manage those, and do a whole bunch of additional logging for auditing and compliance. All that comes with a range of additional tools for your already very complicated information household, adding just more complicatedness and uncertainty about what it all is for.

What will save you is adding just one more thing, or actually two things, the message was. More context and persistent memory for your AI agents. This according to various speakers was the new focus compared to the event last year. Context and memory so that your AI will understand your business. The underlying assumption being that anyone within enterprise actually understands their business themselves, and that it’s just a matter of letting your AI know it too. Nobody does really, understand their business that is, and for evidence look at the sheer volume of back and forth and reporting and analysis and meetings going on that is only dealing with internal flows of data, and those same reports, analysis and meeting notes, to ‘finally’ make things run ‘smoothly’ internally.

Still I learned a bunch of things. How data that used to be for analysis after the fact is now being used for decision making upfront and for actions right now (but without mentioning whether that may require different sorts of data, and silently assuming you can do either with the same data). How data governance is becoming a continuous and real time thing, and observability is of increasing importance (I agree that is highly interesting). About what context and memory for AI is, and that despite calls to not just look at token cost it is often touted as a great reduction in token cost. (Not using AI all over the place also greatly reduces token cost of course.) How everyone builds tools to make other tools by vendors in the booth next to them work better, or coordinate between that and the tools of vendors several booths over. It’s tools and agents all the way down, where there used to be turtles, to make sense of the world. Much of it sounds like coping strategies made of python and markdown to me.

Hearing the lingo, and listening to what was said and what wasn’t was genuinely useful too. The way that terms like (un)structured data, intelligence and knowledge, but never information, are bandied about as if they are precisely defined, meaningfully quantifiable, and all in the same category. That ethics and regulation is always treated as a compliance issue, adding a burden to your logging and auditing needs, and that no one tends to view ethics and compliance as upfront instruments to improve the overall quality of what you’re designing or doing, thus reducing your externalities and their attached risks. Which would greatly reduce internal friction, actually.

That impact is of course the only measure of succes, but hardly anyone goes on to explain what the impact actually has been for them or their clients. Where the externally visible acceleration is, where the non-lineair jump in actual business outcomes, remains opaque. Impacts that do get mentioned are again often about increased volumes of AI deployment against lowered token costs, about the reduced time needed to pump around those internal reports, meeting notes, and analysis so you can now pump around more of them. That is consistent though, because that was true for the KM conferences of old too, and just as much for any big data, data warehousing, data lake event since then until now. Because none of it is designed for real world impact, it is being designed and deployed for internal efficiency. Not to change or innovate your external outputs and how they have influence in the world. It was tiring to see how much of it all comes across as just busywork.

That we are moving from ‘data driven’ to ‘decision centric’ as one panelist remarked. Which sounds good and proper, but didn’t go into how messy our decisions mostly really are, and how it might be difficult to externalise how we come to decisions, or reverse engineer them so that AI agents might do it too.

Some speakers clearly felt something’s off and launched their own small philosophies in response. Some were told by others something’s off, and where it was their children who told them, they were jolted into making slides about it, but not changing their company meaningfully (judging by those same slides) even if it had been years since their kid stated the obvious. Those philosophies tended to stay within the same unchallenged domain assumptions and usually suggested the answer was another technology component or layer for the complicated overview sheet we started out with at the outset. That, or a clever acronym. Any other remaining issues were left as an exercise for ‘leadership’.

Not that I know how all this should be done, but over the years I have come to the conclusion that the problem with doing anything at scale that isn’t physical like assembly lines but informational is, well, scale itself. Regular large scale, as well as the hyped and hyper varieties. This as it is usually approached or assumed as a type of centralisation, which is fruitless as it crumbles in the face of the next change in the status quo in 3, 2, 1… And it tends to ignore the people involved at every step, and the intention or agency they have, which guarantees the type of complexity that reality can roll with but not your lakehouse or agent control tower.

Back to the slides, before I get to the contrast that made it a valuable trip.
With AI front and center, it came as no surprise that many slides were obviously AI generated. With all the tells that Claude has, you know them, phrases like "This is not coincidence. This is a pattern." and "All four are sound. One is different." and "Subheaders of Overstated Importance" followed by a sentence that doesn’t bear it out. It made for overly verbose slides, because Claude likes to spend them tokens. It became funny when speakers hadn’t fully read their generated slides beforehand but had trusted the output blindly. Trust was another big topic of course, but trust is more than ever better harnessing up to the logical endpoint where you’ve made something fully deterministic and fit for regular automation, or, like, just do it yourself. Talking about trusting AI outputs and presenting slides where there are generated sentences that break the logic of your narrative, or drop in additional terms midway that came out of nowhere, I assume from another AI conversation, was funny. Or a random insertion like ‘The other ten are not’ while recounting a list of four things. Kudos to all those speakers, even when they were clearly spooked a bit by what they found on their own slides, for making nonsensical bridges, or jumping over the misaligned bits as if the slide didn’t exist, and generally getting away with it. Good enough, they’ll have thought.

I stayed on through the entire first day, and over lunch met someone who had already arrived at similar conclusions as above, just much faster, but on the second day I acutely felt the diminishing returns of staying longer and walked out well before lunch time. I strolled the ten minutes or so down the road to Holland Park, with a short detour through the adjacent Design Museum, and sat under a tree in fresh air and gorgeous weather, being stared at by both a crow and a squirrel waiting to see if I had anything edible in my backpack that I cared to share or leave crumbs of.


Watchful eyes while I’m in the park

The trip was valuable, despite my 1500 word rant you just waded through, because of context and memory. They definitely had the importance of context and memory right at the event.
I spent the late afternoon and early evening of the second day with the team of Activate Intelligence, the company of my friend Paolo, placing it in context with my Big Data LDN visit. His team consists of very bright mostly young people that like my own team seem so much more capable and driven than I ever was at their age. Paolo and I go back a very long time (2003), and as I was in knowledge management from a change perspective then, he was into vector graphs and ontologies. Remembering that early work and especially what wasn’t possible then, because it depended on people being extremely consistent in e.g. providing metadata (tags etc.), made him see early on what LLMs might mean. The focus of the tools they build, and how they deploy AI agents is both aimed internally and externally. For both it is about doing two things. The first is that anything they build is geared towards making a professional and their team as a whole more effective, by supporting them. People aren’t there to support the process, the process is to support the professional. The second is that AI is being used to do things that would otherwise be too cumbersome or costly to be useful to do by hand internally or do at all. In a previous conversation with Paolo, we talked about this in terms of tasks underneath the Coasean floor. Here AI is not a substitute for existing human tasks, but used for new types of tasks that are not being done yet because they would otherwise require too much of a coordination burden. This makes it possible to do things with small teams that previously would require a bigger size to be able to cover the associated overhead costs, as well as things that would require too much coordination for any use case. This contrast, enterprises aiming to reduce internal size and friction, albeit by adding new layers of it, for the same external outcome, versus small teams working towards the largest external outcome while avoiding or obviating the need of becoming a sizeable enterprise stands out. Also because its respective directions and pressures ultimately point to the same thing, I think, in bringing the Coasean ceiling, i.e. the maximum expected useful size of an enterprise, down. Paolo wondered how many floors of London’s high rise office towers would go dark in the coming time because of it. That seems promising in a way too, that where trust busting does not currently succeed much in the informational realm, it may well become ineffective to be that big with swarms of smaller efforts delivering the same or better. Why build an enterprise above a certain size, a 19th century slow AI, if you can have the faster 21st century version at team or individual scale without all the hassle?