Field Log #1: I gave four AI agents a company rulebook and made them run an approval workflow

This is an English edition of a post originally written in Japanese, with added context for readers outside Japan. The Japanese text is the version of record —日本語版の原文はこちら.

Field Log #1

Subject under observation: our own AI agent setup (Claude Code, with four agents: secretary / PM / finance / engineering)

Observed on: 2026-07-24

Change since last log: none — this is the starting point of the series

What the next log will compare: (1) number of active projects, (2) whether the rulebook was amended, (3) how many deliverables got sent back in quality review

This records what was actually built and run at that point in time. The tools and rules will change. Read it as a snapshot of lived experience, not as a recommendation.

Context for readers outside Japan

The Japanese original assumes two things its readers already know. If you are reading in English, they are worth spelling out, because they are the reason this setup looks the way it does.

“Ringi” (稟議) is a real Japanese management practice, not a metaphor. In a traditional Japanese company, a proposal is written up as a document, circulated to each relevant department, stamped by each one in turn, and only then approved by the top. It is often criticised as slow. But it has one property that matters here: every step leaves a written artifact, and the reasoning behind each judgment is recoverable afterward. What I built is a ringi workflow where the departments are AI agents. The bureaucracy that makes ringi frustrating for humans turns out to be almost free when the participants are software — and the auditability you get in exchange is exactly what is missing when you delegate work to an AI.

A “one-person company” (一人社長) is a common and fully legal structure in Japan. One human is simultaneously the CEO, the accountant, and the person doing the work. The tax and legal framework treats it as a real corporation. So the roles I split across four agents are roles I would otherwise be switching between myself, several times a day.

With that context, the rest of this post is a translation of the Japanese original.

Lead

This is the first Field Log on the blog “AI Evolution Archive.” The subject under observation is not AI itself, but the setup that puts AI to work: our own AI agent operation. Later logs will build on this one by comparing against it.

When you start a company alone, you end up doing “CEO,” “finance,” and “the actual work” all by yourself. Every decision means switching hats, going back and forth between the person approving and the person being approved. It wears you down in a quiet, cumulative way.

So I used Claude Code (Anthropic’s coding agent) to implement not human employees but four AI employees. Secretary, project manager, finance, and engineering — each defined as an independent agent with its own persona and its own authority, with the company’s rules written into a single document that all of them have to obey.

This post records that design, and what happened when I ran one real project through it — the launch of this very blog — following the sequence: CEO instruction → filing → planning → ringi review → approval request → implementation. It is not a staged experiment. This article is itself one of the outputs of that workflow.

1. Why give an AI a company rulebook

Handing work to an AI agent is no longer unusual. What I was interested in was one step past that: how do you guarantee the quality of the judgments you delegated?

An AI agent will act when instructed. But if the instruction is vague, or if the standard it judges by shifts with the mood of the moment, what accumulates is a pile of inconsistent output. This is especially true for decisions involving money (how much am I allowed to spend?) and decisions that face outward (is this okay to publish?). Those tend to collapse into a binary: ask every single time, or let it do whatever it wants every time.

What I tried instead: fix the judgment criteria in advance as a single written rulebook, and let agents with role-separated authority operate only within that boundary. It is the same idea as a human company having employment rules and a delegation-of-authority policy — applied to the composition of AI agents.

2. What went into the rulebook — investment limits and a delegation matrix

The rulebook is one document. Two things matter most.

Investment criteria were fixed as numbers, up front. Initial investment per project, total new investment per month, and additional recurring charges each got a deliberately small ceiling, set in advance as a figure. Anything above it requires the proposal to state “over limit” explicitly, attach the reason and the expected payback, and get advance approval from the CEO. Deciding the numbers first is what lets the finance agent judge “is this inside the limit or not” on its own, every time.

What is delegated and what needs approval was split into three tiers (the delegation matrix). Internal work is classified as delegated (no report needed), report-after-the-fact, or advance approval required. The dividing principle: reversible actions get delegated; irreversible ones need approval — money moving, anything published externally. There is also a rule that when in doubt, treat it as requiring advance approval.

This gives the agents an explicit boundary between “keep going on your own” and “stop here, always.” Structurally, it is meant to prevent accidents like publishing the blog on its own or signing up for a paid service on its own. (At the design level, at least. Whether it holds up over long-run operation is unverified — see below.)

3. How the four AI employees divide the work

On top of the rulebook sit four role definition files, each running as a separate agent with its own persona.

Secretary — takes the CEO’s instruction, files it as a formal document, creates the project folder, routes it to the right department. Reports to the CEO in inverted-pyramid form, with conclusion, decisions-needed, and deadline in the first three lines. Explicitly constrained from judging whether the content itself is any good.
PM (project manager) — works out feasibility (direction, tools needed, effort, rough cost) and writes the plan. In the execution phase, checks deliverables from an adversarial angle: list the reasons to send this back first, then decide pass or fail.
Finance — reviews the money side of proposals. Judges “approve / send back / over limit (needs CEO approval)” against the numeric criteria in the rulebook, and is required to leave its arithmetic visible.
Engineering — implements against the approved plan. Must restate the spec to the PM before starting, must not submit unfinished work as finished, and does not perform external publication or deployment. (This post was written in the engineering role.)

All four share the same code of conduct: no deference (never agree without grounds, and flag errors even when they come from above), report bad news first, and separate fact from inference — label the unverified as unverified. The repeated appearances of “unverified” in this post are that rule being applied directly.

One clarification. The rulebook defines the operating departments as eight functions — general management, finance, planning, PM, engineering, sales, PR, and audit — separately from the secretary. “Four AI employees” means the secretary plus the three of those eight that currently exist as independent agents (PM, finance, engineering). The unimplemented general-management function is temporarily covered by the secretary in this first phase, and the audit function’s fact-checking role is temporarily covered by the PM.

4. A two-phase decision workflow

Work runs in two stages.

Planning phase (the CEO approves once, here): CEO instruction → secretary files it, creates the folder, routes it → PM works out feasibility → finance reviews the money → general management checks company-wide consistency (covered by the secretary in phase one) → secretary checks the format and submits the approval request → CEO approves the plan and the budget envelope together.

Execution phase (inside the approved scope, progress needs only reporting): engineering implements → PM runs quality review (also covering the audit function’s fact-checking in phase one) → general management decides completion (secretary, in phase one) → completion report to the CEO via the secretary.

Exceeding the budget, changing the spec, or anything involving external publication sends it back for approval again.

The point is that the CEO does not have to weigh in on every detail — the agents can carry the procedure forward autonomously inside what has been approved. The inverse is the actual design goal: decisions that leave that boundary — spending money, publishing externally — always come back to a human.

5. What actually happened on this project

This is the core of the first-hand record. The launch of the blog you are reading was itself run through the workflow above.

A written instruction came from the CEO, specifying the investment conditions (small ceilings assumed in advance), the strategic constraints (no mass production, few but high quality, built on primary sources), and that the final call on the theme stays with the CEO.
The secretary created the project folder and routed it to the PM.
The PM worked out feasibility and wrote a plan with three candidate themes (hands-on review, deep dive into one domain, news curation), each annotated with monetisation routes, competitive situation, and how much CEO involvement it would need. It also compared the cost of a custom domain plus rented server against a free blog service.
Finance reviewed the plan against the numeric criteria and confirmed, with the arithmetic shown, that both configurations were within limits.
The secretary checked only the format — not the merits — and submitted it to the CEO as an approval request.
The CEO approved the theme, the site configuration, and the budget envelope (recorded formally, with date and decision-maker), and the execution phase began. Engineering — the author of this post — then produced the setup guide and the draft of this first article.

None of this was scripted and then performed by an AI “as if it had gone well.” It exists as actual files inside the project folder: the instruction, the plan, the finance review, the approval request. That is what “primary source” means in this post.

6. What I can say, and what I cannot

What holds up so far

Fixing the judgment criteria as numbers up front makes mechanical steps like financial review genuinely delegable. The finance agent produced its verdict with the comparison shown numerically.
Splitting roles into separate files and writing down what each one must not do kept overreach from happening — engineering did not publish, the secretary did not rule on merits — at least across this one project.
Because the planning-phase outputs all exist as files before approval, who judged what, on what grounds, is recoverable after the fact.

What is still unverified — stated plainly

This kit was built the same day. Long-run effectiveness has not been measured at all. Whether it breaks down with several projects in parallel, whether the rules ossify over months — open questions.
Whether the “quality of judgment” actually improved, measured against the cost (AI usage fees, operational overhead), has not been quantified. It remains a subjective impression.
The setup described here was built for one company of one person. Whether it transfers to other structures or industries is unverified.
On monetisation: this project is still mid-flight between planning and execution. Revenue and search traffic are both currently zero, and nothing here is exaggerated. The plan is to track staged KPIs — article count and quality in months 1–2, search traffic in months 3–4, revenue in months 5–6.

7. Summary, and what gets checked next

Even as a solo founder, writing the judgment criteria down first and letting role-separated agents operate against them does move you away from deciding literally everything yourself. But this is one project and one day of lived experience. It is not enough to claim an effect.

From here, using the operation of this blog itself as the material, I will keep tracking:

whether the workflow keeps functioning with several projects running in parallel
whether situations actually arise where a rule nearly gets broken, or does get broken (does the internal review and audit mechanism work?)
how the numbers move — effort, cost, search traffic

as dated snapshot records in future posts.

Field Log #2 will compare three things against this post (observed 2026-07-24): (1) the number of active projects, (2) whether the rulebook was amended, and (3) how many deliverables were sent back in quality review.