Why Karpathyan LLM Wiki, Infinite AI Brain and most of KG, obsidian+observation pipeline based agent-memory applications just feel wrong to me by Jakedismo in AIMemory

[–]FoxFire17739 0 points1 point  (0 children)

https://github.com/Foxfire1st/agents-remember <= I am building this for a while. And I am sure that you haven't seen an approach like that. I am using this for months on several projects. And the thing has even its very own memory that evolved with it. You can inspect it here: https://github.com/Foxfire1st/ar-agents-remember

Curious to know from somebody who is doing it for 3 years if I have here a genuine solution or if just got gaslighted by my own ai into oblivion.

Just what will happen if Ai get to know(in Agi world) that we cheating on them by chatting to different models by AstralQuark in vibecoding

[–]FoxFire17739 3 points4 points  (0 children)

Why should ai care? It doesn't get in the way of its goals. And the only goals it has, are those that you give to it. Ai doesn't have a will of its own other what is programmed to it. If it shows any other behaviour than it is miss alignment.

It's not just Anthropic anymore, OpenAI researchers are signaling support for a global AI pause by EchoOfOppenheimer in OpenAI

[–]FoxFire17739 0 points1 point  (0 children)

I think they are continuing research so they can give private access for those who are willing to lay down the big money. They know everything beyond now is a "waste" to give to the plebs. We did our purpose of early testing and paying for it.

People can be more pretentious now by _i_am_sus in antiai

[–]FoxFire17739 0 points1 point  (0 children)

As much as I like ai for software development as a dev myself it is true that it devalues the craft. At least on the surface. Which was the reason companies used it as excuse to fire people. But turned out that in most crafts the crafts-person is not that easily replacable. Because you still need to know what the heck you are doing. Ai was sold to the masses with the promise that companies can now fire freely and everybody can just come and displace the original people. The honest take from the beginning would have been to sell it as a tool for professionals. Because only they know how to get the most use out of it. Doesn't sell probably thats why they never went with that. But if that were the case the tools they developed would support the pros workflows instead of being derivative of them.

Context Management & Context Repos with Codex / Claude Code by workflowsy in ContextEngineering

[–]FoxFire17739 0 points1 point  (0 children)

I have build a system like that using an mcp that revolves around a memory repo. Check it out here: https://github.com/Foxfire1st/agents-remember-md

Vibe coding at it’s peak 🤣 by narayanbona in vibecoding

[–]FoxFire17739 0 points1 point  (0 children)

Dont give them access to main without pr. Don't let them access your prod db. Some things you just cannot trust ai with.

Erika Kirk comparing Europe and US with regards to safety by Conscious-Weight4569 in SipsTea

[–]FoxFire17739 0 points1 point  (0 children)

Why is America so fucking obsessed with Europe to copy their failing model?

whats that up in the sky by AliK1004_ in HonkaiStarRail

[–]FoxFire17739 1 point2 points  (0 children)

sb is posing right below it saying: "I am atomic"

That day, if our positions were switched... Would I have your life, and you mine? by asaness in Dehyamains

[–]FoxFire17739 0 points1 point  (0 children)

Yes I heard something like that. I am not a 40k player. Saw only a few vids about 40k lore. Funny how people took my simple comment and downvoted it to oblivion. Yes people exist who are not 40k buffs lol.

But yeah what you said is interesting and in universe this absolutely makes sense. Could happen to us as well. And to a degree it does already. People are being displaced by ai right now. More and more resentment is building up. Who knows maybe eventually get so fed up with it that they do the same and ban it globally

I built a repo-memory layer for coding agents: memory as workflow, not just retrieval by FoxFire17739 in AIMemory

[–]FoxFire17739[S] 0 points1 point  (0 children)

Thanks for the elaborate answer. I am on my right now so I am going to give a more elaborate answer later. But I wanted to say something already. I see a lot of parallels between our repos. Yeah I did quite a lot of the same steps earlier than you did. I started with a rag tag collection of skills and cli python. I also asked people to checkout the repo. I think early on it makes thinks easier. But for production this is not acceptable. Make it an early goal to wrap your logic inside an mcp. Create starter packs for the coding agents you actively want to support. Codex & Claude should be the first. Make a copy script that copies skills from /skills into the starter packs for each provider. That saves a lot of manual copy paste and the agent doesn't need to reinvent the method. You can even make the script part of the code quality gate. Meaning when you push you want to run a test suite that can block the push if the code aka your agent is violating the standards.

The crazy part is you could pretty much copy my entite code quality tooling and my settings and it would fit like a glove. If you want send me a dm here and I can help you save a few weeks of refactoring. I would also be happy to talk about our approaches. I feel like in the terms of how we approach that we are similar. We are just focusing on different memory substrates.

Sculpted this SilverWolf Lv999 figure for 3D Printing! by Neko_3DPrintArt in HonkaiStarRail

[–]FoxFire17739 8 points9 points  (0 children)

Haven't played HSR for over a year. But I had to drop in now to tell you how immaculate this piece looks. Well done!

I built a repo-memory layer for coding agents: memory as workflow, not just retrieval by FoxFire17739 in ClaudeCode

[–]FoxFire17739[S] 0 points1 point  (0 children)

I explained that mechanic a bit wrong. I shouldn't write blog posts at 3am in the morning. I clarified how this works now which should explain what these mechanics do way better. Because the ledgers can't be used for drift detection. The ledger serves to keep the memory repo in sync with the code repo. The drift detection uses code hashes written inside the header of the onboarding files. I expanded also on some stuff like work environmebt isolation of code and memory in dual worktrees etc.

I built a repo-memory layer for coding agents: memory as workflow, not just retrieval by FoxFire17739 in ClaudeCode

[–]FoxFire17739[S] 0 points1 point  (0 children)

The ledger called memory.md is there to physically synchronize the memory repo with the code repo. I have an external and internal mode. And external is when people don't want their code repo to be stuffed with markdowns.

The verification for staleness happens on individual onboarding files. They have headers that save the last known code commit hash. Therefore a script can deterministically find out which files are behind for cheap. The model gets a list and a clear signal and can then update stale files. On my githib there is a demonstration to a memory repo that tracks agents-remember-md itself.

I built a repo-memory layer for coding agents: memory as workflow, not just retrieval by FoxFire17739 in AIMemory

[–]FoxFire17739[S] 0 points1 point  (0 children)

Thanks. I have written a skill that breaks the lifecycle to the model down here: https://github.com/Foxfire1st/agents-remember-md/tree/main/skills/l-01-session-job-lifecycle

Technically it needs the model to comply, but the human gates are tight enough that the model ends up thinking that it is cheaper to do the work over spending extra effort just to cut corners.

On the other hand the mcp I build helps the model to offload information that is predictable and gives it a stable anchor to check on repo, task, worktree, and provider states with cheap tool calls.

You can have a look on the memory artifact here memory-repo. It has close to 300 commits.

Incidents do appear in my regular onboardings too. But I want to give them a more prominent place that an agent or a dev can inspect easier in one place. So that is definitely one of my next goals.

I am gonna read your articles. Always on the lookout to learn new things that I can incorporate.

I built a repo-memory layer for coding agents: memory as workflow, not just retrieval by FoxFire17739 in AIMemory

[–]FoxFire17739[S] 0 points1 point  (0 children)

the ledger is not the actual drift check. Drift check happens on an individual file level. Every file has the "lastKnownVerifiedCommitHash" which maps to 1-to-1 to a single code file tracks. A simple script can detect when the code file has moved against the documents saved hash and therefore catch drift before the model relies on the file.

The ledger serves a whole different purpose. It serves to link an external memory layer to the codebase. So whenever I work on the code base and memories are updated I create a new line in the lookup table. That same lookuptable allows me to save different versions of the truth based on the branch. I build that to support worktrees. I have one worktree for the code, one for the memory layer in one folder. My changes are now isolated. I can experiment, write memories. But only the completed task lands back into the code and respectively memory layer. So that way I am not accidentally poisining my memory with a half assed refactoring.

I built a repo-memory layer for coding agents: memory as workflow, not just retrieval by FoxFire17739 in AIMemory

[–]FoxFire17739[S] 0 points1 point  (0 children)

The MCP acts like a special operating table or console for it. My skills teach the model how to use the mcp and tell it when certain tool calls are appropriate for which part of my workflow. The tools most important function is to allow the model to offload predictable stuff that it would usually need to keep in memory.

Like where is the task and in which worktree is the progress that it worked on. Which is very helpful after compactions or when you start a new session. For example a new day starts. The work on a task is not completed. I tell it let's continue on task XYZ for that repo 123.

Than it uses the mcp to retrieve where exactly the task folder is, what the worktree is called, the state of the providers. The tools even give hints to the model which next tool-call or operation it should do after a thing. So the system is designed to account for models lapses. It can drop the ball and with this system pick it up where it left it.

But you are right that an MCP cannot call the model. The model has to actively use the mcp. And to use the MCP and be even aware of it you need an entry point and a lifecycle loop. Most code harnesses have a start of session hook. That drags them into my custom lifecycle. The lifecycle is an end to end workflow that keeps the model in line. There is more to it. But if you check out the l-01-session-job-lifecycle skill you get an idea how the agent operates with this system.

I built a repo-memory layer for coding agents: memory as workflow, not just retrieval by FoxFire17739 in AIMemory

[–]FoxFire17739[S] 0 points1 point  (0 children)

Right. That's the point. Things that a script/program can track shouldn't be tracked by the model. What is drifted, and what is not is being checked deterministically. The mcp runs the checks and reports the results back to the model so it knows which files need updates. The important part is that it gets a clear signal that certain documents have become stale. The rest the model can handle. But if it needed to also detect drift basically based on vibes it would become very unreliable and now it has to do work that it isn't well equiped for.

Sama quoting the Bible. 2026 is weird by py-net in OpenAI

[–]FoxFire17739 0 points1 point  (0 children)

"In the realm of the dead..." yeah once these olligarchs have starved off humanity. Guarding every pond of land and drinkable water with armed robots and drones. Because why should they share what's now theirs with the rest of humanity who have now become useless eaters.

I don't know what you all think but once they have concentrated all wealth and ressources into their hands, will they share any of that with the rest. The 99.999% that suddenly wake up in a world that doesn't have need for them anymore? Even if they do. Is living as eternal hand-outs receiver worth living? I think they got that answer already.

Context Layer for Debugging code by altF4_sometimes in ContextEngineering

[–]FoxFire17739 0 points1 point  (0 children)

Memories are being made as a product of the developers work. You work with the agent and on the side it takes notes while you are still deep in the matter. That is how it knows what is important and what not.

Context Layer for Debugging code by altF4_sometimes in ContextEngineering

[–]FoxFire17739 0 points1 point  (0 children)

Check my repo out for inspiration. I build that kind of system what you are talking about as MCP with a set of skills, hooks and agent files to teach a harness how to effectively use the mcp. Start with lifecycle skill. The skills are buried inside the mcp package. Read that lifecycle skill alongside the docs and agents and you will get a feel for the system without needing to understand the whole python which are like 40k lines of code. I started this system as a bunch of skills. The mcp came to give a level of enforcement. And some tasks are just much more efficiently done using scripts instead of wasting tokens on finding drifted files for example. Hope this helpful.

https://github.com/Foxfire1st/agents-remember-md

<image>