Show HN: Nodecode, open-source living agent in Lisp that rewrites itself for you

github.com

2 points by svsairevanth 6 hours ago

Hi HN, we're Mike and Thom.

Agents of the future should only have one tool (the interpreter, ideally a LISP eval), nothing more or less; to interact with the world. Agents remember by writing markdown files. NODECODE remembers by rewriting itself. And that is in itself a new paradigm in working with agents. What if memories, skills, MCPs, provider connectors, tools, etc. all live under the same image as *.lisp files instead of in disarray across random folders?

Ask it for something it can’t do, and it writes what it needs into its OWN running image and keeps it even after a restart. (Changes in a LISP image have significantly lower ceremony and overhead than in harnesses written in other languages):

Small intuitive scenario:

> you can't read PDFs. teach yourself. (defun read-pdf (path) ...) ; runs at once, kept (read-pdf "invoices/0421.pdf") ;; Globex owes $1,240.00, due Oct 24, unpaid. [… rest of PDF content]

read-pdf is still there after a restart, in your terminal, and in every other UI clients (Discord, web app, etc.)

Technically at a lower level; NODECODE runs as one process in SBCL, a Common Lisp system, and shells attach to it. The model has one tool: it evaluates LISP in the running program. Code is data, so a program can rewrite itself while it runs. What the model defines runs at once and is kept, one file per definition, committed with git, loaded at every start.

Why LISP now? Current SOTA models have reached an optimum point in how they efficiently work with LISP, though not as fluently as Python. Still, we believe AGI will understand ANY language (past/present/future) by understanding the crux of any given language, and not through excessive and expensive pretraining scheme.

Why LISP in general? We believe LISP is the current language that communicates to the world with the least bandwidth.

Why another LISP agent? The LISP harnesses we found are hard to use unless you already know the language itself, and so we had this idea of simplifying and condensing the UX to be user friendly for the masses, while leveraging the power of LISP. Code as data is what lets an agent change itself, and that shouldn't need a LISP hacker to run. NODECODE is our first step toward putting it on everyone's PC and mobile. You ask in plain words, the model writes LISP, and you get briefed in natural language; that is how it should be.

Extensions? Code as data also suits extensions. We see NODECODE as a living agent organism. To us, it feels very much alive, and so this brings us to the Cells system. A Cell is a folder that teaches NODECODE something new: a chat room it can live in (e.g Discord, Telegram, Slack, etc. - Yes we made Cells for channels to have it act as a very capable personal agent), a skill, a memory, MCPs, new tools, etc. Install one from our Cell hub or ask it to write a custom, personalized one. Either way it is more code the agent can read and change.

Your terminal, a browser tab, your phone and bots in Discord, Telegram and Slack all attach to that SAME gateway process, so a tool it writes in one is there in ALL of them. Over time it becomes yours and it is continuously evolving; the organism within it; NODECODE.

MIT License. https://github.com/nodecode-ai/nodecode X/twitter/demo launch post: https://x.com/pomterree/status/2113721985167728757 docs: https://nodecode.ai/docs