The company is a folder

For some months now, a personalised Claude harness has been assisting me with my time management, organisation and goals. I have seen practical changes in my way of working; my calendar is more organised than ever, my work is more intentional, and I have less ‘noise’ in my day-to-day. As we now are building Accord, a company which puts AI to work inside organisations, I wanted us to think about building a similar harness as a ‘company repo’, which would centralise the knowledge base, keep track of progress, decisions and roadmaps as the company grows, making them navigable by an LLM to bring us the same benefits I have experienced on a personal level. I searched for existing inspiration or public repos made by someone doing a similar thing but didn’t find anything close to this exactly, so I decided to go ahead and build it myself.

The harness is set up to do a few things: keep records of company decisions over time; keep track of open and archived projects; create an asset which grows with the company over time. If these three things are done well and consistently, we would be building a ‘centralised knowledge base’ which can become very valuable over time. The value of having a company repo be an AI harness is that the AI needs everything up to date to be actually useful, which forces the documentation to actually happen.

The Structure

By taking a step back and making a list of the functions I wanted this harness to have, I made the following decisions: a small, concise set of skills would carry most of the maintainability instructions for the harness, almost nothing in the root md (CLAUDE.md is 26 lines); each folder receives its own ‘router’ md file, with instructions of what’s inside it; there will be a queue.md file which carries the open projects, categorises them by now/next/parked, keeping track of priority tasks. I kept the starting point simple, as I would like to prove the project works, before spending time adding ‘nice-to-have’ features.

The starting point includes a relationship manager - a simple CRM; a ‘projects’ folder, which in combination with the /project skill manages the open/archived projects; an admin folder which is the place to keep track of accounting, finances, insurance etc.; a record folder which keeps track of the main company context (who we are, what we do, etc.).

Caveats

The company is in its early days so keeping track of everything at the moment is simple, it will be interesting to see how the harness/repo keeps up over time as the company grows. Secondly, drift. I had to be very intentional about the architecture and instructions to restrict the project from drifting. Models today have the tendency to write verbose md files, often, which may end in contradicting documentation, outdated ideas, or straight up wrong facts. To avoid this, I restricted the nature of the changes; updates to a project timeline or to-do list require an update/overwrite of the previous version (with human approval) to avoid double entries; and the nature of the md files themselves, which should be kept short, concise, and avoiding making assumptions.