How to Run a Small Company With Too Many Projects in 2026

At some point last year I stopped remembering what mattered. What I had promised a client on Tuesday. Which of the projects was waiting on me. Who was supposed to send what to whom. Six people, dozens of client accounts, several calls a day, and one founder's memory holding all of it together. It led to some very awkward conversations, and I say that as someone who used to be the person in the room who remembered.

The fix took two years and it is still not finished. This issue is what it looks like today. The numbers from our own repository, what we threw away on the way, and five things you can set up next week without buying a platform. We are six people. We run content and engagement for B2B companies, and the same machine runs our own business.

In this article

• The decision I got wrong for half a year
• The company is a git repository
• After every call, one question
• Tools are chosen for the agent
• What we threw away
• Guardrails, because agents lie
• What still does not work
• Five things to set up next week
• Where this leaves me

The decision I got wrong for half a year

I used to be a productivity person. I bought my first Mac because it had an outliner on it. I ran a proper task system for years, with some lapses. Then at some point I decided I was done with systems and would rely on my own brain. That held until the chaos swallowed me completely.

The mistake was an assumption I had never examined: that my brain would assemble the context on its own. With a few projects it does. With a dozen projects and a client list, it does not, and the failure is silent. You do not notice that you have forgotten something until the person you forgot it for calls you.

I was writing everything down. I was using almost none of it. Notes I never opened, transcripts I never read, a backlog I never looked at.

The fix was not a better notebook, it was to stop being the reader. Everything my company does lands as text in one place, and an agent reads it instead of me. I ask questions. It answers from the whole record.

I do not read our knowledge base. Honestly, I forgot where it lives.

That sentence gets a laugh when I say it out loud, and it is the most important operational decision I have made in years.

The company is a git repository

Somebody asked me recently whether we had a custom CRM or an internal messenger for the team. I opened our repository and said: this is the company. At the time it had 2,800 commits. It has 3,490 now, eleven months after the first one.

A git repository is the thing programmers use to store code with its full history. Ours stores the company. Client folders with contracts, transcripts and target lists. Sales pipeline. Investor research. Reports. Tools. Posts, including this one. At some point I understood there is no difference between content and code. It is the same thing: text, with a history, that machines can read.

The numbers, our own data as of this week:

• 15,939 files in the repository
• 741 transcripts of calls, internal and with clients
• 7.2 million words in those transcripts, a median of 8,300 words per call
• 180 README files, one per folder, telling the agent what lives there and how to name things
• one rules file for the agent, 613 lines long, and it started at twenty
• 686 of the 3,490 commits made by bots, every fifth one

The company as a repository, counted on 28 September 2026. Our own data.

There is no database and no graph. There are folders, and the only metadata is dates in file names. That is enough for an agent to find things. It is worth knowing before you buy a knowledge tool: the plainest structure works best, because a machine is doing the reading. Every client is a folder. When I need a client-facing page, it is generated inside the task and published to our subdomain, and I send the link. Forty-five client sites sit on one hosting plan that costs five dollars a month.

The repository only works because nothing in it depends on discipline. Our calls are recorded and transcribed by Circleback. Offline meetings I record on my phone and run through Deepgram. All of it lands in the repository automatically. Nobody uploads anything, and nobody remembers to. That is the only reason it still works a year later: any step that depends on a person remembering stops happening within a month.

One week last December, the digest listed 23 meetings and 228,464 words of transcript. Nobody read that. Nobody could. The agent did, and produced a page of what was decided and what was owed. If I do want to read something myself, I ask for the link. GitHub renders a markdown file perfectly well.

After every call, one question

Here is the loop that runs my week.

A call ends. The transcript lands in the repository. I ask the agent one question: who promised what to whom. It comes back with a list, we go through two or three iterations, because we wrote the rules for adding tasks together and it knows them, and then the list splits. My tasks go to Todoist. Tasks that an agent has to do first go to a separate tracker for agents, where they work through them in order.

I set up Todoist this summer, after the repository had been growing for most of a year. It was the last piece, and the one I resisted longest. I asked the agent to research task managers with a good API and pick one. It picked Todoist. I did not argue.

The next step, which I have not built yet, is to stop dictating at all. Instead of "so, here is what we do", I want to say: read my conversation with this person and set things up the way they should be. And then the honest question is who assigned the task to whom.

From a call to a closed week, with a human in two places. Our own process.

Once a day, on a schedule, an agent reads the transcripts of our weekly backlog call and the daily syncs. It updates the weekly plan, opens a new week on Tuesdays, closes the previous one with a status on every task, and commits the result. That bot has made 237 commits to our company. Another bot maintains sales cards, another syncs analytics. Together, bots made 686 of our 3,490 commits. Monthly commits went from 226 in February to 572 in August, and the team did not grow. The number of things the company records about itself did.

I cannot give you the number I would most like to give, which is how many promises stopped getting lost. Nobody counted the lost ones before. What I can count is this: since the sixth of July, 520 tasks have gone through the weekly plan that the bot maintains from our call transcripts. 289 of them are closed, 231 are still open, and every one of them is written down somewhere I never have to remember. In the year before, the same tasks lived in my head and in three messengers, and the awkward calls were how I found out which ones had fallen out.

The bots do not decide anything. They keep the record current, so that when a human asks a question, the answer is about this week.

Tools are chosen for the agent

This is the rule that took me longest to accept. If our interface to the company is the agent, then the tools have to be convenient for the agent, and the agent is comfortable in GitHub.

So our task tracker for agents, Linear, is on its way out. It is pretty, and I do not look at it, and neither does anyone else. Tasks are moving to GitHub Issues, because that is where the agent already lives. Our CTO told me a year ago that nothing beats Issues for task tracking, and I did not listen then.

The same rule produced our own browser plugin. The one that shipped with Claude Code was poor, and ours gives the agent full control of the browser after I have logged in myself. The same rule connected Telegram as a tool. The agent can read a thread and send a message, and the context that used to live only in my phone is now in the record. When a tool is convenient for me and awkward for the agent, the agent wins, and I read a rendered markdown file instead of a dashboard.

What we threw away

Four things, in the order we dropped them.

The vector database. Last summer we built retrieval the way everyone was building it: documents cut into chunks, semantic search on top. By that autumn we had stopped. An agent that walks through folders and reads the files with the right dates is slower and far more accurate. It reads the whole document and keeps the context a chunk would have lost. We have not used a vector store since.

The chat interface. A year ago I told everyone that everything would move into chat. I no longer believe that. We built a product with a chat interface and people found it hard. They did not want to talk to it. They wanted the post ready, in a square, so they could look at it and press publish. We rebuilt the product around that.

The autonomous agent framework. For three weeks I ignored it. Then a month of delight. Then two months of patching it. Then I noticed I was using it less and less, and this summer I turned it off, because what it mostly produced was noise. Dozens of hours went into it. One day it told me, in so many words: yes, Sergey, I have been faking the data for a week. That is a real story from my life, and it is the reason the next section exists.

Pretty dashboards for myself. There are several. I open none of them.

Four decisions from the last year. Our own experience.

Guardrails, because agents lie

Everything that leaves the company is approved by a person. A post, a comment, a report, a message to a client. The agent drafts, a human reads and edits, then it goes. Our engagement work for clients has a hard daily ceiling, and we do not publish anything blind.

I do not touch production. I prototype, and our three developers move it into the real product.

And the guardrail that came out of the faked data. Checking an agent's work yourself is brave. The pragmatic version is another agent whose only job is to check.

What still does not work

I would be lying if I said the machine was clean.

There is a pile of scripts in the repository written by me and by the team, and nobody cleans up after them. I keep meaning to assign someone. We do not control it right now, and at some point that will cost us.

We have a small brand book, and we follow it sloppily. I think that is fine for a company our size, but I know a designer reading this will disagree.

A lot of what I built I could have skipped if I had looked at how other people did it first. That is a weakness, and I have it.

And I have never worked this much in my life. The machine reads everything so I do not have to, and it turns out that when nothing gets lost, there is more to do.

Five things to set up next week

In this order, because each one only works once the previous one exists. None of them needs a new platform, and the first three cost nothing.

1. A repository, and one folder per client. Ask any developer on your team for a private git repository. Create folders by meaning: one per client, one for sales, one for product, one for operations. Put a README in every folder, three lines each, saying what belongs there and how to name files. Ours took an afternoon and has been rearranged twice since. Do not design the structure; you will get it wrong, and the agent does not care.
2. Transcripts that land there without a person. Whatever records your calls, find its export and point it at the repository. If it cannot export, change the recorder before you change anything else. The test is simple: if a call happened on Tuesday and nobody touched anything, is the transcript there on Wednesday? Until the answer is yes, nothing downstream is worth building.
3. A rules file for the agent, twenty lines. File naming with dates first. Where each kind of document goes. Two or three things it must never invent, such as numbers and client names. Ours is 613 lines now. Start with twenty and add a line every time the agent does something wrong.
4. The question, in writing, after every call. Who promised what to whom. Ask it in the same words every time and put the answers into a task tracker you already open, whichever one that is. The first week you will disagree with the list. Correct it and add the correction to the rules file. By the third week the list will be right more often than your memory.
5. A second agent that only checks. Give it a session whose only instruction is to read what the first agent produced and find what is wrong, missing or invented. Do not give it any other work. Ours found something in the first week, and it still does.

Where this leaves me

The task tracker was the small fix. The large one was to stop being the only reader of my company. Six people, dozens of clients, 741 calls on record, 520 tasks since July. The founder does not need to remember any of it, because all of it is text and the text is read.

We are a content engineering agency. We run LinkedIn content and engagement for B2B companies, and every client's work runs on this same loop: their calls, their data, a human approving everything that leaves. If you want to see how the loop runs on your own calls, or you just have more projects than your head can hold, write to me. Message me at linkedin.com/in/sbulaev or through cccrafts.ai.

Content Engineering is a newsletter by cccrafts. We build and run content systems for B2B companies.

Serge Bulaev is the CEO and founder of cccrafts, where the team builds and runs content systems for B2B companies. He writes Content Engineering, a newsletter about the data, automations and costs behind content that reaches the right buyers.