Many years as a mainframe administrator of an Application called ViewDirect, flat files, pointer indexes, report layouts. Started Cliff's Notes course a couple of months back. When he talked about structure over tools, it clicked immediately. I was heading down in our project and busted up my back and my elbow, so I was kind of immobilised for the last couple of weeks. I watched a half dozen of Jake's videos and was really excited. I started building it out like I was building that report warehouse again. Not the right way. Now that I've gone back and read some of the course, it's a start. Here's a quick 12-minute (the Creative side background in tech, but what came out of it) fly-through of my vault operating as generative infrastructure. This view just showed that I'm very happy to be in the group. I really brought my mainframe experience up to date with the current technology. I felt I was lagging a month ago, two months ago, even after investing a pretty couple of years into it. The vault isn't just storage; the agents kind of came out of it, building it (Merlin & Sarah from building the vault). Stock Obsidian. No plugins. Just folders and markdown, working like flat files always did. Last, this weekend I should say, a friend and I created a quick story in an hour. We have other AI rapper programs from other groups that we use. They have a lot of genre outlines in them, just for brainstorming a story, and we sat down and did this. Then, after my friend left, added the creative content to the Vault. What happen for me was an incredible workflow. Something I'd been wanting to do for a couple of years emerged from the Vault, and here's what it is. I left a little bit at the end of this. You can just quit after a couple of minutes to see it evolve, but I left the creative process that came out this weekend in the video in there just as an example. Current constraints for me are that I see why we need a vault and what they can do. The limiting aspect seems to be the input. This is the same as we had in the old days of mainframes. You have to be able to manage your queues. I just wanted to simply update files and move things around quickly.

I have been living inside ICM for a while now, and it changed how I build. Recently I started pairing it with one more idea, and the combination clicked hard enough that I wanted to share it here and see what you all think. Quick version: ICM 2.0 = ICM (the interpretable filesystem) + Colibri style routing (a router that only wakes the experts a task actually needs). One gives you a system you can read. The other gives you a system that stays light. Together they run local and sovereign (this system build ACTUALLY helped me move the needle, i.e. KPI, creating content, closing deals, etc) --- 🗂️ First, why ICM already wins For anyone newer to it, the core of ICM as I understand it: 1. The filesystem is the operating system. Plain-text steps, one job per folder. No black box. 2. It documents itself. Every folder says where you are and what is next, so you never lose the thread. 3. It is resumable. Close the laptop, come back next week, pick up exactly where you were. 4. It is portable. What runs in your head, in an agent, or on a local model is the same folder of plain steps. The magic is interpretability. You can always open the box and see the reasoning. 🐦 The piece I added: Colibri (the router) The problem with a big system is that it gets heavy. You do not want every folder, every expert, every context loaded for every task. A hummingbird does not flap every muscle to hover, it uses only what the moment needs. Colibri is a mixture-of-experts idea applied to a whole life or business: 1. Only a sliver is ever active. Roughly 5 percent at a time, not the whole library. 2. A router picks the ~8 experts the task needs** and wakes only those folders. 3. Core stays pinned, the rest streams in** on demand and caches while it is hot. 4. It learns to predict which experts you will reach for next, so the right context is already warm. 🧬 Put them together and you get ICM 2.0 1. The ICM filesystem becomes the DNA / schema** — the canonical map of every expert the system can call.

Hey everybody! I hope you are doing well. I know I've been a little quiet the past few months, but I have some interesting news and wanted to share a little 'sauce,' if you will, that I came across while writing and publishing my new AI book on Amazon. By the way, I highly recommend that if you have ever wanted to write a book, you just do it!!! Here's my story: #1. I happened to come up with a new way to use AI (July 2025) and wanted to test whether anyone was even interested in learning it, so I posted my ideas on LinkedIn. #2. After about a month of posting almost every day, I had a good idea of what people were thinking and saying, and how to lay out the book (so I thought LOL), and I started writing. #3. I had the first version of about six chapters done and shared it with 10 people on LinkedIn who expressed interest, and 4 of them actually read it. #4. I took their feedback, revised some chapters, and wrote a couple more. #5. I then gave the book out again (V2) and connected with two people who had read the whole book and were willing to jump on a Zoom call with me. #6. As I watched the first person start using AI the way I thought it should be done, I realized she had built her 'AI Intelligence System' correctly but was still using it like a search engine, and I realized I was MISSING half the book. 🤣 #7. So I condensed the now 8 chapters down to 6 and then wrote the second half of the book, showing people how to use AI not like a search engine or an answer machine. (I call it briefing AI like a CEO.) #8. I gave that version of the book (V3) to about 100 people (A mentor of mine a couple of years ago mentioned that when you do write a book, try to get 100 people to read it before you publish it; that will give you the truth you need about whether it should be published) I received more feedback, made some tweaks, and, after writing the book 4 1/2 times, I went ahead and published it. And believe it or not, I hit best-seller status in two days. The 'secret' is to send your Amazon book link to everyone who read it and ask them to buy it at a low price the day after publishing.

Last week, I tried out Jake's icm-architect skill, which he also posted here. There were a few legitimate issues the skill found that needed fixing, and I quickly patched those in my infrastructure. What surprised me, though, was that the structural part itself (which I built before I joined here and started learning about Jake's ICM methodology) was not only completely fine, but when applied to my use case, it was even better than what the skill suggested. Jake's skill is set up for fairly general use cases, as well as for people who don't know how to organize a specific idea or project in a way that works well for agents. After I patched the holes the icm-architect skill found, I gave it some thought and created my own version. I named it Agency ICM Builder. https://github.com/krsnczky/agency-icm-builder The difference is in what it assumes. One folder per client, and keeping them apart is rule two, not an afterthought: any learning whose client is ambiguous goes to a quarantine inbox instead of getting guessed into the wrong folder. In an agency, cross-client bleed isn't untidy, it's a liability. Expertise and state are split the same way, by construction. Departments hold what's true for a service across every client, client folders hold per-client state, and the two never mix. A few weeks ago, I posted here about my memory system, for which I created a public plugin, and this new skill complements it perfectly. You could say the memory kit is the soul/brain of my infrastructure, and this skill helps you build the body around it. Once you plug the memory kit in, you'll have a very strong foundation for your infrastructure. https://github.com/krsnczky/agency-memory-kit It won't fit everyone. If you're not doing client work at all, the client separation is dead weight and Jake's icm-architect is the better starting point. And if you want a framework with a database and orchestration code, this isn't that either. It's markdown files in folders, and that's the whole design.

I run a few agents on a schedule — ones that read some inputs and then do things with side effects: send a summary, write a record, flip a status somewhere. The happy path is fine. My worry is the failed run. The cron fires again, or I re-run it by hand, and now I'm nervous it'll redo the half it already finished: a second email, a duplicate record, a status changed twice. Today I lean on a checkpoint file. The run marks each side-effect done before moving on, and on restart it skips whatever's already marked. It works but feels brittle, since the mark and the action aren't atomic — a crash between them can still double-fire. How do you handle re-runs? Idempotency at the destination (dedupe keys, upserts)? A ledger the run reads first? Splitting read from write so the write step is the only thing that has to be safe? Curious what's actually held up for you in real unattended runs.