Like a lot of people here, I started with Jake's paper. ICM made immediate sense to me, the filesystem as the orchestration, folders as stages, an agent that navigates instead of being fed. So I built with it. And somewhere along the way I realized my main workspace was never a pipeline like ICM describes. So I made a workspace builder skill off the paper, and started my first true pipeline workspace and the contrast became apparent. My original workspace has been running for months now, agent-maintained, prose-dense, and the thing I was tending wasn't a sequence of stages anymore. It was a body of knowledge. Decisions piling up, conventions hardening, old files going quietly stale, and the question I kept hitting wasn't "what runs next." It was "does the right knowledge still reach the right task." Then Google published OKF, and the pieces clicked. Markdown, YAML frontmatter, typed nodes, a semantic layer over what you know. My existing html frontmatter wasn’t sufficient enough. But OKF is a format, and it says so itself. Nothing in it governs what happens when the corpus grows for a year. The next realization came when I stopped thinking in layers and started thinking in nodes: a long-running development workspace isn't a stack, it's a graph, and it accretes. So I gave it a name. An Accretive Context Graph. What it is An ACG is a project workspace built as a growing knowledge graph of plain markdown files. Each file is a node holding one piece of what the project knows: a decision, a convention, a failure, a spec. Typed links join the nodes and state what governs what, what answers what, and what depends on what. An agent works inside the graph. It walks the links to gather the context each task needs, adds what each session learns, and regenerates the indexes, maps, and checks from the prose, so the structure stays accurate as it grows. A human directs from the edge, judging what the checks and the agent surface, deciding what stays, what supersedes, and what earns a closer look. And because the graph accretes rather than resets, maintenance is part of the work: staleness is tracked, contradictions get reconciled, growth is consolidated on a cadence.

Hi Jake & Community — Working through your folder architecture and markdown file methodology and genuinely seeing the value. The context load sequence, the living CONTEXT.md approach, the layered structure — it maps well to how I think about systems. Here's my constraint: I'm working inside Cowork & Chat without access to Claude Code. No terminal, no hooks, no automatic file loading on session start. The files are there. The structure is there. But Cowork doesn't appear to auto-load them at the start of a session — Claude only reads what it's explicitly pointed to. So the architecture exists but the context doesn't load unless I remember to trigger it manually, which defeats part of the purpose. My question: Has anyone implemented this approach in an environment without Claude Code — no CLI, no hooks, no programmatic session triggers? And if so, what's the workaround for the auto-load problem? Specifically wondering: - Is there a reliable way to trigger context load at session start without Claude Code hooks? - Is a "load my context" opener prompt the current best practice for non-Code environments? - Are there tools or patterns that approximate the Claude Code experience for desktop/non-developer users? I'm working on making the case to my org for this approach — so understanding the real implementation path for non-technical users matters a lot. Also, being in a highly restrictive, governed, and large enterprise company creates so many bottlenecks for this approach, but the value and impact of application outweighs the "risks." TYIA, Colin

So, for the last week or so I've been digging into the OKF from Google. This past weekend Jake brought it up in his Afternoon Tea session. It filled in the one thing that I wasn't grasping on my own. Its not a alternative or a replacement for ICM, its an additional layer that drops right in. Much of the OKF is built like ICM stuff, which makes sense. The big difference is that its designed about retrieving data and then feeding that into the Folder Agent. Think of it more like an Index at the back of a book that tells the folder agents, where data is and how to get it. It can be local or it can be out on the internet. Jake used an example of a topic and looking for it on Stack Overflow at this weekend's Afternoon Tea. A "traditional" ICM agent/specialist looking for that topic on Stack Overflow, would have to search the whole thing. With the OKF layer in place, the specialist sees there is a link with a BigQuery and can go straight to the source. This is handy if you are looking for certain things over and over or you need to reference some piece of data often. Its a nice structured way to pull data without a local RAG system or even NotebookLM. This is especially useful for data that might get updated over time, like census data or financial statements, you can ensure you always get the most current data. Are there a million ways to do this type of thing already? Sure. Is it the best way to do it? I don't know Is it a viable way to do it and slots nicely into ICM? Heck yeah. I will need to dig into this more. This might change the way I build my councils going forward for when I build an advisor off a real person. Instead of distilling them down into 2 or 3 md files, I can just point the LLM to interviews, papers, etc by said person to get a better responses.

If you build with Claude or any LLM as an active collaborator rather than autocomplete, this one is worth a look. TL;DR Hard-wrapping markdown at 80 characters is a 50-year-old terminal convention that LLMs now reproduce by default because their training data is full of it. In an LLM-collaborative workflow it actively hurts you: diffs balloon, grep misses matches, retrieval chunks badly, and model output drifts when half your files use the convention and half don't. The fix is to stop hard-wrapping anywhere in your project, pick semantic paragraphs (one paragraph per line) or semantic line breaks (one sentence per line) per folder based on how that folder's content gets read and edited, and let your editor handle soft-wrap for display. Treat project files as a runtime, not as documentation. The discovery I came across a Claude system prompt (https://pastebin.com/C0s47rjV) posted to Reddit, dense and content-rich but only 71 lines long, with each paragraph sitting on a single line. Then I looked at my own project files. Around 100 markdown files of decision logs, architecture specs, reference docs, and glossaries, and most paragraphs were broken across multiple lines with manual newlines at roughly 70-80 characters. Same amount of text, two to three times the line count. The system prompt was written for a machine to read. Mine were written by following an inherited convention without anyone noticing. How the convention got there The 80-column rule is roughly 50 years old. Punch cards were literally 80 columns, VT100 terminals inherited the width, and early Unix tooling assumed fixed-width displays everywhere. Email reinforced it with RFC 2822 recommending 78 characters. By the time Markdown was invented in 2004, every developer had internalized "wrap at 80" as a virtue, and Gruber wrapped his own examples that way. The spec never required it, GitHub renders unwrapped markdown identically, but the convention propagated through every README, every dotfiles repo, every "how to write good docs" tutorial.

What has everyone found to be their sweet spot when it comes to the line length of thier MD files? Wouldn't it be more efficient to have fewer lines in a markdown file but have them be higher quality? You would likely need to create more MD files, which will take more time. However from my understanding it's easier for LLMs to process higher quality MD files with more files than the other way around. I was wondering what everybody else thought of this.