TL;DR

Agentic systems are the latest thing being used to solve IT integration issues, becoming the glue squirted into the gaps between systems. But the use of natural language means that the distinction between ‘data’ and ‘code’ is almost impossible to make, which causes a whole raft of security concerns. This new glue may be powerful, but it gives off fumes that can cause a bunch of problems. Handle with care!

Agents are being used as space filling glue

Agentic AI agents are being put to use filling the gaps between systems in order to get them to integrate. Zack Akil has a post about this “AI Agents are the new 3D Printers“, which I might boil down the the observation that it’s fine to make a disposable prototype out of hot glue, but maybe consider other things if you want a load bearing structure.

Zack’s post inspired me to comment on LinkedIn:

This reminds me of some of the conversations around serverless a few years back.

The analogy I used was ‘space filling glue’, and 3D printing is (approximately) “what if we make things entirely out of space filling glue”.

Serverless functions also make a great (virtual) space filling glue. If you have some apps or services that don’t quite join together then you can squirt some functions into the gap and get a fit that works.

Agents are the new shiny, and so of course people are finding novel ways to use them to fill those annoying gaps between systems. More space filling glue. But once again, you might wish to think twice about building something load bearing entirely out of this stuff.

Glues through the ages

I’m sure there’s historical stuff about tree sap or whatever I could dig into; but there’s no need to go so far back.

My first memory of glue was 1970s adverts for ’10 second bonding’ Superglue; but cyanoacrylate is not ‘space filling’ and relies on perfectly matched surfaces that fit together. I came to discover that epoxy resin, and impact glue and various other forms were better for fixing many things. When my dad first showed me a hot glue gun it seemed like magic, but I came to discover it too had (many) limitations.

Of course another feature of the 70s was the scourge of ‘glue sniffers’ – people getting off their heads by inhaling the toxic solvents used in some glues.

It’s been a similar story with integrating IT systems. At first we had to arrange for the perfect fit, but over the years various forms of ‘middleware‘ have come along to facilitate integration. Before agents, serverless was the latest hotness (or hot glue); which caused me to observe at the time that serverless is great if you have a joining things together problem, but you might not want to construct entire systems from it.

And yet, we still have ‘swivel chair‘ integration; and mostly because it’s been deemed too risky to join systems with the glues at hand. I’ll speculate that agentic approaches don’t magically fix that.

IT’s original sin, repeated, and worse

We chose the Von Neumann architecture over the Harvard architecture because memory was expensive and thus rare; and its use could be better optimised if code and data shared the same space. Arguably this is the original sin of IT security, as many of the issues that beggar us today track back to not properly separating code from data. There have of course been successive attempts to remedy this, with something like Capability Hardware Enhanced RISC Instructions (CHERI) representing the state of the art.

Agentic systems double down on this original sin, turbocharged, and on steroids. Everything is in natural language, so there’s no clear way to separate ‘code’ from ‘data’. Sequences of tokens might be innocuous in isolation, but add a couple together and you get an attack. It seems the only way to tell is to ‘run’ it and find out. Halting problem anybody?

Is our new agentic integration glue ‘better’ than what we had before? For some situations undoubtedly yes. Safer? Hell no, this stuff makes gluing stuff together in an unventilated cupboard with giant open pots of contact adhesive look like the sane option. Don’t huff the fumes.