5 ms·

An agent in 100 lines of Lisp

242 points by jamiebeach 3mo ago

hankbond 3mo ago
Maybe this is a reductive comment, but how does this differ from just letting your agent bash tool a `python -c` command (or anything of that class)? I'm not really getting where this is a "wow" moment? 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.
- pama 3mo ago
  The blog is about writing an agent when you dont already have an agent, but only a plain LLM. It stitches the minimal pieces together. Agents dont need lots of supporting infra, so it is good to keep the code concise. Not a wow moment for sure, though some people think that agents and harnesses are complicated.
  - jstanley 3mo ago
    Right but given that the agent only outputs text, and agents are perfectly happy writing python, the supposed benefit of Lisp is completely irrelevant here.
    - embedding-shape 3mo ago
      > the supposed benefit of Lisp is completely irrelevant here Yeah, it's a small example (it's in the title, "100 lines") so obviously doesn't highlight the best benefits once you reach larger codebase size. Still think ~8 lines for the core loop is probably more elegant, readable and concise than you can achieve in other algol/C-like languages, but happy to be shown that I'm wrong :)
      - hnlmorg 3mo ago
        Most of the code in agents is to handle unhappy paths and human friendly interfaces. I’m sure you could trim most languages core loop too if you discarded all the stuff that actually make agents peasant to use.
        embedding-shape 3mo ago
        Please do show the equivalent of those ~8 lines in the other languages you think of so we can explicitly compare :) I gave it a try in the other languages I know, the Clojure one I have still ends up the smallest and fastest to comprehend.
        hnlmorg 3mo ago
        But that’s not just 8 lines. If I were to try and run those 8 lines on their own then the compiler would fail because half of those functions are undefined. Even the article itself doesn’t claim the agent is only 8 lines long. And once you start including the boilerplate code you end up with something that’s a lot more equivalent to the other languages you tried. I love functional languages, and LISP specifically too. But the point of that article wasn’t even to say “LISP is better at code golfing than other languages”. so this doubling down on the SLOC that you’re doing isn’t even a relevant tangent.
- lelandbatey 3mo ago
  By my eye it's not that different, it's riffing in it from a Lisp perspective. 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.
- wild_egg 3mo ago
  You're not wrong. I did a similar agent in lisp back with Sonnet 3.5 and had a wow moment, but the wow was mostly for seeing an agent working effectively at all at that point in time. 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.
  - josefrichter 3mo ago
    you can use LFE (Lisp flavored erlang) = lisp on BEAM runtime. you get a snippet from LLM, compile it to module, and hot-load it into the running node. the module lives in the node's code table, so it persists and every other agent can call it. not just the one that wrote it. the agents themselves are seaprate supervised processes, so if one crashes - e.g. because the snippet was crap, it doesn't take down whole system. of course you can do that in just elixir too, the lisp is just cosmetics really.
- slim 3mo ago
  this is as if python was written in python, and you added support for llm in python so that it can write it's own code
- kmeaw 3mo ago
  If you give your agent a `bash` or `python -c` tool, it starts a separate process that produces some output and then exits. After that, only the output and the exit code are available. In contrast, `eval` runs the code in the same execution context as the agent loop. When `eval` finishes, that execution context still exists. For example, any functions defined during an `eval` call remain available for later use.
  - vikramkr 3mo ago
    That's technically true but practically an agent can just save the script file/rerun it/write a tool that lets it call a reply with memory etc.This aspect is a bit more elegant when it's in the execution context, but the core of "you don't need to predefine tools, the agent can dynamically write its own code" is not exactly new - that's pretty much the basis of why Claude code and codex and all the other agent harnesses are so much more effective than old ways if working with llms - they can just write giant incomprehensible bash scripts on the fly to accomplish random things without having pre-defined tools, write state to files, etc
  - hnlmorg 3mo ago
    That’s a distinction in search of a reason though. Being able to run code in the same unix process or a new one doesn’t really matter all that much in the context of self modifying code. But even if we cared about that, this isn’t a LISP specific feature. All dynamic languages support eval. And having the agent cache the tool for reuse is a really trivial problem to solve. Though I do agree that LISP makes this much easier than in many other languages. This is certainly a cool tech demo. But the claims of its novelty are overstated
  - hankbond 3mo ago
    Ok yeah fair enough I think thats a sizable distinction. FWIW you can do the same thing inside a python process with eval()/exec(), or if we were still keeping it external to the harness process you could just run python as a persistent process listening to stdin. That way you retain the state from when the last command exited. I wonder if there are any efficiencies to be gained from running a stateful sidecar process like that or if the LLM will have too much of a hard time juggling the state to make coherent followup calls.
emp17344 3mo ago
Littered with AI writing tells.
- lgas 3mo ago
  This doesn't need to be posted on every post. Everyone that cares is well aware. It's like saying "this was written in english" on every post.
  - hack1312 3mo ago
    Why should I bother reading something that the “author” couldn’t even be bothered to write themselves?
    - lgas 3mo ago
      I'm not saying you should, I'm saying you shouldn't clutter up every thread with this type of useless comment. It just detracts from the people that do want to engage with it.
    - pseudony 3mo ago
      Similarly, why should I be bothered reading this kind of comment in each and every discussion thread? What does it contribute? I can read and discern this for myself, I can then stop reading or decide I don’t care. Seriously, at some point all you “ai writing sleuths” should just get your own discussion thread together. It’s been months of this , we get it already. (Not directly just at you, but anyone who feels the need to drop these comments in every thread)
      - tgv 3mo ago
        > why should I be bothered reading this kind of comment in each and every discussion thread? To help other people who don't care about it so they can skip it. A subject tag would be nicer. > It’s been months of this , we get it already. And I am tired of the constant barrage of AI proselytizing.
    - 3mo ago
goranmoomin 3mo ago
I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. 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.
- galaxyLogic 3mo ago
  A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. 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?
  - goranmoomin 3mo ago
    > A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. > 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. First of all, the LLM does not produce structured tokens, it produces (tokens of) text. It does not have a concept of nested or structured tokens. Which means that producing a Lisp program and a JavaScript program is basically the same difficulty, i.e. LLMs producing function foo () {} is about the same task as producing (defun foo () ()). In fact, because most Lisps uses the same token ( and ) for almost all delimiters, the LLM in fact gets confused a lot more than Algol-family languages that uses various different tokens for different purposes. It generates thinking traces that are a few screens long while trying to count the closing parenthesis and the depth, something that I have not found to be the case for other languages, even with languages much more obscure than Lisp. (And no, it is not a training data issue, because the Lisp family as a whole is pretty well represented in the data set, due to Emacs Lisp.) > 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? You do realize that all programming languages contains both programs and data, right? i.e. JSON is literally a subset of the JavaScript language, all JSON documents are valid JavaScript code, can be embedded in JavaScript programs, and so on. This isn't even a JavaScript-specific thing, almost all recent programming languages have data structure literals. The thing that makes Lisp unique is that it can modify programs as data in the language easily, and why would that be a unique capability that would be beneficial for LLMs, when it can just sed/awk or tree-sitter-parse programs with more conventional languages and modify it as easily?
sroerick 3mo ago
I made an interpreted lisp and stored the AST in postgres and exposed the functions with htmx, and honestly it works pretty great.
scarredwaits 3mo ago
Nice, but this is the equivalent of always running with `--dangerously-skip-permissions` with all the security implications of that.
- markasoftware 3mo ago
  Pi does this by default. Since the frontier lab agents are vibe coded you really should sandbox any agent you run period.
- embedding-shape 3mo ago
  Which realistically, is the only way to be productive with agents. If you aren't running them inside of something that limits their scope/impact/potential damage, you're already doing it wrong. Most of those "permission"-systems are built on the idea that an LLM can decide what to ask for approval to run or not anyways, which obviously don't work out great in practice. Might as well give them blanket permission to do whatever, then put them in an isolated environment.
elij 3mo ago
it is also possible to sandbox elisp at least. I allow pure functions through by default: https://github.com/elij/macher-agent/blob/main/macher-agent-sandbox.el https://github.com/elij/macher-agent/blob/main/macher-agent-... -- more an interpreter then straight eval but works as author states
rcarmo 3mo ago
This is a thing of beauty, no matter what the general feeling in the comments seems to be against LISP. And yeah, you can do it in JS/TS/Python/etc., but somehow it doesn’t feel as elegant.
skapadia 3mo ago
This is beautiful, I can't deny that. But the claim that Claude Code is a fixed set of tools is quite wrong. Claude Code regularly generates new code to carry out tasks, and you can choose to promote those tasks to skills, workflows, etc.
drob518 3mo ago
So, writing an agent in Lisp is interesting but not particularly novel. If there’s a big idea here it’s giving Lisp’s eval function to the AI as a tool. Yes, AIs write Python and Bash all day long already, but those scripts are run out of process. In this case, the AI can modify the process running the harness, extending it directly and potentially changing it (evolving it). That’s powerful. And obviously quite dangerous. Definitely only for a sandbox. But I wonder how far that can go…
- Shorel 3mo ago
  Now this is AI going full circle, back to their roots. Yeah, I want to see that system working.
- derdi 3mo ago
  There is no good reason for running this in-process. The maximally inefficient Fibonacci function in the article is a good demonstration why: Call it with a slightly larger number, and your agent slows to a crawl, with no way to enforce a timeout. Call it with a slightly larger number yet, and you might bring your agent down entirely, with no way to recover. There is a case to be made for a dynamically evolving "tool server", but it should be a separate process. That would be more flexible for other use cases too. For example, multiple independent agent processes could talk to one shared tool server. Like a blackboard system, more classic AI! And if you really do want to evolve the agent itself: As the article observes, its entire state can be serialized. Nothing is gained from hanging on to one particular agent process. Serialize its state, ask the tool server to kill it, rewrite its code, then start the new version and replay the state.
  - mvc 3mo ago
    Lately I've been adding a repl service to my docker compose configs so the agent can easily send fragments of code for execution in the project context without incurring the clojure startup costs each time. So cool to watch the AI get into a tight learning loop when it has access to all the internal data structures.
  - drob518 3mo ago
sim04ful 3mo ago
Prolog would have been a better choice
- esafak 3mo ago
  why?
chumzygood 3mo ago
[flagged]
tosh 3mo ago
9 lines of python: import json,sys,uuid;from subprocess import getoutput as sh;from urllib.request import Request as R,urlopen b={"model":"gpt-5.6","prompt_cache_key":uuid.uuid4().hex,"input":[],"tools":[{"type":"custom","name":"shell"}]} while prompt:=input("> "): b["input"]+=[{"role":"user","content":prompt}] while True: o=(r:=json.load(urlopen(R(sys.argv[1],json.dumps(b).encode(),{"Content-Type":"application/json"}))))["output"] b["input"]+=o;calls=[i for i in o if i["type"]=="custom_tool_call"];used=r["usage"]["total_tokens"]/10500 if not calls: print(o[-1]["content"][0]["text"],f'\n[{used:06.3f}%]'); break b["input"]+=[{"type":"custom_tool_call_output","call_id":i["call_id"],"output":sh(i["input"])} for i in calls]
- tosh 3mo ago
  nb: - stdlib only, 0 external dependencies - works with openai compatible api (including local models) - shows context usage in % when turn goes back to user - cache friendly (keeps stable prefix and provides uuid v4 as session cache key) - uses 'shell' as open ended tool 'shell' as tool name is sufficient context for gpt 5.6 sol
- ySPARK 3mo ago
  Every Lisp program can be written in one line.
whartung 3mo ago
I never realized that when chatting with the bot, the entirety of the session was sent each time. I guess I just figured there was some state maintained Out There, rather than simply resubmitted each time.
deleted 3mo ago
[deleted]
kazinator 3mo ago
> Symbolic AI lost. Symbolic AI lost? At what, surely not chess? A symbolic AI solution to a problem requires vastly less energy. And is deterministic; you can cover it with expected input/output pair regression test cases.
- ijk 3mo ago
  Technically the current best chess engine is a neurosymbolic hybrid. But I have found that sometimes the best use of an LLM is to write code for symbolic AI.
killerstorm 3mo ago
It might be kind of cool to implement just a basic loop and let the agent itself to implement memory and all other aspects on the fly, fully embracing self-modifying code. But it's also extremely brittle and unstable. It's really the opposite of what people look in agents.
vichoiglesias 3mo ago
I always had this idea after reading so much about Lisp that I was designed for AI, but kinda forgot about it with all the craziness of the last years. When I read on the article the eval and the implications of agents self generating their code, it just clicked. Looking forward to experiment with this! kudos to the author!
guillaume_code 3mo ago
[flagged]

242 points by jamiebeach 3mo ago

Maybe this is a reductive comment, but how does this differ from just letting your agent bash tool a `python -c` command (or anything of that class)? I'm not really getting where this is a "wow" moment? 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.

pama 3mo ago
The blog is about writing an agent when you dont already have an agent, but only a plain LLM. It stitches the minimal pieces together. Agents dont need lots of supporting infra, so it is good to keep the code concise. Not a wow moment for sure, though some people think that agents and harnesses are complicated.
- jstanley 3mo ago
  Right but given that the agent only outputs text, and agents are perfectly happy writing python, the supposed benefit of Lisp is completely irrelevant here.
  - embedding-shape 3mo ago
    > the supposed benefit of Lisp is completely irrelevant here Yeah, it's a small example (it's in the title, "100 lines") so obviously doesn't highlight the best benefits once you reach larger codebase size. Still think ~8 lines for the core loop is probably more elegant, readable and concise than you can achieve in other algol/C-like languages, but happy to be shown that I'm wrong :)
    - hnlmorg 3mo ago
      Most of the code in agents is to handle unhappy paths and human friendly interfaces. I’m sure you could trim most languages core loop too if you discarded all the stuff that actually make agents peasant to use.
      - embedding-shape 3mo ago
        Please do show the equivalent of those ~8 lines in the other languages you think of so we can explicitly compare :) I gave it a try in the other languages I know, the Clojure one I have still ends up the smallest and fastest to comprehend.
        hnlmorg 3mo ago
        But that’s not just 8 lines. If I were to try and run those 8 lines on their own then the compiler would fail because half of those functions are undefined. Even the article itself doesn’t claim the agent is only 8 lines long. And once you start including the boilerplate code you end up with something that’s a lot more equivalent to the other languages you tried. I love functional languages, and LISP specifically too. But the point of that article wasn’t even to say “LISP is better at code golfing than other languages”. so this doubling down on the SLOC that you’re doing isn’t even a relevant tangent.
lelandbatey 3mo ago
By my eye it's not that different, it's riffing in it from a Lisp perspective. 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.
wild_egg 3mo ago
You're not wrong. I did a similar agent in lisp back with Sonnet 3.5 and had a wow moment, but the wow was mostly for seeing an agent working effectively at all at that point in time. 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.
- josefrichter 3mo ago
  you can use LFE (Lisp flavored erlang) = lisp on BEAM runtime. you get a snippet from LLM, compile it to module, and hot-load it into the running node. the module lives in the node's code table, so it persists and every other agent can call it. not just the one that wrote it. the agents themselves are seaprate supervised processes, so if one crashes - e.g. because the snippet was crap, it doesn't take down whole system. of course you can do that in just elixir too, the lisp is just cosmetics really.
slim 3mo ago
this is as if python was written in python, and you added support for llm in python so that it can write it's own code
kmeaw 3mo ago
If you give your agent a `bash` or `python -c` tool, it starts a separate process that produces some output and then exits. After that, only the output and the exit code are available. In contrast, `eval` runs the code in the same execution context as the agent loop. When `eval` finishes, that execution context still exists. For example, any functions defined during an `eval` call remain available for later use.
- vikramkr 3mo ago
  That's technically true but practically an agent can just save the script file/rerun it/write a tool that lets it call a reply with memory etc.This aspect is a bit more elegant when it's in the execution context, but the core of "you don't need to predefine tools, the agent can dynamically write its own code" is not exactly new - that's pretty much the basis of why Claude code and codex and all the other agent harnesses are so much more effective than old ways if working with llms - they can just write giant incomprehensible bash scripts on the fly to accomplish random things without having pre-defined tools, write state to files, etc
- hnlmorg 3mo ago
  That’s a distinction in search of a reason though. Being able to run code in the same unix process or a new one doesn’t really matter all that much in the context of self modifying code. But even if we cared about that, this isn’t a LISP specific feature. All dynamic languages support eval. And having the agent cache the tool for reuse is a really trivial problem to solve. Though I do agree that LISP makes this much easier than in many other languages. This is certainly a cool tech demo. But the claims of its novelty are overstated
- hankbond 3mo ago
  Ok yeah fair enough I think thats a sizable distinction. FWIW you can do the same thing inside a python process with eval()/exec(), or if we were still keeping it external to the harness process you could just run python as a persistent process listening to stdin. That way you retain the state from when the last command exited. I wonder if there are any efficiencies to be gained from running a stateful sidecar process like that or if the LLM will have too much of a hard time juggling the state to make coherent followup calls.

emp17344 3mo ago

Littered with AI writing tells.

lgas 3mo ago
This doesn't need to be posted on every post. Everyone that cares is well aware. It's like saying "this was written in english" on every post.
- hack1312 3mo ago
  Why should I bother reading something that the “author” couldn’t even be bothered to write themselves?
  - lgas 3mo ago
    I'm not saying you should, I'm saying you shouldn't clutter up every thread with this type of useless comment. It just detracts from the people that do want to engage with it.
  - pseudony 3mo ago
    Similarly, why should I be bothered reading this kind of comment in each and every discussion thread? What does it contribute? I can read and discern this for myself, I can then stop reading or decide I don’t care. Seriously, at some point all you “ai writing sleuths” should just get your own discussion thread together. It’s been months of this , we get it already. (Not directly just at you, but anyone who feels the need to drop these comments in every thread)
    - tgv 3mo ago
      > why should I be bothered reading this kind of comment in each and every discussion thread? To help other people who don't care about it so they can skip it. A subject tag would be nicer. > It’s been months of this , we get it already. And I am tired of the constant barrage of AI proselytizing.
  - 3mo ago

goranmoomin 3mo ago

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. 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.

galaxyLogic 3mo ago
A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. 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?
- goranmoomin 3mo ago
  > A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. > 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. First of all, the LLM does not produce structured tokens, it produces (tokens of) text. It does not have a concept of nested or structured tokens. Which means that producing a Lisp program and a JavaScript program is basically the same difficulty, i.e. LLMs producing function foo () {} is about the same task as producing (defun foo () ()). In fact, because most Lisps uses the same token ( and ) for almost all delimiters, the LLM in fact gets confused a lot more than Algol-family languages that uses various different tokens for different purposes. It generates thinking traces that are a few screens long while trying to count the closing parenthesis and the depth, something that I have not found to be the case for other languages, even with languages much more obscure than Lisp. (And no, it is not a training data issue, because the Lisp family as a whole is pretty well represented in the data set, due to Emacs Lisp.) > 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? You do realize that all programming languages contains both programs and data, right? i.e. JSON is literally a subset of the JavaScript language, all JSON documents are valid JavaScript code, can be embedded in JavaScript programs, and so on. This isn't even a JavaScript-specific thing, almost all recent programming languages have data structure literals. The thing that makes Lisp unique is that it can modify programs as data in the language easily, and why would that be a unique capability that would be beneficial for LLMs, when it can just sed/awk or tree-sitter-parse programs with more conventional languages and modify it as easily?

sroerick 3mo ago

I made an interpreted lisp and stored the AST in postgres and exposed the functions with htmx, and honestly it works pretty great.

scarredwaits 3mo ago

Nice, but this is the equivalent of always running with `--dangerously-skip-permissions` with all the security implications of that.

markasoftware 3mo ago
Pi does this by default. Since the frontier lab agents are vibe coded you really should sandbox any agent you run period.
embedding-shape 3mo ago
Which realistically, is the only way to be productive with agents. If you aren't running them inside of something that limits their scope/impact/potential damage, you're already doing it wrong. Most of those "permission"-systems are built on the idea that an LLM can decide what to ask for approval to run or not anyways, which obviously don't work out great in practice. Might as well give them blanket permission to do whatever, then put them in an isolated environment.

elij 3mo ago

it is also possible to sandbox elisp at least. I allow pure functions through by default: https://github.com/elij/macher-agent/blob/main/macher-agent-sandbox.el https://github.com/elij/macher-agent/blob/main/macher-agent-... -- more an interpreter then straight eval but works as author states

rcarmo 3mo ago

This is a thing of beauty, no matter what the general feeling in the comments seems to be against LISP. And yeah, you can do it in JS/TS/Python/etc., but somehow it doesn’t feel as elegant.

skapadia 3mo ago

This is beautiful, I can't deny that. But the claim that Claude Code is a fixed set of tools is quite wrong. Claude Code regularly generates new code to carry out tasks, and you can choose to promote those tasks to skills, workflows, etc.

drob518 3mo ago

So, writing an agent in Lisp is interesting but not particularly novel. If there’s a big idea here it’s giving Lisp’s eval function to the AI as a tool. Yes, AIs write Python and Bash all day long already, but those scripts are run out of process. In this case, the AI can modify the process running the harness, extending it directly and potentially changing it (evolving it). That’s powerful. And obviously quite dangerous. Definitely only for a sandbox. But I wonder how far that can go…

Shorel 3mo ago
Now this is AI going full circle, back to their roots. Yeah, I want to see that system working.
derdi 3mo ago
There is no good reason for running this in-process. The maximally inefficient Fibonacci function in the article is a good demonstration why: Call it with a slightly larger number, and your agent slows to a crawl, with no way to enforce a timeout. Call it with a slightly larger number yet, and you might bring your agent down entirely, with no way to recover. There is a case to be made for a dynamically evolving "tool server", but it should be a separate process. That would be more flexible for other use cases too. For example, multiple independent agent processes could talk to one shared tool server. Like a blackboard system, more classic AI! And if you really do want to evolve the agent itself: As the article observes, its entire state can be serialized. Nothing is gained from hanging on to one particular agent process. Serialize its state, ask the tool server to kill it, rewrite its code, then start the new version and replay the state.
- mvc 3mo ago
  Lately I've been adding a repl service to my docker compose configs so the agent can easily send fragments of code for execution in the project context without incurring the clojure startup costs each time. So cool to watch the AI get into a tight learning loop when it has access to all the internal data structures.
- drob518 3mo ago

sim04ful 3mo ago

Prolog would have been a better choice

esafak 3mo ago
why?

chumzygood 3mo ago

[flagged]

tosh 3mo ago

9 lines of python: import json,sys,uuid;from subprocess import getoutput as sh;from urllib.request import Request as R,urlopen b={"model":"gpt-5.6","prompt_cache_key":uuid.uuid4().hex,"input":[],"tools":[{"type":"custom","name":"shell"}]} while prompt:=input("> "): b["input"]+=[{"role":"user","content":prompt}] while True: o=(r:=json.load(urlopen(R(sys.argv[1],json.dumps(b).encode(),{"Content-Type":"application/json"}))))["output"] b["input"]+=o;calls=[i for i in o if i["type"]=="custom_tool_call"];used=r["usage"]["total_tokens"]/10500 if not calls: print(o[-1]["content"][0]["text"],f'\n[{used:06.3f}%]'); break b["input"]+=[{"type":"custom_tool_call_output","call_id":i["call_id"],"output":sh(i["input"])} for i in calls]

tosh 3mo ago
nb: - stdlib only, 0 external dependencies - works with openai compatible api (including local models) - shows context usage in % when turn goes back to user - cache friendly (keeps stable prefix and provides uuid v4 as session cache key) - uses 'shell' as open ended tool 'shell' as tool name is sufficient context for gpt 5.6 sol
ySPARK 3mo ago
Every Lisp program can be written in one line.

whartung 3mo ago

I never realized that when chatting with the bot, the entirety of the session was sent each time. I guess I just figured there was some state maintained Out There, rather than simply resubmitted each time.

deleted 3mo ago

[deleted]

kazinator 3mo ago

> Symbolic AI lost. Symbolic AI lost? At what, surely not chess? A symbolic AI solution to a problem requires vastly less energy. And is deterministic; you can cover it with expected input/output pair regression test cases.

ijk 3mo ago
Technically the current best chess engine is a neurosymbolic hybrid. But I have found that sometimes the best use of an LLM is to write code for symbolic AI.

killerstorm 3mo ago

It might be kind of cool to implement just a basic loop and let the agent itself to implement memory and all other aspects on the fly, fully embracing self-modifying code. But it's also extremely brittle and unstable. It's really the opposite of what people look in agents.

vichoiglesias 3mo ago

I always had this idea after reading so much about Lisp that I was designed for AI, but kinda forgot about it with all the craziness of the last years. When I read on the article the eval and the implications of agents self generating their code, it just clicked. Looking forward to experiment with this! kudos to the author!

guillaume_code 3mo ago

[flagged]