Claude Code for Business: How We Run Our Company on It, and What Still Needs a Human Yes

As of 28 October 2026 · checked by Oskar Korjus

I build the systems kratt runs on. This post is about our own setup, not a client's. Our company's memory is a folder of plain text notes, and Claude Code works inside it with us. I left out anything I could not check against our files today.

If you run a business and are weighing Claude Code, the list of things our agent may not do is the part worth copying. How we work with clients is in what an audit-first AI consultancy is, and who we are is on our about page.

Where the agent works: a shared Markdown vault in git

The vault is a folder of Markdown notes in a private git repository. We read it in Obsidian, and the same folder is the working directory where Claude Code runs. Obsidian's help page on how it stores data says: "Obsidian stores your notes as Markdown-formatted plain text files in a vault." So the agent reads and writes the same plain files we do.

Everyone writes into one shared set of folders, and nothing is locked. Writers do not collide because every note gets a unique filename, a date or a slug. The obsidian-git plugin commits, pushes and pulls every five minutes, and it is set to sync by merge, not by rebase. The reason for that setting comes further down.

The vault started on 4 June 2026. On 28 October 2026 it held 1,886 tracked Markdown notes. We and the agent write to it, and 1,457 of those notes, about three in four, carry the tag that marks a note the agent wrote. Every note the agent writes must carry that tag. The tag records who typed the note, often at our request. It does not mean the agent decided anything.

Two instruction files load at the start of every session. One holds the vault's conventions, the other the agent's role and safety rules. The agent never deletes anything: it only creates, appends or moves. And keys and tokens never go into the vault.

Claude Code's documentation on how Claude remembers your project says what such files can and cannot do: "Claude treats them as context, not enforced configuration." The same paragraph says that to block an action regardless of what Claude decides, you use a hook. The guards further down exist because of that limit.

In June 2026 we took three hook ideas from an open-source vault template and wrote them ourselves, with no third-party code. We turned down its transcript backup hook. It would have copied full session transcripts into the shared vault, along with any secret or client personal data pasted into a session.

What the agent does alone, and what needs a human yes

On its own, the agent writes briefs, drafts, analyses and notes straight into the vault. It reads live systems with read-only access. When it is unsure, it writes a proposal for us instead of guessing. One line in the conventions file sums up the default: "Drafts are fine; sending needs a human nod."

The other list is short. The agent's rules say: "Never on your own, in any tier: send to a human, spend, delete, write to the CRM, publish, raise a volume cap." We made one standing exception, and it stays inside the company: once a post of ours is published, the agent shares its link in one internal Slack channel, with a suggested comment for each of us, without asking first. Everything else that leaves the vault goes in one order: the agent drafts, a person approves, a person sends. Live systems are read-only by default, and writing to one needs a lane we approved separately.

Choose, do not author

The line between the two lists is a rule we sum up as choose versus author. The agent may choose between options a person already approved: reorder a worklist, move a weight inside a range we set, add an exclusion it can back with evidence, write its own briefs. It may not author anything new: a new rule, new instructions for itself, a changed threshold, or anything outside a range we declared. Those go to a proposal and wait.

OWASP's entry on LLM06:2025 Excessive Agency recommends the same two things: limiting what an agent may do in other systems "to the minimum necessary", and using "human-in-the-loop control to require a human to approve high-impact actions before they are taken." How we keep human review in the systems we build for clients is on our trust page.

Six Claude Code hooks, and the problem behind each

A hook is a command Claude Code runs at a fixed point in a session. The hooks guide says this "gives you deterministic control: certain actions always happen rather than relying on the LLM to choose to run them." The hooks reference adds that a hook running before a tool call can block that call.

We run six hook scripts at six points: session start, each prompt, after a note is written, before a Slack post or a shell command, when a turn ends, and when the session ends. Two of them block. One holds a turn open once. The other three only inform or warn.

Guard	When it runs	What it does	The problem behind it
Session brief	Session start	Pulls first, then shows the last 48 hours of commits, new inbox items and blockers that wait on a person	Other writers' work was invisible unless you read the git log
Filing hint	Each prompt	Suggests filing a note when a message sounds like a decision, a win or a wrap-up	After the vault's first week the decisions folder was empty, while decisions were being made in chat
Note check	After a note is written	Warns about missing frontmatter, a missing AI tag or a note with no links	32% of notes had no links in or out at our June audit
Slack guard	Before a Slack post	Refuses the post and says how to fix it	Slack rules written in prose were broken within four days
Corrections guard	Turn end, session end, after writes	Holds a writing session open once per draft until corrections given in chat are saved as rules	Saving them depended on the model remembering
Rebase guard	Before a shell command	Refuses a rebase pull in the vault	The vault jammed in September, and a rule kept in memory did not hold

The Slack guard

We wrote rules for how agent sessions post to Slack. Agent sessions broke them within four days, so on 17 August 2026 the rules became a hook that refuses a post before it is sent. It allows no bot direct messages and no unknown channels. Every post needs a fixed first line, every ask needs a named person, and there is a length cap. The guard runs before the human yes, which still applies.

When the guard refuses a post, its message tells the agent how to fix it. The comment in its test suite gives the reason: "an agent that gets 'denied' learns nothing". The suite runs offline. On 28 October 2026 it ran 43 cases and all passed. Its header also explains why we do not test the guard by firing a real message: that "only proves anything if the guard is loaded; if it is not, the test IS the incident."

The alerts we switched off

Scripts can crowd out people too. In one week in August, 68% of the 56 messages in the Slack channel meant for us to talk to each other came from about 14 scripts. One alert lane had sent 155 posts in 14 days from 11 scripts without a single human reply, so in September we switched most alerting off. A script may now reach a person only when waiting would cost money, a client or legal exposure. Everything else goes to a local log.

The vault stopped syncing twice in September

The first time ran from 2 to 6 September 2026. A state file that one of our scripts writes was left halfway through a merge, so the automatic pull at session start failed in every session. The brief printed a warning third in its list, we read it as noise, and 273 commits piled up unseen. Now files that scripts write merge by keeping the local copy, since the next script run regenerates them anyway. A failed pull prints first in the brief, with the number of commits we are behind.

The second time ran from 7 to 9 September. This time a rebase had stopped halfway. Git kept asking us to resolve merge conflicts in a tree that had none. Aborting the rebase and pulling with a merge cleared it: six script-written files were resolved, and no Markdown note was touched.

On 9 September a rule against rebasing the vault went into the agent's memory. It did not hold. Our usage audit on 22 October found a session that had still run a rebase pull in the vault. That day the rule became a hook that refuses the command. On 28 October we fed the hook test events offline: it refused a rebase pull and allowed a merge pull.

The same audit summed up which of our earlier fixes lasted. What survived was code wired into a path we already walk. What died needed a person to keep a habit, or a new command nobody used. In the audit's words: "Warning-only guards don't change behaviour."

Decisions go into dated files

The vault's inbox holds proposals, decisions and handoffs. Nobody edits an existing inbox note: a reply is a new file, and an idea we killed stays on record.

Decisions we want to keep go into a dated file, and a script builds the decision index from those files. Nobody edits the index by hand. When the index was generated on 26 October 2026 it listed 86 decisions: 8 in force, 11 replaced by later ones and 67 with no status set. That last number is our weak spot. Most decisions were filed and never marked as reviewed, and some decisions are still made in chat and never filed.

A decision note on its own does not bind the agent. A rule that has to hold in every future session also goes into the agent's instruction file. Before we added that step, one rule sat in a single decision note for five days.

A council for decisions we cannot undo

For one-way-door decisions we run a council of seven agents. Three members read our notes, each through one lens: skeptic, revenue or risk. An outsider reads only the raw facts, never our own conclusions. Two judges rank the four answers without names, the ranking is added up in code, and a chairman writes the verdict. The chairman may not smooth over where the members disagreed. If they all agree, the note has to say that agreement inside one model family is weak evidence. We do not run it on copy, because "councils average toward bland". Its output is one note, and nothing is sent.

It has run twice, on 26 and 28 October 2026, and each result is still a recommendation waiting for our sign-off. In the first run all four members gave the same answer, and the note flagged that as weak evidence. On 26 November 2026, if no council run has changed a decision, we retire it.

What we counted in 34 of our own work sessions

We counted 34 of our own Claude Code work sessions that started between 8 and 22 October 2026: 27 in the workspace we use for client work and 7 in the vault. A counting script that lives in the vault did the count.

• About four in ten prompts were six words or fewer: 349 of 871 (40%), or 313 of 753 (42%) with a stricter filter that also drops text Claude Code inserts on its own.
• 17 of the 34 sessions ran long enough that Claude Code compacted the conversation at least once, 29 times in all.
• Most of the agent's actions were shell commands: 6,033 of 8,336 tool calls (72%). 182 tool calls (2%) returned an error.
• 87% of the agent's turns (15,668 of 17,980) ran in the workspace we use for client work, and 13% in the vault.

Many of the short prompts are approvals after the agent offered numbered options, a word like "send" or "ship". The count measures length, and it cannot tell an approval from an instruction.

These are our own logs, from one machine over 15 days. There is no control group, and they say nothing about time saved. A session is one transcript file, so a session left open for days counts once. Claude Code deletes old transcripts after about 30 days, so the oldest sessions in this window start to disappear in early to mid November, and the count cannot be repeated after that.

If you want Claude Code in your business

This is what we would do again, in this order.

1. Start read-only. Give the agent read access to the systems that matter and write access to nothing live. Claude Code's permission rules let you set a tool to allow, ask or deny, and the docs say deny rules are checked first.
2. Write the two lists down. Put what the agent may do alone and what needs a human yes in the instruction file it loads every session. Our dividing line is choose versus author.
3. Keep a decision log. Dated files and a generated index are enough to start. Expect gaps, and count them.
4. Add a guard only after a real problem. Each of our six hooks traces back to something that went wrong. Where a warning was ignored, make the guard block.
5. Test a blocking guard offline. Feed it test events. A live test of a guard that is not loaded is the mistake itself.

The vault is plain text and the rules are sentences, so neither needs code. The hooks are scripts, so someone has to write and test them.

If you want an agent like this in your company, start with our automation service. For where an agent fits in your wider plan, see how to write an AI strategy. For what an agent costs to keep running, see our post on AI running costs. If your company is in Estonia, our page on AI consultancy in Estonia describes how we start.

What this post does not claim

• It does not claim the agent saves us time. We have not measured that.
• It does not claim our session logs show anything about other companies. They are our own logs, from one machine, over 15 days.
• It does not claim every decision gets filed. 67 of the 86 indexed decisions have no status, and some decisions are still made in chat.
• It does not claim the council works. It has run twice and faces a kill test on 26 November 2026.
• It does not claim the hooks catch everything. Three of the six only inform or warn.

kratt is an audit-led AI systems partner in Tallinn: we work out where a company loses time, money or information in its workflows, then build the practical AI, automation or systems integration that fixes the most valuable part.