RRochak Shrestha

Build log · · Rochak Shrestha

Claude Code is an operations tool. I run a company's day with it.

A rota of agents with written briefs works the inboxes, scouts supply, checks the catalogue and writes the report. The setup, the loops and the limits.

Most people meet Claude Code as a coding assistant. I use it for business operations: a rota of Claude Code agents, each with a written brief, does the daily non-engineering work of Kata Jaam, the event-discovery company I run alone in Kathmandu. They read the inboxes, find and import events, check the catalogue, draft the posts and plan the retention pushes, and everything outward waits for my click. As of 17 Oct 2026 that costs me about fifteen minutes a day.

Why Claude Code and not a chat product

A chat window is good for a question. Operations is a job that repeats, touches real systems and has to leave a record. Claude Code works in a terminal on a folder of files, so it can read a brief, run a command, call a tool and write down what it did, which covers most of what a business task is.

The briefs are files. They live in the repo, they have a history, and a change to one is a diff I can read and reject. The tools are files too: the agents write to production through one command-line tool, so the path from judgement to action is code I can audit. Scheduling is the last piece. The daily, nightly and weekday loops start on their own as scheduled sessions, each one pointed at its brief, and I open the desk in the morning to clear what they filed overnight.

It also means the agent that drafts a reply to an organizer and the agent that fixes the bug that organizer reported run in the same place, on the same repo.

The rota: what the agents do each day and week

Four loops run daily or overnight.

  • Desk, daily. Reads the Instagram DMs and comments, the company Gmail, claims and removal requests. Judges what deserves an answer and drafts it. Sends nothing.
  • Scout, daily. Walks Instagram the way a person would, finds the events Kathmandu is about to have, and imports the real ones through the CLI with every field decided by the agent.
  • Catalogue, nightly and weekly. A cron checks every upcoming listing for defects; the weekly loop judges the findings against the source and files corrections.
  • Night shift, after the day closes. Takes the bugs the day found and builds fixes with tests in its own git worktree. It never deploys and never touches the main tree.

Five run weekly.

  • SEO, Tuesdays. Pulls Search Console, reads coverage and foreign canonicals, drafts what to thicken or build, pings IndexNow, updates the tracker.
  • Content, Wednesdays. Turns the month's data into a press post and journalist emails, a guide draft, and captions for the week.
  • Retention, Thursdays. Cohorts from PostHog, a scan of frustrated session replays, the weekend push plan. Drafts only.
  • Organizer success, Fridays. Checks every organizer who signed up in the last 14 days: do they have an event, is registration on, who came. Sets things up on their behalf, for approval.
  • Retro, weekly. Reads the week's journal and run log, distils lessons and proposes diffs to the briefs, never to the code.

Everything lands on one approvals desk in the admin panel, with a run log beside it that shows what each loop did and what it cost.

How a brief is written

A brief describes the job, the person on the other side, the tone, and a short list of hard limits, then leaves the judgement to the model.

From the desk brief:

Your job is the inbox. Read the Instagram DMs and comments and the company Gmail, decide what deserves an answer, and draft it. You send nothing. Every draft goes on the desk.

Most people writing in are organizers who want a listing fixed or claimed, attendees asking where, when or how to register, and people asking for a listing to come down. Give each one what they came for in the first line.

Write like a person from Kathmandu who runs the place and knows the scene. Short, warm, plain. No marketing voice.

A takedown request is answered and filed the same day. Do not argue with it. The organizer owns their event.

Never quote a weak number to an organizer. A small count reads as a reason to leave, and it is not the whole story.

Never publish a price on social. Prices change, and a price in public becomes a promise.

Never send. If something looks urgent, say so in the draft and leave it for me.

The hard limits that matter most are not in the prompt at all. Sending caps per day are enforced in code. The CLI that writes to production has no AI inside it, has a dry run for every write, and refuses a likely duplicate. Chrome is mine, used in a supervised session; no headless browser posts as the company.

What it cost in attention

Fifteen minutes is the running cost. The setup took longer, and the desk came down to fifteen minutes one loop at a time, as each loop's drafts got good enough to clear in a glance.

Every loop started in phase one: it files drafts and sends nothing. I widen a loop's autonomy when its approval rate says the drafts are right. As of 17 Oct 2026, eight months in, outward messages still wait for a click, on purpose.

The mistakes

Rules instead of briefs. The first briefs were full of if-X-then-Y rules. They produced stiff, robotic replies and still missed the edge cases, so I kept adding branches. When I rewrote them as briefs, quality went up and the briefs got shorter.

Instructions that only grew. The always-loaded instructions kept collecting rules until they were 301,000 characters at their worst. Now each gotcha lives next to the code it binds and loads only when an agent touches that surface. As of 17 Oct 2026 the always-loaded instructions are 59,000 characters, and a budget script fails the session if they grow.

Two sessions in one tree. Two sessions editing the same working tree clobbered each other's work. The night shift now builds in its own git worktree and leaves diffs for me in the morning.

The limits of running a business with Claude Code agents

No agent publishes a post, sends a DM or an email, approves a listing, places a paid feature, or deletes anything. Each of those is a row on the desk and a human click. An approved row executes at once. Drafts carry no "send later" conditions, because I would not see the condition when I approved the row.

It also does not replace judgement about the business. The retention loop reads the cohorts every Thursday and the number is still not where I want it. An agent can tell me what the cohorts say. Deciding what to build because of it is still my job.

If you want this in your business

I build the same setup for other founders, starting with one loop on an approval queue: AI operations.