Memory over time (LLXPRT.md evolution)

[acoliver]

Because some people are really into file naming just wanted to explain why AGENTS.md isn't compelling to me.

Right now we rename GEMINI.md to LLXPRT.md mainly for trademarks and because they tended to fill GEMINI.md with crap in the early releases. Over time I dont want to rename this file per se I want to eliminate it.

Hear me out. We have already parameterized prompts in LLxprt. That massive system prompt that gemini-cli sends to your model still exists in LLxprt for now but it is served from ~/.llxprt/prompts/. There is the default but you can also OVERRIDE it per provider and model. We also have the tool and other prompts there completely overridable on a per model basis if needed. This is an artifact of three LLxprt design principles: control, transparency and multi-model.

I see LLxprt moving in the direction of agentic development. I generally do not do human in the loop development anymore. I do human in the loop QA. I plan and work with the LLM to create a structured plan then I let it just go. https://github.com/acoliver/vibetools/blob/main/executor/plans/PLAN.md

Claude Code and RooCode showed us the power of sub contexts and roles. It saves on tokens, the LLM doesn't need the whole conversation to do discrete tasks. It also helps control attention. The LLM is more likely to do exactly what was intended if it doesn’t know anything else.

Parallelism is important but I favor controlled parallelism dictated by the plan more like a DAG. Two sub agents might work in parallel on different parts coordinated by another. Their tasks dont conflict. Having a swarm with duplicates seems wasteful. I see the appeal of consensus but LLMs are generally agreeable. I prefer adversarial review and rules.

Memory and how it should work is dictated in part by the model. People evolved these massive cursor.rules files and have tried to import them into the current era. However, the models often ignore them (too long, wrong part of the context) and they are model ignorant. Moreover, subagents do not need a whole history of the world.

So what is LLXPRT.md? Many want to rename it AGENT.md and import their Cursor.rules. I'd like to evolve. Rather than tell the agent your TypeScript rules and what things annoy you, structure the environment and tools to make doing the wrong thing impossible. Inject the right prompt at the right time.

We have LLXPRT.md for now. By all means inject your 9000 line cursor.rules if that works for you. However, maybe you want to consider moving some of those into our configurable prompts associated with specific tools? They may get injected so the model pays better attention. You dont need to tell it all that stuff when it grabs the read tool. Maybe right before an edit! Maybe you tell it all about your build as it grabs the shell.

In the future we may wire more specific tools like "build" and it just does that. No hallucinating other ways to do it. Instead of telling it not to use various types, lint rules for now. Also try complexity rules. In the future maybe the edit refuses to do bad code.

In the future, I plan to add interceptors and other patterns to tools like edit. LLM tries to add an any type, it doesn't even get to the lint the edit tool tells it to stuff it. Not to say we won't have rules but they will be in the plan and task files more focused on what it is doing. They will be in the subagent definition.

Anyhow this is why no AGENT.md. LLXPRT.md is here for now because of upstream. Soon, it will evolve away. You'll work with the LLM to set up the project and the plans and other things will ensure compliance. Lets leave those 9000 line long token sucking rule files to Cursor.

Anyhow this is forward looking. I still use these things to some degree too. Just people seem really passionate about this filename. I just wanted to explain that I'm passionate about eliminating the file entirely.

[dipping5115]

This seems like a very ambitious plan (though I haven't fully understood it), but I still want to know what your project positioning for llxprt is? According to my understanding, you seem to want to position it as a complete programming assistant, even almost completely replacing human programming. Does this mean you plan to gradually abandon support beyond writing projects?

Also, I have a small question: currently, even specialized LLMs are only proficient in mainstream programming languages. If they use niche languages to develop projects, they'll face many obstacles. Do you think llxprt can allow models to achieve smooth development experiences with only relevant documentation, even if they're not proficient in a particular language? (I know this requirement might be niche, but it's indeed my current pain point)

[acoliver]

Yes this is a directional plan.

So I'm an open source guy, the community will direct a lot of what we do. I probably wouldn't have even noticed PDFs worked in gemini or didn't work when I broke it or that they didn't work in other LLMs if not for you. But because its important to one of our best users -- it is on the roadmap to fix all that sooner than later. (I just need to fix some other pluming first). Short answer - no. Whether you're writing code or document processing I think the general principles are the same. However, I'll definitely be bound to user feedback more for domains I don't understand or am not doing.

So this is a double issue. I think LLxprt can mitigate but not solve this problem. Smarter LLMs can take an example if we give them examples. However, they will still not be great at it. You can mitigate this somewhat with tools but only so far. Long term you need to finetune a model on that example. LLxprt Code's role there is to connect to that model and write the best prompts to it (through user customization).

Long term I might see a role for Vybestack there. My goal for LLxprt Code is to be completely open and hyper functional. However, very specialize things we may need to actually host a model (which costs $) and fine tune it. That might be something we I do commercially later. It's not. No, I don't want LLxprt Code to do that -- it's that only model fine tuning can actually make a real difference there.

[acoliver]

In the short term I'm going to make this configurable. Note I do not think having a long cursor.rules style AGENTS.md file is a good idea. I think we should fix the tool and the default prompts, but a core principle is developer choice. In the manwhile you can have your cusor.rules renamed AGENTS.md if you believe it to be a good idea.

[BradKML]

Cross-reference with other tools algorithmicsuperintelligence/openevolve#197

[acoliver]

Presently I'm working on subagents for llpxrt-code. We already support a single context (you can chat with multiple models in the same context just like on cursor). Subagents can be of any model. so you can coordinate with say Claude and code with say Qwen and verify with maybe GPT-5. In the future we'll have tools for creating and executing plans including adversarial multi-model verification.

[dipping5115]

I think PLAN.md indeed performs better than AGENTS.md in handling fields like programming and automation, but unless it can be used lightweight, I don't think removing AGENTS.md is a good idea, because AGENTS.md can simply be used as a prompt rather than a workflow, and its configuration is simpler and more intuitive, so keeping it would cater to lighter users.

Additionally, I noticed that llxprt scans three layers of directories to find AGENTS.md. I hope we can customize the scan depth, or scan three layers in the git directory and only one otherwise, which would help avoid misinterpretation of prompts.

[acoliver]

Interesting. Open a bug detailing that a bit more please. That behvavior comes from upstream and I think is more or less a copy of claude code.

For prompts -- remember you can override and customize them in total or per model in ~/.llxprt/prompts -- that's where the system prompts are now all defined.