I play a little game in the summer of 2026. When someone mentions AI, I substitute the word computer. We are in a unique time when people say, 'I have an AI project' or 'Are you using AI with that'. And I think it feels like a complete idea to them. So I substitute the word computer, and I quietly say, 'I have a computer project' or 'Are you using a computer with that.' Because we all are so familiar with computers we know 'I have a computer project' is an incomplete idea - When I hear computer project, I want to know what it really is. AI has many sides to it, and we are lucky in this forum to know many of them. But I think it is important to remember that some people are still coming on board and that we can help them.

Hand a cheap model a task and it re-reads everything, or confabulates the one ID that actually mattered. So I pack it instead. A Context Pack is one file: exact needles (ids, paths, values) kept verbatim, the bulk gisted, sized to half the model's window. Workers read what matters and re-fetch the rest. A manager routes each task to the cheapest Claude tier that can do it, on your subscription, never metered. Small jobs go direct. Big ones fan out under a cheap large-context model that reassembles the result. I shipped this repo by pointing the tool at itself. It said "12 ok". I believed it only after diffing every file, because a workflow once told me "ok" for work it never ran. Verify the behaviour, not the tally. Repo, MIT, built with Claude: github.com/PUSHINGSQUARES/Build Deep-dive + a fidget to try: aris-space.com/documents/dispatch/context-pack-dispatch //A<3

Most ICM setups I see here are single-operator: one person, one agent, one context tree that's basically externalized working memory. We're running it differently — as the shared know-how of a small engineering firm (~15 people: industrial automation, control-panel building, light EPC). That one shift, from personal to organizational, changes the whole problem. In a company, the context isn't just my memory — it's the procedures everyone has to follow, and procedures have to be governed, auditable, and improvable by people who will never open a terminal. Here's the core of what we've landed on. One markdown source, three readers. The ICM KB — plain markdown in GitHub — is at the same time: - the agent's operating context (what it reads to act: load costs into the ERP, build quotes, enforce the process); - the company's procedure manual, rendered into a navigable wiki — search, cross-links, the graph of how procedures interconnect — which is what employees actually read; - the ISO 9001 controlled-document system, because Git already is change control: versioned, attributed, diffed, immutable — stronger than the Word-on-a-shared-drive most small firms limp along with. No parallel copies, so nothing drifts. Git is the evidence vault; the wiki is the auditor's reading room. (Worth stating for this crowd: ISO 9001 mandates control — identification, approval, versioning, availability of the current version — it mandates no specific format. A git-backed static site clears that bar cleanly.) The agent is the abstraction layer — this is what makes it survive in a company of non-technical people. Nobody learns markdown, Git, or pull requests. They talk. The agent enforces the current procedure while they work; and when someone says "step 3 is wrong, we do Z now," it turns that into a proposed change to the controlled document. The quality lead gets a plain-language summary and approves or rejects. Proposing is frictionless and open to everyone; approving is a controlled human gate. The Git/PR machinery stays invisible underneath.