Earlier quoted context omitted.
Back in the late 90's, during one of the previous AI waves, there was this idea of autonomous agents, where one would communicate by sending code snippets or bytecode if using something like Java, which would trigger tasks on remote agents that would process those requests on their own somehow, and the transmited code snippets would be extensible logic. As far as I can remember, never really left the research lab, wi…
Later renamed as D'Agents[1]. Still never got any serious industry adoption as far as I know, but I guess the code is still out there if somebody wanted to do something with it. [1]: https://wiki.tcl-lang.org/page/D%27Agents+%28formerly+Agent+...
I worked as a programmer for the D'Agents group at Dartmouth. The Tcl agent system was ported to Java and we did a variety of experiments with it, mostly centered around information retrieval. I built a Beowulf cluster which we populated with a distributed database of Usenet news. Agents could jump onto the cluster, do multistep queries, and then jump back with the condensed results. We did some work with the US Navy who had a problem with ship-to-shore networks; their network links to shore were T1 equivalents, which made it difficult to work interactively with large data sets for those on shore. We used agents to jump to the ships computer, do multistep queries and computations, and jump back to the shore with the results. This saved a lot of bandwidth. There were a few problems with agent systems. Letting untrusted code run on your server was a difficult security problem, though Java sandboxing helped. Also sending a trusted agent to run on a potentially compromised server was a difficult security problem, the agents might be carrying secrets. Another issue was that agents could use enormous resources, for example doing a database query for the word "the" would engage the entire cluster database. A single laptop sending an agent per second could overwhelm a computing cluster in minutes. We spent a fair amount of time implementing resource management, such as agent lifetime limits, but this was still an issue. What mostly ended the field of study at the time was probably that agents were a lot like computer worms, with difficult security issues, both for the agent and for the server. Also agents were somewhat uncontrollable, until you tried one you didn't know for sure what it might do, which made testing risky; agents could not only jump to and from the cluster, they could jump between machines on the cluster and fork themselves, so like a computer worm they could self-spread everywhere. Some later work seemed to find some solutions to those problems, but I don't know them in detail. Remote procedure calls were a possible alternative to agents, but didn't have as much versatility as sending your own custom code in an agent.