Most of my reference layer is facts the agent treats as true: this contact prefers X, that endpoint lives here, this rule still applies. the trouble isn't wrong facts, it's facts that were true when I wrote them and quietly went false. nothing errors, the agent just confidently uses a dead one. I've tried an expiry date per fact and a re-check pass at the start of a session, but expiry is mostly a guess and re-checking everything is slow. for anyone keeping a real knowledge layer and not just live workflow state: do you delete a stale fact, overwrite it, or keep it and mark it superseded so the old answer still explains a past decision? and how do you pick what's worth re-verifying versus what you just trust? curious what's actually held up for you.

I am running an ICM knowledge base for my engineering company using GitHub, VS Code, and Claude Code. The efficiency gains in our workflows have been massive, and I see a clear opportunity to offer this to other regional companies as a new business unit. ​However, this dev-centric stack creates too much friction to be presented directly as a product to non-technical clients. ​The model I envision starts with heavy consulting to align the client's processes and culture. Once maturity is reached, it transitions into a managed service: issue tracking, periodic context pruning, and ad-hoc consulting for new agentic features. ​Has anyone here successfully commercialized this philosophy? I am particularly interested in how you package the delivery and abstract the technical friction (like the IDE and repo management) for the end user. Are there platforms already solving this?

I'm deep in ICM like everyone here and folders still carry most of my work. but I kept getting bitten by the same class of bug, and it wasn't a folder problem, it was a state problem: what's running, what's half-done, who owns the next move, what's safe to resume. that stuff changes by the hour, and a folder is a bad place to keep something that changes by the hour. so I stopped forcing it. the map stays in folders, the live state moved to rows. four things actually held. One writer. agents propose, exactly one process commits. the two-agents-edited-one-record mess disappears the day you stop letting every step write. Every touch gets a timestamp. not for audit theatre, for staleness. "is this stale" stops being a feeling and becomes a query: anything open and untouched for N days gets flagged. Done means the effect exists, not that the code reached the line. a step isn't allowed to mark itself done; something else confirms the artifact is really there first, or a clean run that produced nothing quietly poisons every retry after it. Folders still win for anything a human reads: context, knowledge, the map an agent walks. I didn't move that to a database and wouldn't. rows are only for the stuff that moves. what I'm still unsure about is when to make the jump. too early and you've built a database to hold six rows, too late and you're debugging drift at 2am. the real signal for me was the third time I couldn't answer "what state is this in right now" without opening five files. where do you draw that line? what made you move state out of folders, or what's kept you from it?

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.

I’ve been testing Grok Bot for 48 hours. Not a chat. A fleet. Hour 6 was chaos. Hour 46 was seats, recipes, and the quiet click of oh, this is a desk. I’m writing what actually happened. The deep dive, not the demo. Notes stay notes. If you’re already on Claude Code and you’ve been wondering what it feels like to stop prompting and start staffing, that’s the post. Full deep dive coming on: https://aris-space.com //A<3