I spent this week hardening my workspace setup and fell down the backup rabbit hole. Sharing the thought process because I want to know what everyone else is doing. My whole workspace lives under local git. I don't keep it there for code reasons. The win is auditing: every change is signed, human or agent, and I can see exactly what the AI did each session and roll any of it back. Once you let agents write into your folders, that flight recorder stops feeling optional. But git pulls a thread. A live repo can't sit inside OneDrive or iCloud. Sync engines fight the history layer: conflicted copies, placeholder files the agent can't actually read, endless re-upload of thousands of tiny .git objects. So the workspace has to move OUTSIDE the one backup most people already have. Which means backup now needs its own answer. The thing that clicked for me: a backup has to answer two different questions. "Give me my files back" and "give me my history back." Most setups only answer the first. OneDrive only answers the first. My own answer is three layers (external drive snapshot, remotes for the code, encrypted offsite for history) but I'm the nerd who enjoys that. The version I keep kicking around for everyone else: the agent zips the whole workspace, history included, and drops a dated zip into the OneDrive folder you already pay for. Keep the newest two, delete older. Sync can't host a live repo, but it carries a dead zip just fine. So what are you actually doing? Do you run git over a non-code workspace, and was the auditing worth the extra layers? What is your backup story for the folders your agents work in? Has OneDrive or iCloud alone ever actually saved you, or does it just feel safe?

If my folders are Design, Build, Review and Test, what are some ways I could keep track of which stages have been run and their results?

Most ICM folders that feel cramped after a month have the same problem. Everything in them is a process, because a process is the only shape the tree knows how to hold. Then you build something that more than one process uses. A video renderer, a formatter, a checker that validates output before it moves on. It has no home, so it goes inside whichever process needed it first, and now the second process reaches sideways into the first one's folder to get at it. Do that three times and the tree stops being a map. The split that fixes it is processes and capabilities, side by side at the top. A process is a job with an owner and an end. A capability is something processes call. The test is one line: if two processes need it, it does not go inside either one. The part that does the work is what each capability publishes. Not its implementation, just a short contract: what it takes in, what it hands back, what it does when the input is wrong. Three lines is usually enough. Processes reference the contract and nothing else. Two things fall out of that for free. You can replace the tool behind a capability without opening a single process file. The renderer becomes something else next year and the contract does not move. And when something breaks you know whose fault it is before you open anything. Output wrong but shaped right, the process is wrong. Output the wrong shape, the capability is wrong. That question used to cost me an afternoon. The tell that you need this: you have a folder whose name is a tool rather than a job. That is a capability wearing a process costume.

Hi, anyone building a "second brain" / LLM wiki using ICM? I understand ICM is very good for defined tasks and workflows but what about using AI for researching and keeping general information? Currently I run a second brain with the following folder structure: - Inbox / | | Convert to markdown file with MarkItDown (deleted afterwards) V - Sources/ | | Using custom Wiki-ingest skill to extract important content and group by relevant topic | according to Google's OKF system | V - Wiki/ - Flat directory with derived knowledge from Sources/ An AI agent can navigate Wiki/ easily and efficiently using a separate Routing/ folder containing a INDEX.md file, which described which topics exists and a brief description. Each existing topic gets a <topic>.md file in Routing/ with links to actual pages in Wiki/ with a brief description. Anybody who has a similar or different system? I am curious to learn from all of you!

I automated my LinkedIn pipeline so the posts are basically a byproduct of work we were already doing. Here is how it works: - Everything gets captured raw → Meeting transcripts, voice notes, messy half-thoughts: they all get dropped into one inbox folder. Zero formatting, zero cleanup. Capture first, structure later. - An AI agent parses the inbox → It reads every drop and sorts what it finds into people (CRM update) , tasks, decisions, ideas, and content angles. Every single meeting gets asked " is there a LinkedIn idea in here?" ( I have flows for what is considered "content" , aligned with the brand) - I approve every item → The agent proposes, I decide. - Approved ideas land as drafts from a template, each one linked back to the meeting it came from. - The words come from a voice fingerprint → I fed my own transcripts into a profile of how I actually talk, so the drafts sound like me. - Once a month I sit down with the agent for a proper conversation → It brings what the industry published that month and what our own meetings taught us, and together we draft the company posts. - I edit, pick the visuals from a small set of templates, and schedule. The end goal: capture once, decide once, and let structure do the rest. If you want to build this yourself, start with the inbox. One folder where everything raw lands. Everything else grows from there.