Running a Company on AI

Tomohiro Iida · Published June 23, 2026 · Updated August 23, 2026

Netsujo Inc. is a small startup based in Kyoto. We run the company by combining AI agents (Claude Code) and automation with quality gates that enforce facts through mechanisms rather than relying on individual care. This article publishes the details of that operating system as we actually implement it: it is not a showcase of flashy AI use, but an account of how we run day-to-day work. Three principles anchor it: humans hold judgment, AI handles implementation and verification, and errors are stopped by mechanisms rather than caught by attentiveness alone. We describe the three layers that check everything before it goes live, the audits that run automatically every week, and the decisions we deliberately keep in human hands: positioning, publication approval, first-hand verification of facts, and ethical boundaries. We also share, honestly, what has worked and what AI still cannot do.

Key takeaways

Netsujo is a small team where humans hold judgment while AI agents (Claude Code) handle implementation and verification across multiple businesses and site operations.
Quality is enforced through mechanisms, not carefulness: third-party AI fact-checking (an operating rule), CI that automatically blocks factual errors before anything goes live, and source-required proof verification.
Every Monday morning, automated audits run for SEO, Core Web Vitals, funnel performance, and content originality, with results posted to Discord.
Positioning, publication decisions, first-hand fact verification, and ethical boundaries remain in human hands.

Why we built an operating system

Netsujo was founded in June 2023 as a small, Kyoto-based startup working in Web3 and AI. As a small team took on more businesses and more sites to run, the amount that needed checking grew faster than headcount. Relying on human attentiveness alone was not sustainable: we experienced real errors, including a misstated job title and a mixed-up date. So we changed our approach. Rather than asking people to try harder to be careful, we built errors-cannot-happen-or-get-stopped mechanisms into daily operations itself. We call the resulting collection of mechanisms our operating system internally: AI agents handle implementation and verification, automated gates enforce quality, and humans hold judgment and responsibility.

Aspect	Traditional operations	Operating system
Quality assurance	Staff try to "be careful"	Built into CI, verification scripts, and third-party AI
Catching factual errors	Left until someone notices in review	CI fails automatically on a banned-pattern match
SEO/site monitoring	Addressed after a problem occurs	Automated audit every Monday, reported to Discord
Work records	Scattered across individual memory and chat	Kept in markdown/ledgers, verifiable later
Implementation speed	Proportional to headcount	Repetitive, routine work delegated to AI and automation

Three operating principles

Humans decide, AI implements: positioning, publication approval, and ethical judgment stay with people; research, code changes, analysis, and routine work go to AI agents.
Facts are enforced by mechanism, not vigilance: relying on human attention always lets some errors through, so we require sources for claimed results, run automated checks for banned phrasing, and add third-party AI fact-checking.
Everything gets recorded: decisions, work results, and audit outcomes are kept in markdown or Discord so they can be verified later, avoiding reliance on what one person happens to remember.

Three layers of quality gates

We do not publish what AI writes as is. Every piece of work is checked by three mechanisms of different character: one is CI, automatically enforced before anything reaches production; the other two are an operating rule and a verification script. Layering mechanisms with different levels of enforcement makes errors easier to catch.

Third-party fact-checking via Codex (operating rule): Before anything is reported as complete, we run it once through OpenAI's Codex CLI (GPT) to cross-check the work against the actual repository, surfacing errors, exaggeration, and unverifiable claims stated as fact. Having an AI other than the one that produced the work check it reduces mistakes caused by the author's own blind spots.
CI that blocks factual errors (automated): Errors that have actually happened before, such as a mistaken title, a fabricated credential, an old service name, or a wrong date, are registered as banned patterns in CI. If matching text appears, the CI check fails automatically before it reaches production. Of the three layers, this is the only one that is mechanically enforced.
Proof verification requiring a source (script): Claimed achievements, such as speaking engagements, awards, or media coverage, must be registered with a verifiable source URL and a verification date; if either is missing, the verification script fails with an error. A human still checks the source content itself; the script only guarantees that a source and a verification date are always attached.

As an example: if someone's title were written incorrectly, under the old process the mistake could sit until a reviewer happened to notice it. Under this system it matches a banned pattern in the fact-error-blocking CI, and the check fails automatically before release. Turning a past mistake into a registered pattern lets the same error be caught automatically the next time.

Weekly automated audits

Quality does not hold up under a one-time check. Every Monday morning, several audits run automatically via GitHub Actions, with the results posted to Discord. Rather than checking only when asked whether there is a problem, this runs on a standing schedule.

Full GSC audit: combines Search Console and GA4 to check sitemaps, indexing status, CTR underperformance, and canonical mismatches
Core Web Vitals audit: measures mobile and desktop load speed via PageSpeed Insights
Funnel effectiveness: analyzes traffic and results for local-government and Kansai Web3 funnels using GA4 and GSC
IndexNow ping: automatically notifies Bing IndexNow of key URLs to encourage crawling
llms.txt consistency check: verifies the URL consistency of the llms.txt file provided for AI search
Originality audit: scores article content for originality and flags thin content

In addition to these, a fact-error-blocking CI check and a check for unresolved merge conflicts both run automatically before code reaches production. Serious issues found are fixed on the spot; minor ones are logged and addressed in the next cycle. We try to put as much of the path from detection to fix onto a system as possible.

What stays with humans

The more we delegate to AI, the clearer it becomes what humans must keep holding. The following decisions are never handed to a system; a person carries the responsibility.

Deciding positioning and messaging
The final call on whether something is fit to publish
First-hand verification of facts, including proper nouns and track record
Where the ethical line sits
Deciding what to build next, and what to stop doing

This operating system does not aim to reduce the number of people involved. It aims to free people to spend their time on the highest-value work there is: judgment. The more we hand implementation and verification load to AI and to the system, the more time we have to think about what to build, who it reaches, and how to stay honest.

What we learned from delegating to AI

Strength: repetitive work, such as bulk fixes, audits, and applications, shrinks dramatically with AI and automation.
Strength: quality checks built into the system are not affected by anyone's workload or condition on a given day.
Strength: because records persist, past decisions can be verified and reused later.
Limit: AI still makes mistakes through exaggeration or unfounded assumptions; third-party checks and sourced verification remain essential.
Limit: decisions about what to build and whether to publish cannot be handed to a system; they still require human judgment.
Limit: building the system itself carries real upfront cost. Starting small and growing it is the realistic path.

Summary

Running a company with AI agents does not mean replacing people with a system. It means holding firmly to a division of labor: humans decide, AI implements and verifies, and mechanisms stop errors. Even a small startup can reach stable operations with fewer oversights once quality is built into the system this way. Netsujo tests this operating system daily on its own site: building the tools we use ourselves, and enforcing our own integrity through mechanisms. We believe that discipline feeds directly into the quality of the development and analysis work we provide clients.

AI implementation service

System development service

Building an in-house SEO analytics dashboard on GA4 and Search Console

Getting AI-agent SEO work wrong: what we retracted and how we prevent a repeat

What Broke When We Put AI Agents to Work #12

We cut GitHub Actions and quality improved

Without an evidence ledger, more CI creates more ambiguous signals

The improvement did not come from checking less. It came from defining what every check proves, binding evidence to exact artifacts, separating result from validity, and deciding readiness from an evidence bundle rather than from workflow volume.

Incident Card

Every incident encouraged us to add another workflow, gate, or checker. Eventually CI produced many statuses, but the human still had to determine which result was authoritative, which result applied to the current head, and whether skipped steps had hidden additional failures.

Field	Observed condition
Symptom	Many checks but no single defensible completion decision.
Direct impact	More Actions time, reruns, and manual cross-checking.
Hidden impact	Early failures prevented later independent failures from being observed.
Incorrect premise	More workflows automatically produce more trustworthy delivery.

A green check proves less than people think

A green check proves that a specific procedure ran against a specific artifact in a specific environment and returned a successful result. It does not prove that every acceptance criterion is satisfied.

If the head changes, that evidence may become stale. If the job stopped before later checks, those checks were never evaluated. A successful deployment does not prove that an authenticated user path works in production.

Early failure can hide the rest of the failure set

One failed test step can skip content validation, title checks, scope audits, and other independent checks. Fixing the first visible failure and rerunning CI then reveals the next one, lengthening the convergence loop.

Independent checks should run independently when observing the full failure set in one pass reduces repair latency.

Define the claim before adding the check

Every evidence item should answer one question: what claim does this result support? A typecheck result can support the claim that the exact pull-request head satisfies the TypeScript type system under a particular configuration. It does not support unrelated claims about scope, security, production behavior, or review quality.

Subject: repository, pull request, exact head, environment, or deployment.
Procedure: command, workflow version, configuration, and runner context.
Result: PASS, FAIL, or INCONCLUSIVE.
Validity: VALID, STALE, SUPERSEDED, REVOKED, or UNKNOWN.
Provenance: the evidence producer and its version.

Separate result from validity

Evidence can have result PASS and validity STALE at the same time. That means the procedure succeeded in the past but no longer proves the current artifact.

Head movement should stale head-bound CI and review evidence. A defective checker can revoke the evidence it produced. Policy changes can require previously sufficient evidence bundles to be reevaluated.

Exact-head identity is the readiness spine

Current head, verified head, reviewed head, and authorized head must agree before merge. A green current CI run cannot compensate for a review that targeted an older commit.

This is an identity check, not a visual inspection task for the human owner.

Decide from an evidence bundle, not from one workflow

The controller should evaluate required claims for the current risk class: exact identity, lint, typecheck, tests, content links, scope audit, independent review, authorization, and production observations when applicable.

Each producer contributes evidence. The controller decides READY only when all required claims have valid evidence and no blocking counter-evidence remains.

Reduce redundant CI without reducing assurance

Consolidate workflows that prove the same claim for the same artifact.
Do not run expensive substrates for changes that cannot affect them, while still considering dependency impact and risk.
Run independent checks in parallel when fail-fast would hide useful failures.
Reuse valid evidence instead of rerunning the same procedure against the same artifact.
Keep observational or advisory checks out of the blocking completion gate.

Deployment is not production observation

A deployment record proves that an artifact reached an environment. Production observation proves that a required user scenario actually works there.

Systems can look healthy from public endpoints while authenticated paths fail. Completion therefore needs the production scenario evidence required by the task contract, not merely a successful deployment job.

Rule

Judge the current artifact from valid evidence, not from the number of CI checks. Every check must prove a defined claim, and result must remain separate from validity.

Guardrail

Define a claim for every blocking CI check.
Bind evidence to exact artifact identity.
Invalidate stale CI, review, and authorization automatically after head movement.
Keep independent checks independently observable.
Consolidate duplicate evidence producers.
Separate deployment evidence from production observation.
Decide completion from an evidence bundle rather than workflow status count.
Converge the external outcome to DONE or a concrete HUMAN_REQUIRED decision.

Evidence

Decision latency from head update to READY
Evidence reuse rate
Hidden failures discovered only after an earlier check was repaired
Manual verification and cross-check count
Redundant runs proving the same claim
False blocks unrelated to the current change
Use of stale evidence in readiness decisions
Production observations tied to deployed commit identity

Remaining Risk

An evidence ledger cannot compensate for weak tests, incomplete review, or narrow production scenarios. It makes the basis of a decision explicit; it does not magically make that basis sufficient.

Evidence requirements can also become rituals. Add a blocking requirement only when it addresses a concrete failure mode or business risk and the assurance benefit justifies its cost.

Series conclusion

Compile human intent into a task contract. Separate planning from execution. Keep live state outside individual sessions. Bind evidence to exact artifacts. Let the controller own transitions, convergence, and escalation.

The durable advantage is not the number of agents or workflows. It is an execution system that can reproducibly move from a goal to verified delivery without depending on continuous human attention.

Do not make the agent stateful. Make the system stateful.