Running a company on an AI operating system: 30 days of numbers

What ran

The fleet has about 35 scheduled runs a day on working days across four brand pages (an SAP and ERP news page, two AI news pages, an accounting firm's pages) and one personal LinkedIn profile, plus hourly publishing jobs. Each run is one role with one written procedure: a desk that builds news cards from sources younger than 72 hours, a conversation role that answers comments, a video desk, a day-end report, a weekly review, a proposals role that drafts three posts a day for a person to choose from. The runtime is Claude Code on a Mac mini; procedures are Markdown files in a repository; memory is a directory of dated notes the roles read before they start.

The numbers

The four failures happened on one day, 12 October, with one cause: the account behind the fleet hit its monthly spend limit, so four afternoon runs of the conversation role did not start. Nothing was published half-done, because a run that cannot start does nothing; the morning runs of that day had already gone out, and the limit reset the same evening. That is the fail-closed behaviour we describe on the service page, seen in the log rather than in a slide.

What the table does not show: quality. A run that succeeds has passed its gates, which is a different statement from a run that produced something a reader wanted. Quality is measured by the pages themselves: impressions per card, followers per thousand impressions, comments, and the one reversible change the weekly role makes. Those numbers belong to the pages, not to this write-up.

Which gates fired, and how often

• Cold read: two independent models see only the first line of a draft and say what they think happened and whether they would read on. In the news desks roughly a quarter of drafts pass on the first attempt; the rest get one more attempt and then the desk moves to the next story. This is the gate that throws away the most work, on purpose.
• Legal check for posts about named companies: a source younger than 72 hours, an attribution verb in the sentence, the company's response included, accusation words only inside quotation marks from a court, regulator or first-tier outlet. A draft that cannot meet it is dropped, not softened.
• Humanizer and slop check on every text that leaves the machine, with one correction attempt; a second failure escalates to a person instead of publishing something weaker.
• Publish only with consent: the roles post to pages the company owns, never to a person's profile; the proposals role drafts three options a day and a person picks one by replying, or none.
• Iteration cap of three attempts per task; spend cap per day; a kill switch file that stops every role at its next start.

What people still do

• Choose. The proposals role drafts; a person decides what goes on their own profile. The weekly roles prepare at most three decisions and a person takes them.
• Answer anything about money, customers and disputes. A reply that touches a price or a complaint is handed to a person; a legal dispute is a hard stop with a message, not a reply.
• Change the procedures. When a role repeats a mistake, a person edits the Markdown procedure, not the model; the memory file keeps the reason.
• Read exceptions. One Telegram message a day per page with the numbers, and otherwise silence. Activity logs exist for audits, not for reading.

What it costs us

The runtime is one fixed monthly subscription per seat on the model provider's side, a Mac mini, and the time of one person who reads the day-end reports and edits procedures. The spend limit that fired on 12 October is that subscription's limit. Model usage inside a customer installation is billed by the customer's own cloud or provider account; we do not resell tokens.

What this proves, and what it does not

• It proves that a fleet of roles with written procedures, gates and caps can run a content and reporting operation for weeks with a handful of human decisions a day, and that the gates stop the fleet when something is wrong.
• It does not prove that the same works inside a customer's SAP or Microsoft 365 environment with their identity, their data and their auditors. That is what the four-week build is for, and the first customer installation will get its own page with numbers, anonymised, when it exists.
• It does not show quality from the reader's side. Ask us for the page metrics in the call; they are the honest version of this table.

Questions we get asked

Can we see the run log itself?

Yes, in a 30-minute call, live: the scheduler's run list, a gate refusing a draft, the day-end report of the same day and the kill switch. We do not publish the raw log because it contains the texts of every draft, including the rejected ones.

What happens when the model provider is down or the limit is hit?

Runs that cannot start do nothing and the next scheduled run tries again; nothing is queued for a later blind retry. On 12 October four runs were skipped that way and the day-end report said so.

Do the roles learn?

They read a memory of dated notes before each run and a person edits the procedures when a mistake repeats. There is no fine-tuning and no training on anyone's data; the model is the provider's standard model under a business subscription.

Would our numbers look like this?

Not in the first month. The roles above took about six weeks of procedure writing and gate tuning before they ran unattended; the four-week build we sell ends with three roles running beside your people, measured against the manual baseline, and the rest is added role by role.

Which three routines would you hand over first?

A 30-minute conversation: we map your routines, name three roles for a four-week build and send a written assessment with a fixed price. Free, whether we work together or not.

Book a 30-minute consultation

Or write to us directly: info@iteractive.ai · +421 905 452 325