A few days ago, I thought I had found a cheat code for Codex usage. During one real work segment on SOL at very high reasoning, the input was about 48.35M tokens . About 47.72M of that was cached input, roughly a 98.7% cache ratio , and yet my weekly usage meter moved by only 1%. At first I thought the interesting question was obvious: why is so much of this being cached? But I want to separate one thing immediately. I have not proven that my External Intelligence system caused the 98.7% cache ratio, and I also cannot say it caused the weekly quota meter to move only 1%. I do not want to turn correlation into a causal claim. While looking into it, I became more interested in something else. For a long time, I have been leaving parts of my AI work outside the chat: past failures, why a decision was made, conditions for stopping, restart points, and boundaries that previous agents already discovered. Then a later AI retrieves only the parts that appear relevant. For example: “This kind of completion judgment failed before.” “Under this condition, additional search was put on HOLD.” “In this repository, missing this boundary can produce a false completion.” I have started calling this External Intelligence . I am not claiming that external memory itself is a new idea. It obviously is not. Obsidian can even be one place where this kind of External Intelligence lives. The distinction I am interested in is not primarily where the information is stored, but what happens to that information afterward. Which observation remains only an observation? Which one survives repeated evidence? Which one gets promoted into reusable knowledge? When should an old rule stop being trusted? And when should a later AI retrieve an old failure boundary and allow it to change the next decision? That led me to a smaller question: Can failure boundaries left by previous AI work actually change the judgment of a later AI? So I ran a small matched comparison from the same snapshots: one side without the relevant External Intelligence, one side with it available. There were only three task pairs, so I am not treating this as a statistical claim. OpenClaw: the baseline failed a hidden countercase and produced a false completion. The External Intelligence side passed it. VS Code: same pattern — baseline false completion, External Intelligence side passed. AWS CDK: both sides correctly BLOCKED, and in this case the External Intelligence side was actually slower. The correct-completion result was 1/3 → 3/3 . In two cases, a failure boundary left by earlier AI work changed what the later AI did and avoided the same kind of false completion. But it was not universally better. On the AWS case, the judgment did not improve and it took longer. Across the three pairs, input and fresh input went down, while command executions went up. So I also cannot say “External Intelligence always makes agents faster” or “it always saves tokens.” The claim I am comfortable making right now is much narrower: knowledge left by previous AI work changed a later AI’s decision in some matched cases. That is all. In my own workflow, though, that difference has started to matter quite a lot. One thing that bothers me about AI coding is not just that an agent can fail once. It is that a stronger model can arrive later and still walk into the same boundary from zero. Strong models can already write a lot of code. But what should we investigate, when should we stop, which failure should survive into the next run, when should an old success stop being treated as authority, and whether the next loop should GO, HOLD, run under a CAP, or BLOCK — those things do not automatically accumulate just because the model got smarter. I have also been using this workflow while contributing fixes to public OSS. At the moment I have 21 direct upstream merges across 17 independent public repositories , including Apple and Sony projects. I am not claiming External Intelligence “caused” those 21 merges either. Subjectively, though, the second half has felt very different from the beginning. I chase fewer weak candidates. If another PR already owns the repair, I stop. If the expected value of continuing drops, I HOLD or CAP it. If the boundary is weak, I do not keep digging just because I already spent time on it. My sense is that the quality of the attempts I actually externalize has improved, but that is still an operational observation, not a statistical claim. The public repository is here: https://github.com/shin4141/decision-os-v13-loopkit You do not have to fork it. I recently changed the entrance so an English-speaking user can simply give the repository to ChatGPT, Claude, or Codex and ask: “Read this repository. Is there anything here that would actually help my own AI workflow?” The AI is supposed to inspect the real public files first and state what it could and could not verify. You also do not need to adopt the whole thing. I actually think trying to adopt everything at once is probably the wrong way to use it. What I want to ask here is not “please use my framework.” I want to know how this looks from outside. Does this still look like ordinary agent memory or context management with different terminology? Or does the combination of failure-boundary accumulation, evidence-based promotion, selective retrieval, re-entry, completion integrity, and loop governance look like a different operational problem? If you already built something similar, I would genuinely like to see it. And if there is a case where this idea breaks, I would rather hear that than collect another success example. submitted by /u/Powerful_Creme2224
Originally posted by u/Powerful_Creme2224 on r/ArtificialInteligence