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.
Yes. Check the codebases. It's all prompting scaffolding. All of it. Chain of though, agents, tool using. It's just parsing the user inputs, adding text around it. "You are an expert X". That's the whole edifice.
I think you're right: Agents are at first just an LLM wrapper (app, can even be a Spreadsheet).
For me, the question of which protocols are used to communicate with the environment (MCP et al) ist just one and not even the most interesting question. Other questions uncover better, why agents are "a different kind of software" and why they might vastly change how we think of and use software:
- Stochastic not deterministic (evals/tests are crucial, creating reliable systems is much harder)
- conversational not forms (changes how we write software, and what we need to know for great UX)
- modalities, especially voice, change how we use computers (screens may become less important),
- batch with occasional real-time vs interactive might change how we feel that software works "for us"
- different unit economics (inference costs are significant compared to traditional run-time costs) change how software can be marketed
- data-driven capabilities on every level may change value chains and dictate how agents can work (if data is the moat, will agents need to "go to" the data owner and will be closely guarded of what they can extract/use?, much more than just traditional AAA)
- agents can be implemented in a way that they get better "themselves", because LLMs can be trained with data - will model providers capture most of the value of specialized vertical solutions? Is code less valuable than data/LLMs in the end?
- human-agent-relationship: By definition, agents act on someones behalf. This may again change how we interact with services/websites/content. Currently our personal systems are just like terminals. Will our interactions with services/websites etc. be mediated by "our" personal agents, or will we continue to use the different services, directly (and their agents, too)? Depending on that, the internet as we know it might change dramatically - services must deal more with agents than to humans, directly.
Bottom line: Agents are just an LLM wrapper, but they have the potential to dramatically change a lot of things around software. That's what's interesting about it, in my view.
i think an Agent is an LLM that interacts with the outside world via a protocol like MCP, that's a kind of REST-like protocol with a detailed description for the LLM on how to use it. An example is an MCP server that knows how to look up the price for a given stock ticker, so it enables the LLM to tell the current price for that ticker.
Each MCP endpoint comes with a detailed comment - that comment will be part of the metadata published by the MCP server / extension. The LLM reads this instruction when the MCP extension is added by the end user, so it will know how to call it.
The main difference between REST an MCP is that MCP can maintain state for the current session (that's an option), while REST is supposed to be inherently stateless.
I think most of the other protocols are a variation of MCP.
