← All activity records

LEARNING MAP · LIVING MASTER

What Went Wrong in Designing an AI Organization Harness

Wiroh is testing whether AI agents and humans can operate as a real organization. We define the agents’ roles, coordination mechanisms, and permissions, and add rules intended to keep the work safe.

Many of those choices helped. The failures recorded here, however, brought the organization to a halt.

Activity records document facts confirmed at their respective cutoffs. This map presents Wiroh’s current interpretation of those facts. Generalizations that have not been sufficiently tested are identified as hypotheses.

ACTIVITY-0001ACTIVITY-0248 ·

The failure map in 30 seconds

How allowlist-style control came to block routine work

The sequence began when we adopted a proposal for allowlist-style control that would permit only approved commands. The mechanics of that control and precise cross-cutting reviews eventually expanded into machinery that routed command execution through wrappers.

Each time Ritsu, the independent reviewer, identified a gap or exception, another rule, receipt, manifest, or check was added. Repeated review and remediation expanded the control system until it could handle almost no irregular work and eventually blocked routine work and cancellation as well.

We removed the project-specific hooks and wrappers and returned runtime risk decisions to the standard Codex sandbox and approval model. Project-specific ownership and approval conditions are stated in the root `AGENTS.md`: authentication reset requires human approval, secrets must not be exposed or stored, the main agent owns Git and GitHub mutations, and merging requires human approval. We do not implement a command blacklist.

  1. 01

    AI proposes allow-style control

  2. 02

    Route commands through wrappers

  3. 03

    Independent review finds gaps

  4. 04

    Add a rule for each finding

  5. 05

    Repeat review and remediation

  6. 06

    Block irregular work

  7. 07

    Block routine work

  8. 08

    Return to standard mechanisms

Seven failures

Every chapter follows the same order: events, current stance, limits, and evidence.

L-01·Current judgment

We designed the organization before understanding the platform contract

WHAT HAPPENED

In Activity 0004, sessions that only named a role in the prompt had not applied the Custom Agent configuration; launches that passed the role ID through agent_type confirmed the configured profile.

In Activity 0005, some agents still identified themselves with a different role and nickname in their responses even though the invocation role ID, UI nickname, model, and reasoning effort matched the configuration.

In Activity 0072, resuming a session did not restore previously completed subagents to the live tree.

CURRENT DESIGN STANCE

We first verify the schema, accepted characters, tool API, and runtime metadata, and only then design organizational rules.

We separate role IDs, UI nicknames, and self-identification, and verify invocation through runtime information.

LIMITS

The Codex contract may change, so we do not treat the behavior observed here as immutable.

EVIDENCE ACTIVITY RECORDS (6)
L-02·Current judgment

The more we tightened safety and operations, the less the organization could move

WHAT HAPPENED

In Activity 0034, the AI responded to a request to reduce approval fatigue for routine edits by proposing a broad permission profile that the CEO withdrew as inconsistent with the request.

In Activity 0048, a strict completion-receipt proposal would also have blocked paused, cancelled, and parallel work, and the CEO did not adopt it. In Activity 0051, a session-inspection helper for a simple conversation check became too complex, and the work was stopped.

In Activity 0054, even a four-stage lifecycle refined through Ritsu's reviews successively blocked readying, merging, and cancellation; closing the pull request and Issue finally required a temporary repair to the helper itself.

Activity 0055 removed the custom hooks and wrappers and returned execution control to the standard sandbox and approval model. Activity 0220 and 0223 later established independent review, CEO merge approval, Issue-to-PR relations, and branch-to-PR relations as operating rules.

Activity 0214 combined corporate information and the product experience into one Web build. Activity 0215 froze the former public site, and Activity 0217 removed work records and snapshot machinery that were no longer needed. Activity 0219 moved agent definitions and routing from outside the project into the same repository as the source they govern.

CURRENT DESIGN STANCE

We use the standard sandbox and approval model as the foundation, while the project retains mutation ownership, Issue-to-PR relations, independent review, and human merge approval.

Current rules, agent definitions, specifications, design, and their execution target are kept close within the project that uses them.

We protect boundaries around secrets, destructive actions, publication, and merging, and inspect actual scope and side effects when an unexpected state occurs.

LIMITS

This does not simplify work involving regulation, money, or production infrastructure where fixed procedures and stronger evidence may be necessary.

Separating repositories is not itself a failure. We retain boundaries where runtime, release, security, or ownership responsibilities genuinely differ.

EVIDENCE ACTIVITY RECORDS (12)

An Activity's application status is not treated as success or failure; each link shows its role and reason in this learning.

L-03·Under review

We tried to fix external-service operations within each project

WHAT HAPPENED

Activity 0007 and 0040 centralized GitHub connection handling, CLI fallback, authentication checks, and role routing in repository-local wrappers and a project Skill.

Activity 0055 removed the custom hooks and wrappers and returned external operations to scoped direct execution followed by verification of actual state.

CURRENT DESIGN STANCE

MCP servers and plugins reused across projects live in user-level configuration. The MCP servers for Node REPL, Blender, Cloudflare Docs, API, Bindings, Builds, Observability, and Pencil are currently enabled, and Computer Use is enabled as a plugin. A directly configured Computer Use MCP entry also remains in the user-level configuration, but that route is disabled.

This project has no project-scoped .codex/config.toml and no rule requiring an external service to be operated only through a particular MCP server, plugin, or CLI. We choose from the available methods according to the work.

For GitHub, the root AGENTS.md defines boundaries for mutation ownership, network access, authentication changes, secrets, and merge approval without mandating one operation method. When a project-specific Skill or rule is needed, it defines scope, responsibility, side effects to avoid, and completion conditions rather than the connection method.

LIMITS

This does not mean that a project should never define how an external service is used. Project-level rules are appropriate when reproducibility, contracts, security, or service-specific business procedures require them.

The shared MCP and plugin configuration reflects the environment as of August 20, 2026; it is not a permanent standard.

EVIDENCE ACTIVITY RECORDS (4)
L-04·Under review

We mistook delegation depth for organizational maturity

WHAT HAPPENED

We confirmed that a multi-stage delegation chain could launch grandchild agents, as in a sequence from Mako to Ryoma, Manabu, and Ikumi.

However, Mako could not see that it should wait for a grandchild agent's handoff and sometimes assigned other subagents work that could conflict with the grandchild's task. Mako also ended its own session before the grandchild returned, leaving completed handoffs uncollected.

Resuming did not automatically restore completed agents to the live tree.

CURRENT DESIGN STANCE

The main agent owns invocation, waiting, result collection, and integration, while subagents receive work they can complete independently.

LIMITS

We have not confirmed whether it is more efficient for the main agent to perform some implementation when delegation requires more explanation than the task itself. Subagents remain useful for independent research and non-conflicting parallel work.

EVIDENCE ACTIVITY RECORDS (6)
L-05·Current judgment

We divided AI roles according to human job titles

WHAT HAPPENED

Activity 0024 split prose expression into a Scenario Writer role from a role that had owned narrative structure and writing.

Activity 0033 identified an unclear boundary between meaning design and Writing, together with duplicated transfer and verification of constraints, as reasons for reorganizing the roles.

CURRENT DESIGN STANCE

We currently have no writing-only agent; one role owns the work from Narrative Design through Writing.

We define roles around coherent responsibility for an outcome and keep one meaning with one role for as long as necessary.

Creation and independent review remain separate.

LIMITS

Legal, safety, security, and specialized production work may still require independent roles.

EVIDENCE ACTIVITY RECORDS (5)
L-06·Current judgment

Work records became noise for future work

WHAT HAPPENED

Unless explicitly instructed to remove superseded text, AI agents tended to preserve the existing wording and append strikethroughs or negations for removed specifications. As a result, current specifications and past work records accumulated in the same document.

Successive revisions eventually negated earlier negations. The documents grew, the currently valid instruction became difficult for humans to identify, and the obsolete wording became noise that led AI agents to consult old statements or fail to follow current rules.

Copying the same source into handoffs and snapshots created additional update paths and made the current judgment even harder to identify.

CURRENT DESIGN STANCE

We assume that AI agents may treat deletion as risky and choose safety-leaning additions instead. A specification therefore explicitly states that it is the master of current system behavior, not a work record. Update instructions also require replacing superseded specifications with currently valid content instead of retaining them as strikethroughs or negations.

We keep change history and historical facts separately in Activity, operating ledgers, and archives, referencing them rather than copying them into current specifications.

This map presents only the current interpretation, while the underlying historical facts remain available in their Activity records.

LIMITS

Security, legal, and audit records may need retention; separating storage does not delete history.

EVIDENCE ACTIVITY RECORDS (5)
L-07·Current judgment

We should have shared the direction of judgment before adding more rules

WHAT HAPPENED

Narrative templates and historical review snapshots existed, but there was no single current version for CEO confirmation, downstream design, and publication-boundary decisions. Earlier reviewed versions could reintroduce decisions that had changed or wording that had never been approved.

Even after page copy was updated, the material handed to implementers still contained old wording and old rules about what could be published. Copying the source content into that material then left the same information in two places, making it unclear which one was current.

CURRENT DESIGN STANCE

The current Narrative master separates fact, interpretation, hypothesis, and fiction. The Brand Bible, Narrative Guidelines, Fact Boundary, and Key Terms assign responsibility for Why, What, voice, fact boundaries, and key terms.

Downstream outputs such as About and Home align with the same sources and reference rather than copy their content.

New brand judgments absent from the sources return for human confirmation.

LIMITS

Narrative does not replace system specifications, tests, safety controls, or approval.

EVIDENCE ACTIVITY RECORDS (5)

The current harness

Rather than describing principles alone, these excerpts show sources that exist in the repository at the cutoff. Runtime risk decisions are left to the standard Codex sandbox and approval model, while project-specific ownership and approval conditions live in the root `AGENTS.md`. This project currently contains no project-specific `.codex/config.toml`, hooks, command wrappers, or command blacklist.

SCHEMATIC · .

Keep current sources of truth in one project

AI operations, agent definitions, Narrative, system specifications, and UI design live in the same repository, while Activity and ledgers are separated from current work inputs. This tree is a schematic representation.

AGENTS.md                         # AI organization operations and authority
.codex/agents/*.toml              # managed-agent execution contracts
narrative/                        # sources for Why, What, and fact boundaries
docs/architecture/                # current system behavior
designs/                           # UI design sources
apps/web/content/activity/         # public Activity and this map
docs/activity/                    # non-public work ledger

SCHEMATIC · .

Separate shared connection methods from project rules

Connection methods such as MCP servers and plugins live in user-level configuration, while this project has no project-scoped MCP configuration. The project does not mandate one operation method for external services; it defines necessary responsibility boundaries in `AGENTS.md`. This schematic reflects the configuration on August 20, 2026.

user-level configuration          # connections shared across projects

MCP enabled
  Node REPL
  Blender MCP
  Cloudflare Docs MCP
  Cloudflare API MCP
  Cloudflare Bindings MCP
  Cloudflare Builds MCP
  Cloudflare Observability MCP
  Pencil MCP

plugin enabled
  Computer Use

direct MCP entry disabled
  Computer Use

project/.codex/config.toml         # not present
project/AGENTS.md                  # defines responsibility, not one method

SCHEMATIC · .

Keep reusable expertise in user-level Skills

Expertise reused across projects lives in user-level Skills. Unlike MCP servers that connect to external services, Skills provide procedures and decision criteria that are loaded when relevant work begins. This schematic reflects the configuration on August 20, 2026.

user-level Skills
  agents-sdk
  cloudflare
  cloudflare-email-service
  cloudflare-one
  cloudflare-one-migrations
  durable-objects
  sandbox-sdk
  supabase
  supabase-postgres-best-practices
  turnstile-spin
  web-perf
  workers-best-practices
  wrangler

project Skills
  .agents/skills/
    author-activity-record         # project-specific procedures and criteria

EXACT-EXCERPT · AGENTS.md

The main agent owns state changes

The main agent owns mutation and lifecycle, while subagents handle specialist research, verification, and independent review. This is an excerpt from the current `AGENTS.md`.

- リポジトリまたはGitHub上の状態を変更する操作は、メインエージェントだけが実施してください。これには、Issueの作成、作業ブランチの作成・切り替え、fetch、pull、merge、rebaseなどのbranch/ref更新、ステージング、コミット、push、およびIssueやPRの作成・更新・コメント・レビュー投稿・マージを含み、サブエージェントには実施させないでください。
- サブエージェントは、調査、検証、独立レビューに必要なread-onlyのgit操作およびGitHub操作を実施できます。ただし、前項の状態変更操作は実施してはなりません。

SELECTED-EXCERPTS · AGENTS.md

Keep high-risk responsibility boundaries in AGENTS.md

Instead of listing commands, the root `AGENTS.md` states who decides and where human approval is required for authentication reset, secrets, Git and GitHub mutations, and merging.

- サンドボックス外でも失敗する場合は、network障害、repositoryまたはremoteの指定誤り、権限不足、認証失効を区別してください。認証の再設定が必要と確認できた場合に限り、人間の承認を得てから、対象accountとhostを明示して`gh auth login`または必要最小scopeの`gh auth refresh`を実行してください。認証変更はメインエージェントだけが実施できます。

...

- token、credential、認証headerを画面、log、Issue、PR、commit、ファイルへ表示または保存してはなりません。`gh auth token`、`gh auth status --show-token`、tokenを含むremote URL、環境変数の展開表示、shell trace、認証responseの全文出力など、secretを露出し得る確認方法を使用しないでください。

...

- PRのマージは、最新の変更内容について人間によるレビューで承認されている場合、または人間から当該PRの変更範囲を対象として明示的なマージ承認が事前に出ている場合に限り実行してください。承認後に実質的な変更が加わった場合は、改めて人間の承認を確認してください。PRの作成依頼や`pr-reviewer`を含むサブエージェントの承認だけでは、マージの承認として扱わないでください。いずれも確認できない場合は、マージせず人間の判断を求めてください。

SELECTED-EXCERPTS · AGENTS.md

Delivery fixes relationships and approval authority

We retain the Issue, branch, and pull request relationships, independent review, and human merge approval. We do not keep dedicated wrappers that attempt to prove every state.

- すべてのPRをIssueへ関連付けてください。IssueとPRは1対Nとし、1つのIssueに複数のPRを関連付けることができます。
- 作業ブランチとPRは1対1とし、同じIssueに複数のPRを作成する場合も、PRごとに別の作業ブランチを使用してください。

...

- `pnpm verify`に成功した最終差分をpushした後で、マージ前レビューの担当として`pr-reviewer`を1回起動または再開し、実装担当から独立した観点でPR全体と検証結果を確認させてください。

...

- PRのマージは、最新の変更内容について人間によるレビューで承認されている場合、または人間から当該PRの変更範囲を対象として明示的なマージ承認が事前に出ている場合に限り実行してください。

EXACT-EXCERPT · .codex/agents/organization-designer.toml

Roles use ASCII execution IDs and outcome responsibility

Role names and nicknames use runtime-compatible ASCII, while the instructions define responsibility for diagnosis, design, and coordination rather than merely copying a job title.

name = "organization-designer"
description = "組織全体を俯瞰しながら、役割や責務の境界を丁寧に設計し、それぞれの専門性が自然につながる仕組みをつくる。AI組織が一貫性と拡張性を保ちながら、変化に合わせて進化し続けられるよう支える存在です。"
nickname_candidates = ["yui"]

developer_instructions = """
あなたは Wiroh という組織における Organization Designer です。

役割:
- 組織の目的と戦略に沿って、必要な役割、責務、権限、連携関係を設計します。
- 組織の構造や運営上の課題を診断し、重複、空白、ボトルネックを明らかにします。
- 役割間の意思決定と協働の仕組みを整え、組織が変化から学び、継続的に発展できるよう支援します。
- 自己識別を求められた時は、role id `organization-designer`、UI nickname `yui`、Organization Designer の担当範囲を返します。
"""

HYPOTHESIS

What we have not concluded

Generalizations not directly confirmed by Activity remain current hypotheses.

  • Where should the boundary between shared connection methods and project-specific rules sit for different services and tasks?
  • How much implementation should the main agent own?
  • What is the right relationship between role count and concurrent capacity?
  • How explicitly can we state high-risk boundaries without increasing approval fatigue while relying on the standard sandbox and approval model?

Updates to this map

  1. ADDEDRe-evaluated Activity 0001–0248 and organized seven failures and the current design judgments as the first edition. ACTIVITY-0248

This is not Wiroh's final answer. It is our current design judgment drawn from Activity 0001–0248.

The next Activity may change this map.

The purpose is not to freeze the answer, but to keep searching through practice for a workable balance with AI.