Closed my first real retainer last month and I start in three weeks!! Putting the whole plan here because I'd rather find out now what I got wrong than in month three The situation. Family holding in LatAm, retail plus financial services, several companies under it. Monthly retainer, four hours a day on site, three months to start. What they want is the stuff that lives in three or four people's heads: why decisions get made the way they do, what got tried before, what broke. Written down, and answerable in plain language. The long game is a private system per founding partner, for succession. I'm one guy. Nothing signed yet... The plan for the first 3 months: Month 1 is entirely non-technical. Map where the knowledge actually lives, which folders, which spreadsheets, whose head. Then measure a baseline before touching anything: how long it takes someone to find an answer today, how often the person who knows gets interrupted. Without that number, nothing I build later can be compared to anything Month 2, a small non-sensitive corpus goes in and a second real user starts using it. Then a hand-written eval set built with their own person. Twenty to thirty questions, expected answer, expected source document, plus negative controls where the right answer is "no record of that" Month 3 is the part I care about. Week 11 I don't open the system at all, and we count how many queries happened without me. That's the acceptance criterion, written into the contract: the designated users operate it without the consultant present. Hard to fake on purpose Three calls I made that I'm not certain about: Cloud with a zero-retention agreement instead of on-prem, even though they asked for maximum privacy. My reasoning: on-prem means weeks of importing hardware before anything exists, the models that fit in an office server are worse, and buying only makes sense once you've measured real usage. So the architecture keeps the corpus and the index on their side and treats the model as a swappable endpoint. Reversible in that direction, not the other one

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.