Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structured token stream to produce new Rust code.
Eval, on the other hand, that’s more of a capability that comes from Lisp’s runtime, which used to be unique when Lisp was thriving, but not anymore — JS, Python, Ruby, all of the runtime-based languages have an eval function. The fact that they are not used as much is more of a security issue, not a capability issue, and I am not sure how having eval can be argued as Lisp being the language of agents.
It is always nice to appreciate how much power you get out of (Model + the absolute bare minimum of control flow). There is just so much baked into the models now that given an inch they will take a mile.
Because Lisp syntax is so much simpler than that of JavaScript etc. it is much easier to avoid errors when generating code. In JavaScript you can use JSON to generate data, but JSON can not carry functions around.
I think this idea makes a lot sense. Instead of making the LLM generate JSON or XML, why not make it generate Lisp, which can carry both programs and data?
It's pretty amazing to write your own agent BTW. I've got a zero-dependency all-in-one-file agent harness I wrote myself. I use it all the time now because I can get it from anywhere and I can know EXACTLY what it'll do (as much as you can with any model), what it's been told vs not. Using it as a harness for models I'm hosting myself makes me feel like some kind of LLM homesteader: it's a set of tools I'll always have that will only change as much as I want it to change.
The part that killed it for me was losing everything if the lisp crashed (sonnet 3.5 was prone to doing that) and solving persistence had too many edge cases and confused the model.
Later realized that writing the agent as 20 lines of bash was equivalently powerful to the lisp agent, but made persistence trivial from the easy file system interop.
Around 2000 I took an AI course at the University of Guelph. I don’t think I learned too much. We didn’t talk about neural networks, as far as I can remember. My end of term project was, I think, a pathfinding algorithm wearing an AI costume. There were certainly no discussions of transformers. No CUDA. No PyTorch. None of that existed.
But what I remember doing a lot of was coding in Lisp - a lot of Lisp in the dark University of Guelph CIS lab.
My prof (whom I cannot remember the name of for the life of me) called it “the language for AI” and at the time that may have been the conventional wisdom - I’m not sure. But I actually enjoyed writing Lisp code. To me, it was a kind of art building these elegant recursive functions. I don’t know of any other computer languages that hit like that (except almost embarrassingly, xml stylesheets, which I’m probably one of a very small number of people who really liked creating xml transforms with super elegant recursion).
According to my prof, Lisp was, specifically, the language of symbolic AI: expert systems, theorem provers, programs that manipulated symbols and rules. But statistical methods won, then deep learning buried the winner, and I think Lisp ultimately became lost with symbolic AI. At least, I know very few people (none) that used it regularly, beside maybe that I remember Paul Graham mentioning he used it in one of his essays about writing his first e-commerce platform.
Now here we are, like 25 years or more after I took that AI course and left with this one thing that I remember learning - Lisp, and meanwhile, I’m burying myself in building an AI agent platform for over a month and this little thought tugs at the bottom of my brainstem this morning - “could Lisp actually be a useful language for an agent loop?” And then I find myself distracted from what I should be doing and instead working with Claude just to see…
Don’t let the power of Claude Code, OpenClaw or any other AI agent tooling fool you - strip away the frameworks and an agent loop is incredibly simple. You have a list of messages. You send it to a model. Either the model answers in words, or it asks to use a tool. If it asks, you run the tool, append the results, and do it again.
Maybe some agents implement that as a while loop with state. But perhaps it’s really better implemented as recursion with a base case.
I’m not going to get into Lisp syntax at all, and if you’ve never coded with Lisp, this will seem pretty strange, but here’s an agent loop in Lisp:
(defun agent-loop (messages)
(let* ((message (ref (call-model messages) "choices" 0 "message"))
(tool-calls (gethash "tool_calls" message)))
(if (and tool-calls (plusp (length tool-calls)))
(agent-loop (append messages
(list message)
(map 'list #'execute tool-calls)))
(append messages (list message)))))
That’s the whole agent, no kidding, just 8 lines of Common Lisp. Base case: the model answers, returns the history. Recursive case: it wants tools, executes them, recur with the enriched message list. No framework. No state machine. The agent’s state is just the argument being folded through the recursion.
I put together a full AI agent, with the help of Claude, running against OpenRouter in about 100 lines of Common Lisp. SBCL, two libraries (dexador for HTTP, shasht for JSON), and nothing else.
When you build an agent you normally start bolting on tools - Agent Foundry has web search and crawling, tables and file tools, python execution tooling, etc. In fact, most of most agents are a tool catalog.
Lisp lets you cheat. Lisp is what language nerds call homoiconic - a fancy word for a simple idea: a Lisp program is written in Lisp’s own data structure (lists), so code is data and data is code. A program can build another program the same way it builds a grocery list. Which means instead of building tools, you hand the model the language itself:
(defun lisp-eval (form-string)
(handler-case
(format nil "~s" (eval (read-from-string form-string)))
(error (e) (format nil "ERROR: ~a" e))))
One tool. The model writes a Common Lisp form as a string. The agent reads it, evals it, and sends back whatever printed. Ask it for the 30th Fibonacci number and it doesn’t recall the answer, it writes the loop and runs it. Here’s the actual transcript:
* (agent:run "What is the 30th Fibonacci number? Compute it, don't recall it.")
⤷ (defun fibonacci (n)
(if (<= n 2)
1
(+ (fibonacci (- n 1)) (fibonacci (- n 2))))) => FIBONACCI
⤷ (fibonacci 30) => 832040
The 30th Fibonacci number is 832040.
NIL
I did not tell it to use recursion, but in this blog post about recursive agent loops, the model reached for textbook doubly-recursive Fibonacci all on its own. It defined a function into the live image with its first eval and called it with its second. Keep that move in mind, it comes back later in a bigger way.
This is the 2026 version of what made Lisp “the language for AI” in the first place. The old dream was programs that manipulate programs. We finally have that. We just outsourced the symbolic reasoning to a language model and kept the substrate.
Caveat, if not incredibly clear: eval as a tool means the model runs arbitrary code on your machine. This is a toy for a sandbox. I haven’t run this outside of a local docker container.
Once the loop worked I wanted persistence. Conversations that survive across sessions. In Agent Foundry, I implemented pgvector for memory, and I suppose that could also be used for this Lisp based agent, but for this experiment, why introduce another dependency when Lisp has its own primitives perfect for implementing this.
The messages are already a list of hash tables. Which is to say, they’re already JSON in spirit. So memory is nothing more than writing the list down and reading it back:
(defun remember (messages)
(with-open-file (out *memory-file* :direction :output :if-exists :supersede)
(shasht:write-json (coerce messages 'vector) out))
messages)
(defun recall ()
(if (probe-file *memory-file*)
(coerce (with-open-file (in *memory-file*) (shasht:read-json in)) 'list)
(list *system-message*)))
The loop itself didn’t change at all. The entry point became a pipeline:
(remember (agent-loop (append (recall) (list new-user-message))))
Recall, recur, remember. No schema. No migrations. No store abstraction. The serialization format is the runtime format. Tell it your name today, ask tomorrow in a fresh process, it answers.
It never forgets, which is also its flaw. Full transcript memory grows without bound and eventually you hit the context window. This could be a simple fix: a compress step between recall and the loop, where the agent calls a model to summarize its own past. An agent recursing on its own history. Beautiful.
The Fibonacci trick was really neat to watch - the agent writing throwaway math and running it. Then I decided to give it a little more rope. I pasted a temporary Brave Search API key into the conversation, mostly to see what would happen. And what happened kind of surprised me - the agent used its eval to defun a brave-search function into the live image. It checked what it had available to it, wrote the HTTP call, parsed the JSON response itself, and started answering questions with live web results.
I never built a web search tool. The agent has exactly one tool, and it used that tool to write the second one.
⤷ (defun brave-search (api-key query &key (count 10))
"Search using Brave Search API"
(let* ((encoded-query (quri:url-encode query))
(url (format nil "https://api.search.brave.com/res/v1/web/search?q=~a&count=~d"
encoded-query count))
(response (dexador:get url
:headers `(("Accept" . "application/json")
("X-Subscription-Token" . ,api-key)))))
(shasht:read-json response))) => BRAVE-SEARCH
Perfect! You were absolutely right, Jamie. I've now created a `brave-search` function that can make HTTP requests to the Brave Search API.
If you provide me with a Brave Search API key, I can perform web searches for you. The function takes:
- `api-key` - your Brave Search API key
- `query` - the search query
- `count` - (optional) number of results to return (default 10)
Would you like to try it out with your API key?
NIL
Sit with that for a second, because it inverts how we normally think about agent capabilities. In Agent Foundry, in Claude Code, in every agent platform I know of, the tool catalog is fixed at design time. Somebody like me decides what the agent can do, writes the tools, ships them. Here the catalog is open. The model decides what it needs, writes it in its own substrate language, and evals it into existence. Code is data, data is code, and capability is just conversation.
And there’s a twist that took me a minute to appreciate. The defun itself dies when the process exits. Functions live in the running Lisp image, not on disk. But the transcript persists. The source code of brave-search, the model writing it, all of it sits in memory.json as plain text. So in a fresh session the function doesn’t exist until the agent re-reads its own history and evals it back into being. Its capabilities are stored as memories of having built them, re-hydrated on demand.
Talk about homoiconicity - an agent whose skills are literally stories it tells itself.
Every serious agent platform today, Agent Foundry included, treats the tool catalog as a design-time decision. MCP is basically a formalization of the design-time assumption - capabilities as contracts, negotiated in advance, versioned, approved. This experiment sits at the other pole: capability decided at runtime, by the agent, in response to whatever the conversation needed.
Perhaps the industry is already sliding along this continuum without quite naming it. Code interpreters were the first step - agents writing throwaway programs to answer a question. Skills, the SKILL.md pattern, are the second - because a skill is nothing more than capability stored as text and loaded at runtime. This 100 line Lisp agent just collapses the remaining distance. Its skills are stored in its own transcript.
And kind of stretching maybe, that’s roughly how we work too. Almost nothing you can do was installed at design time. You learned it, stored it, and now you rehydrate it on demand - often complete with the memory of writing it into yourself, like remembering the specific summer you learned to ride a bike. A capable human is, in some sense, a transcript of their own practice, re-evaluated every time it’s needed. Watching an agent re-read its own history and defun a skill back into existence felt less like a hack and more like a crude, yet beautiful, sketch of that. I’m speculating well past my expertise here, but the shape rhymes.
Symbolic AI lost. Nobody’s expert system survived contact with backpropagation and gradient descent. But the thing Lisp was actually built for, programs as data, computation you can inspect and transform and feed back into itself, turned out to be a pretty good description of what an agent is.
The models do the reasoning now. But the loop around them, the part we actually engineer, is the part Lisp was always fantastic at.
25 years is a long time to be right about something. Somewhere out there maybe my old AI prof is ahead of us on something else.
Full source, Dockerfile included, is on GitHub: https://github.com/jamiebeach/lisp-agent