The hype around agent protocols reminds me of the emperor's new clothes. There's just nothing to it from a technical perspective.
pizza · 57s ago
Well.. autodiff isn't particularly technically sophisticated. But I doubt seriously when it was first invented, in the 50s, that people could have foreseen that a lot of autodiff put together can write an implementation of autodiff.
padolsey · 16m ago
I wonder if it's just our egos talking, telling us that for something to have value within this technical sphere it has to be complex and 'hard won'?
I see this agent stuff as a pretty basic agreement wrapped up in the vernacular of a protocol, i.e. "we'll put this stuff in the 'role' prop on our JSON", and then everyone else knows where to look for it. It's not especially important what we decide, as long as we create shared expectations.
I used to think protocols and RFCs and other products of standards bodies were the juicy 'big boy table' of tech, but then I realised: ok, it's not so complex–and perhaps doesn't itch my engineering itch–, but SOMEONE needs to take responsibility for deciding the protocol, otherwise it's just a bunch of randoms making up interfaces 1:1 with other parties and no useful tooling emerging for a long time. Best to beat it to the punch and just figure out a 'good enough' approach so we can all get on and make cool stuff.
Addendum: I will say, however, that the AI space has a particularly unhealthy attraction to naming, coining, forming myriad acronyms and otherwise confusing what should be a very simple thing by wrapping it up in a whitepaper and saying LOOK MA LOOK!
esafak · 3h ago
It's just something that needs to be done if you want LLMs to be useful. Everything does not have to be a technological marvel.
01100011 · 2h ago
Is it something like this:
Ages and ages ago I was an EE turned programmer and everyone was hyping JUnit at the time. I had a customer ask for it on a project so fine I'll learn it. I kept thinking it was stupid because in my mind it barely did anything. But then I got it: it did barely do anything, but it did things you'd commonly need to do for testing and it did them in a somewhat standardized way that kept you from having to roll your own every time. Suddenly it didn't feel so stupid.
fnordpiglet · 1h ago
HTTP was never an extraordinarily different protocol, there was really nothing to it from a technical perspective. What was important was it wrapped up a lot of the concepts from the various hypertext and linking protocols that existed into a standard that was widely supported. The standard and the compatibility across servers and clients made it important. This is generally true for protocols across the board. In fact very few standards protocols are particularly revolutionary from a technical perspective. That’s in many ways very much not the point.
pyuser583 · 34m ago
The world would be a better place if Gopher had taken off instead.
EGreg · 12m ago
How about Xanadu LOL
The Web was freely available, while Gopher was licensed, making it less accessible and competitive
As usual, open beats closed! TimBL actually is on video discussing how CERN didnt care to make money off the protocol, and it was lucky that they let it be freeee.
HTML was XML for the web. Nothing to it from a technical perspective.
pyuser583 · 33m ago
XHTML was supposed to be revolutionary.
padolsey · 28m ago
HTML was designed prior to XML fwiw, spinning off from SGML.
crystal_revenge · 2h ago
Even worse is that virtually no one in this space even recognizes the fairly rich research into “agents” throughout the history of computer science.
Mention John Holland’s work in adaptive systems, Hewitt’s actor model or even Minsky’s “Society of the Mind” and you’ll be met with blank stares.
I do believe LLMs have the potential to make these older ideas relevant again and potentially create something amazing, but sadly the ignorant hype makes it virtually impossible to have intelligent conversations about these possibilities.
android521 · 1h ago
Too young, too naive.I think you just need to study the history of previous generation of protocols and standards to appreciate its importance.
simonw · 3h ago
I scrolled straight to section 2.1 "Definition and Characteristics of LLM agents" to find out which of the many definitions of "agent" they are using here.
They went for LLM + short-term and long-term memory + planning + tool using + action execution.
Presumably "planning" here is covered by any LLM that can do "think step by step" reasonably well?
It wasn't clear to me what the difference between "tool using" and "action execution" was.
I haven't seen a definition that specifically encompasses both short- and long-term memory before. They say:
> This dual memory system allows agents to maintain conversation continuity while building knowledge over time.
So presumably, this is the standard LLM chat conversation log plus a tool that can decide to stash extra information in a permanent store - similar to how ChatGPT's memory feature worked up until about four weeks ago.
swyx · 2h ago
> Presumably "planning" here is covered by any LLM that can do "think step by step" reasonably well?
mild disagree. 1) externalizing the plan and letting the user audit/edit the plan while its working is "tool use", yes, but a very specialcase kind of tool use that, for example, operator and deep research use Temporal for. ofc we also saw this with Devin/Manus and i kinda think they're better 2) there is a form of primitive tree search that people are doing where they can spam out several different paths and run it a few steps ahead to gain information about optimal planning. You will see this with morph's launch at AIE. 3) plan meta reflection and reuse - again a form of tool use, but the devin and allhands folks have worked on this a lot more than most.
my criticism of many agent definitions is that they generally do not take memory, planning, and auth seriously enough, and i think those 3 areas are my current bets for "alpha" in 2025.
> I haven't seen a definition that specifically encompasses both short- and long-term memory before.
> It wasn't clear to me what the difference between "tool using" and "action execution" was.
doing a lot of inference here, but could be a separation between -read- tool kinda actions, and -write/execute- (like running code/sending an email, etc)
a bit weird from a coding perspective but idk
sebastiennight · 1h ago
> similar to how ChatGPT's memory feature worked up until about four weeks ago
Is AI Agent just LLM wrapper ? Is there anything more interesting to it ?
mindcrime · 2h ago
I hate to say "it depends" but it, aaah, kinda depends. Nailing down a good definition of "Agent" has a been a problem dating back at least into the 1990's if not the 1980's. So, depending on which definition of "AI Agent" you're using, you arguably don't even need any LLM at all. Heck, using the most expansive definition I've seen, a mechanical thermostat counts. I don't know that I'd go that far, but I'll definitely say that I do not consider Agents to require use of LLM's.
That said, the "Agent pattern du jour" is heavily based on using LLM's to provide the "brain" of the Agent and then Tool Calling to let it do things an LLM can't normally do. But still... depending on just what you do with those tool calls and any other code that sits in your Agent implementation then it certainly could be more than "just" an LLM wrapper.
Nothing stops you from, for example, using the BDI architecture, implementing multi-level memory that's analogous to the way human memory works, wiring in some inductive learning, and throwing in some case-based reasoning, and an ontology based reasoning engine.
Most people today aren't doing this, because they're mostly johnny-come-lately's that don't know anything about AI besides what they see on Twitter, Reddit, and LinkedIn; and wouldn't know BDI from BDSM.
I see this agent stuff as a pretty basic agreement wrapped up in the vernacular of a protocol, i.e. "we'll put this stuff in the 'role' prop on our JSON", and then everyone else knows where to look for it. It's not especially important what we decide, as long as we create shared expectations.
I used to think protocols and RFCs and other products of standards bodies were the juicy 'big boy table' of tech, but then I realised: ok, it's not so complex–and perhaps doesn't itch my engineering itch–, but SOMEONE needs to take responsibility for deciding the protocol, otherwise it's just a bunch of randoms making up interfaces 1:1 with other parties and no useful tooling emerging for a long time. Best to beat it to the punch and just figure out a 'good enough' approach so we can all get on and make cool stuff.
Addendum: I will say, however, that the AI space has a particularly unhealthy attraction to naming, coining, forming myriad acronyms and otherwise confusing what should be a very simple thing by wrapping it up in a whitepaper and saying LOOK MA LOOK!
Ages and ages ago I was an EE turned programmer and everyone was hyping JUnit at the time. I had a customer ask for it on a project so fine I'll learn it. I kept thinking it was stupid because in my mind it barely did anything. But then I got it: it did barely do anything, but it did things you'd commonly need to do for testing and it did them in a somewhat standardized way that kept you from having to roll your own every time. Suddenly it didn't feel so stupid.
The Web was freely available, while Gopher was licensed, making it less accessible and competitive
As usual, open beats closed! TimBL actually is on video discussing how CERN didnt care to make money off the protocol, and it was lucky that they let it be freeee.
https://youtu.be/GU6fWHHu6Es?si=gCgEQFyvwAZjKmZ9
Mention John Holland’s work in adaptive systems, Hewitt’s actor model or even Minsky’s “Society of the Mind” and you’ll be met with blank stares.
I do believe LLMs have the potential to make these older ideas relevant again and potentially create something amazing, but sadly the ignorant hype makes it virtually impossible to have intelligent conversations about these possibilities.
They went for LLM + short-term and long-term memory + planning + tool using + action execution.
Presumably "planning" here is covered by any LLM that can do "think step by step" reasonably well?
It wasn't clear to me what the difference between "tool using" and "action execution" was.
I haven't seen a definition that specifically encompasses both short- and long-term memory before. They say:
> This dual memory system allows agents to maintain conversation continuity while building knowledge over time.
So presumably, this is the standard LLM chat conversation log plus a tool that can decide to stash extra information in a permanent store - similar to how ChatGPT's memory feature worked up until about four weeks ago.
mild disagree. 1) externalizing the plan and letting the user audit/edit the plan while its working is "tool use", yes, but a very specialcase kind of tool use that, for example, operator and deep research use Temporal for. ofc we also saw this with Devin/Manus and i kinda think they're better 2) there is a form of primitive tree search that people are doing where they can spam out several different paths and run it a few steps ahead to gain information about optimal planning. You will see this with morph's launch at AIE. 3) plan meta reflection and reuse - again a form of tool use, but the devin and allhands folks have worked on this a lot more than most.
my criticism of many agent definitions is that they generally do not take memory, planning, and auth seriously enough, and i think those 3 areas are my current bets for "alpha" in 2025.
> I haven't seen a definition that specifically encompasses both short- and long-term memory before.
here
- https://docs.mem0.ai/core-concepts/memory-types#short-term-m...
- https://x.com/swyx/status/1915128966203236571
No comments yet
doing a lot of inference here, but could be a separation between -read- tool kinda actions, and -write/execute- (like running code/sending an email, etc)
a bit weird from a coding perspective but idk
What happened four weeks ago?
That said, the "Agent pattern du jour" is heavily based on using LLM's to provide the "brain" of the Agent and then Tool Calling to let it do things an LLM can't normally do. But still... depending on just what you do with those tool calls and any other code that sits in your Agent implementation then it certainly could be more than "just" an LLM wrapper.
Nothing stops you from, for example, using the BDI architecture, implementing multi-level memory that's analogous to the way human memory works, wiring in some inductive learning, and throwing in some case-based reasoning, and an ontology based reasoning engine.
Most people today aren't doing this, because they're mostly johnny-come-lately's that don't know anything about AI besides what they see on Twitter, Reddit, and LinkedIn; and wouldn't know BDI from BDSM.
[1]: https://en.wikipedia.org/wiki/Belief%E2%80%93desire%E2%80%93...