zby

I have made an experiment with 'idea generation' last year (with much worse llms): https://github.com/zby/DayDreamingDayDreaming

The results were promising: https://zzbbyy.substack.com/p/reinventing-daydreaming-machin...

If I remember well, the starting point was that memory is only useful if it changes the system behaviour. There are many ideas of automatic 'tips' or 'rules' that are injected into the prompts so that the agent acts accordingly to some retained lesson. But there are many failure modes for this. But maybe I'll need to revise the phrasing on that page and in instructions.

Thanks!

I am not sure if this is sarcasm - but just in case - https://github.com/sshwarts/skillscript does not offer a unified namespace for functions and prompts (agents) like https://github.com/zby/llm-do (currently in suspended development). There are now also the 'dynamic workflows' in Claude Code that are pretty interesting approach - they are like a compiled prompt in many aspects.

I did an automatic review of over 140 such systems.

There are comparisons and stuff: https://zby.github.io/commonplace/agent-memory-systems/

Deja-vu is here: https://zby.github.io/commonplace/agent-memory-systems/revie...

And the full list: https://zby.github.io/commonplace/agent-memory-systems/revie...

I believe there should be easy ways to move logic between prompts and code in a smooth ways. Moving from prompts to code is for getting deterministic, fast, well defined and cheap execution - the other way is when you want to quickly extend your system or when you want to relax a pre-condition (which is extending if you look into it deeply).

There are some inroads into this vision - but I haven't seen anything build directly for this (beside my own experiment).

I have some 'vibe noted' notes on this: https://zby.github.io/commonplace/notes/unified-calling-conv..., https://zby.github.io/commonplace/notes/rlm-tendril-and-llm-...

Frankly I just skimmed that article, and still commented, bad me.

I was also confused by the tag menu - I thought they are sections in the article - I completely failed here :(

By the way I have a page with some more sources for the context degradation phenomenon: https://zby.github.io/commonplace/notes/agent-context-is-con...

It is interesting to compare this to LLMs - they also have the bounded context that you can see as the analogue to our working memory. It can contain enormously more bits of information than the 4 things the article says is the capacity of our working memory - but the 4 things can probably be much more complex internally - they are more like 4 pointers probably.

But at some level context engineering is very similar to what this article talks about.

select text and comment on it - then let the llm read all comments

The feature I am waiting for in all of these editors is integrating 'red lining' as a channel for LLM input. This is the best interface for working on a text. https://www.roughdraft.md/ does the core idea pretty well - but is not well integrated with the rest (browsing, etc).

If the action is decided by code based on metadata - then what is really the LLM task? And if you say that it is only the type of action that is decided by code - then this is maybe a mitigation - but the llm still can do a lot of harm. And also it is very limiting - using the llm to decide the action is very useful. This is different from SQL injection - where the action is determined by the code and the injection is really making a code parsing error.

It might still be the way to go - but calling it 'the real solution' is overselling it.

They do predict what injections might be effective - so it is a theory. I don't know how novel it is and it is not very deep (as you noted the general mechanism is quite obvious) - but they do it quite systematically so it is useful.

The video seems to be about mushrooms.

The fact that programmers can be nerd sniped into yak shaving some random libraries is the only thing that keeps Open Source running.

I would love to hear from someone knowledgeable - is that bad for the company or good?

I am open to changing my mind and I am looking forward for answers to your question - but I think it is like a click bait - looks interesting - but not really useful.

I am building my self-hosting llm-wiki system (https://gist.github.com/karpathy/442a6bf555914893e9891c11519...). My approach is to start with a theory of how such systems could work. Then since llms can interpret theory - this theory becomes an executable llm-wiki system itself.

It's called Commonplace: https://zby.github.io/commonplace/

I think I fixed this in a later revision. Does that persist?

There is also https://github.com/Dicklesworthstone/pi_agent_rust

I vibed a comparison/review of these two systems using my llm wiki: https://zby.github.io/commonplace/work/pi-agent-zerostack-co...

(the prompt is in https://zby.github.io/commonplace/work/pi-agent-zerostack-co...)

"In the 890s, having recently converted to Orthodox Christianity, Boris ensured his church would be independent from the Patriarchate of Constantinople." --- I thought Orthodox Christianity was created by the Great Schism in 1054.

And how they are doing? I think this might be a solid research program - but that blog presented it as some kind of practical approach.

So no hope for https://xkcd.com/810/?

First you need to write these specifications and if you say just tell the llm to write them - then how would it be different from just tell the llm to write the program?

I guess you can argue that these are two independent processes so you can combine them to get something more reliable than both - this might be a viable path. But from what I heard writing formal specifications is just really hard - I haven't seen anything practical in this area.

I concur - it does not make sense to do in llm prompts what can be done in code. Code is cheaper, faster, deterministic and we have lots of experience with working with code.

Especially all bookkeeping logic should move into the symbolic layer: https://zby.github.io/commonplace/notes/scheduler-llm-separa...

""" we need to build:

    Formal specification layers that agents execute against, not just prompts

It is probably easier to just write that program.

It is not novel - but with the new models it is just becoming practical.

If you have a test that fails 50% times - is that test valuable or not? A 50% failure rate alone looks like a coin toss, but by itself that does not tell us whether the test is noise or whether it is separating bad states from good ones. For a test to be useful it needs to have positive Youden’s statistic (https://en.wikipedia.org/wiki/Youden%27s_J_statistic): sensitivity + specificity - 1. A 50% failure rate alone does not let us calculate sensitivity and specificity.

I can see a similar problem with this article - the author notices that LLMs produce a lot of errors - then concludes that they are useless and produce only simulacrum of work. The author has an interesting observation about how llms disrupt the way we judge knowledge work. But when he concludes that llms do only simulacrum of work - this is where his arguments fail.

I don't know - looks like an interesting idea - but ... I am struggling to put that in a polite manner. When I go into the repo and find out that it does stuff like lip syncing of talking avatars then I start to think what percentage of the development effort goes into marketing?

The other reviews are based on published articles - but I am not sure if I want to continue this - because it is hard to keep them honest.

Maybe you can use the instructions from my repo - which are here: https://github.com/zby/commonplace/blob/main/kb/agent-memory... and run them on your code directory? Then send me the result.

I like how the author notices that it really got a start with cloud computing.