How I run a company with agents
Kata Jaam needs fifteen minutes of me a day. Here is who does the rest.
This is the most useful thing I know how to build. Not a chatbot: a set of agents with written briefs that do a company’s daily work, inside limits that are enforced in code, and file everything outward for a human to approve.
The loops
Reads the Instagram DMs and comments, the company Gmail, claims and removal requests. Judges what deserves an answer and drafts it. Sends nothing.
Walks Instagram like a person would, finds events Kathmandu is about to have, reads each post and imports the real ones through the CLI with every field decided by the agent.
A cron checks every upcoming listing for defects; the weekly loop judges the findings against the source and files corrections.
Pulls Search Console, reads coverage and foreign canonicals, drafts what to thicken or build, pings IndexNow, updates the tracker.
The month's data turned into a press post and journalist emails, a guide draft, captions for the week's decks.
Cohorts from PostHog, a replay scan of frustrated sessions, the weekend push plan. Drafts only.
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.
Takes the bugs the day found and builds the fixes in an isolated git worktree with tests. Never deploys, never touches the main tree.
Reads the week's journal and the run log, distils lessons, proposes diffs to the briefs. The briefs change; the code does not.
The desk
One page I clear every morning.
Every loop files on one admin page: what failed after approval first, then what is overdue, then what needs a decision, then what was approved and needs a hand. Keyboard shortcuts for approve, edit, skip. The badge counts only what needs me now. A run log beside it shows what each loop did and what it cost.
An approved row executes at once. There are no “send later” conditions in drafts, because a condition the human cannot see is an action the human did not approve.
Hard limits
What the agents cannot do.
- 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 approvals desk and a human click.
- Every write to production goes through one thin CLI that calls the admin's existing API. The CLI has no AI inside it; every write has a dry run; a likely duplicate is refused.
- Sending caps per day are written down and enforced in code, not in the prompt.
- The agents never read a competitor's account as a source, never quote a weak number to an organizer, never publish a price on social. These are written rules with the reason beside each.
- Chrome is the founder's, used in a supervised session. There is no headless browser posting as the company.
What went wrong, and the rule it became
Judgement, not rules
The first briefs were full of if-X-then-Y rules. They produced brittle, robotic work and still missed cases. The briefs now describe the job, the person on the other side, and the hard limits, and leave the judgement to the model. Quality went up and the briefs got shorter.
Approval first, autonomy later
Every loop starts in phase one: it files drafts and sends nothing. Autonomy is widened per loop when the approval rate says the drafts are right. Eight months in, outward messages still wait for a click, and that is fine.
A CLI with no AI in it
The agent decides what to write; the CLI writes it. Separating the two meant one audited path to production, dry runs for everything, and a log of exactly what the agents did that the admin can read.
Write the gotcha, in the file for its surface
Every bug that shipped became a short rule next to the code it binds, loaded only when an agent touches that surface. The always-loaded instructions were 301,000 characters at their worst; they are 59,000 now, and a budget script fails the session if they grow.
The night shift needs a worktree
Two sessions editing the same tree clobbered each other's work. Now the night shift builds in its own git worktree and leaves diffs, never deploys.
Inside the product too
The same discipline, for users.
Kai, the coach inside Livio, is the same idea pointed at a member instead of a company: an agent that calls thirty-plus tools to read and change real health data, confirms every change with one tap, computes every number in code, and ships only when a blind eval says the model is good enough. The Livio case study has the details.
Want this in your business?
The first loop ships in two to three weeks, filing on an approval queue. Describe the work you want off your plate and the assistant will say which parts I have done before.