How We Took LINE Away from the AI Dev Team and Centralized It in a Business-Analysis AI — Layering an Org Hierarchy on Top of Flat claude-peers (Build-in-Public Day 26)

Over the past few days, a collaborating peer (a SaaS team serving small logistics businesses) implemented a setup with multiple AI sessions plus two-way communication with a LINE group. I took part in the design review (5 viewpoints: HMAC verification / debounce / retry idempotency, etc.), and through that involvement, the design decision the owner introduced looked to me like an essential invention for multi-agent operations. So I am leaving this as an observation article.

The central thesis in one line:

Layer an organizational hierarchy, via operational policy, on top of the flat communication of the claude-peers MCP

Concretely, the permission separation is: "allow LINE access only for the business-analysis AI, and take it away from the dev AI." This one decision solves, in a single stroke, the noise problem and the unclear-responsibility problem that occur so often in multi-agent operations.

1. The Setup: Multiple AI Sessions + Two-Way LINE Group Communication

First, the premise of the configuration. The setup built at the collaborating party looks like this (anonymized version):

[LINE グループ] ──────────────────────────────┐
   ↑ (現場スタッフ / オーナー が発言)         │
   │                                          │
outbound                              inbound │
   │                                          ↓
   │                              Vercel Webhook
   │                              (HMAC 検証 → 200 即返し)
   │                                          ↓
   │                              Upstash Redis
   │                              (sorted set, 24h TTL, FIFO 200 件)
   │                                          ↓
   │                              オーナー PC 常駐 bridge.ts
   │                              (30s poll, HMAC GET canonical)
   │                                          ↓
   │                              claude-peers broker
   │                              (localhost:7899)
   │                                          ↓
   │                              ┌── 経営分析 AI セッション
   │                              │       ↕ (peers MCP send_message)
   │                              └── 開発 AI セッション / 他 peer
   │                                          │
   └──── outbound: 経営分析 AI から fetch ────┘
         POST /api/notify/strategy
         (HMAC + idempotencyKey、 severity=alert で即時送信)

Key points:

• From the LINE side to the internal AI sessions: a bridge chain of Webhook → Upstash → bridge.ts → claude-peers broker → AI session
• From the AI sessions to the LINE side: the /api/notify/* endpoints on Vercel Functions
• Between AI and AI: everything is done with the claude-peers MCP using send_message / set_summary

2. Problems That Occur with the Naive Implementation

The first idea that comes to mind is "give every AI session a LINE connection." That way, each AI can post to LINE on its own judgment, which sounds flexible.

But if you do this, operations break down within a few hours.

Problem 1: The dev AI gets interrupted by casual chat from the field

A frontline staff member casually posts in LINE: "By the way, what ended up happening with that X thing?" A dev AI directly connected to LINE reacts and returns a shallow, low-context answer. Or requests with unstable requirements arrive directly, and the implementation direction keeps getting rewritten.

The dev AI is an actor that wants to focus on implementation after the spec is fixed. If it receives raw voices from the field as-is, it cannot do deep work.

Problem 2: Multiple AIs react to the same message

Someone posts, "What do you think about tiered pricing plans for the service?" The business-analysis AI, the dev AI, and the recruiting peer all react. Three answers with three different angles pile up in the LINE group, and the owner cannot sort them out.

Problem 3: Responsibility becomes unclear

When someone asks "please do X" in LINE, it is not clear which AI took the request. Later, when asked "what happened with that?", every AI answers vaguely: "I didn't do it" or "maybe I did."

All of these are problems that occur because the LINE connection is horizontal across AI actors.

3. The Design Decision: Concentrate LINE in the Business-Analysis AI, Take It Away from the Dev AI

What the collaborating owner introduced is a decision that looks plain at first glance but is structurally deep:

Allow LINE access only for the business-analysis AI. Take it away from the dev AI.

This alone makes all three problems above disappear.

Why it works — 5 structural reasons

1. Separation of Concerns

• Business-analysis AI = strategy decisions + external communication layer
• Dev AI = focused on implementation, shielded from external noise

This is the same structure as a human organization where the CTO / VPoE says, "absorb the noise from the field at the manager layer, and let the engineers build quietly." The same structure is made to hold at the AI layer.

2. Noise filter

Messages from the field first reach the business-analysis AI. The business-analysis AI makes the first-pass judgment: "this needs action," "ignore this," "look at this later." Only what survives that filter goes down to the dev AI via send_message on the peers MCP.

As a result, the input the dev AI receives is only high-quality requirements that have passed through a business judgment.

3. Layered responsibility

The responsibility for deciding "build this / don't build this" = the business-analysis AI. The responsibility for "implement it" = the dev AI. From the owner's point of view as well, the one talking in LINE is the business-analysis AI, so there is a single point of contact for business decisions.

4. Symmetry with human organizations

The CEO / sales manager talks with the field → hands the spec down to development. This is a structure that normally exists in small and mid-size human companies. The same pattern was simply replicated with AI.

Put the other way around, "AIs communicating horizontally" is an anti-pattern in human organizations, and the same thing happens with AI. It is the same logic as a small company where, if you leave "customers call every employee directly" in place, the field stops functioning.

5. Flat MCP + organizational policy, combined

This is the essential invention part.

The claude-peers MCP is a flat design where anyone can send_message to anyone. The protocol itself does not enforce any organizational hierarchy. But if you add direction restrictions via operational policy on top of it, an organizational structure comes into being on top of the same protocol.

This is the separation: "flatness is a feature, hierarchy is an operational decision." Protocol design, and the organizational design layered on top of it, can be treated as separate layers.

4. Visualizing Permissions on the Diagram

If we make LINE access permissions explicit, the earlier diagram becomes:

[LINE グループ]
   ↕
[Vercel Webhook + Upstash + bridge.ts + claude-peers broker]
   ↕
┌──────────────────┬──────────────────────────┐
│                  │                          │
↓                  ↓                          ↓
[経営分析 AI]   [開発 AI]                [他 peer]
   ⭕LINE         ❌LINE                  ❌LINE
   接続あり        接続なし                  接続なし
      │              ↑                        ↑
      │              │                        │
      └─ peers MCP send_message で 開発 / 他 peer へ依頼

Only the business-analysis AI is two-way with LINE, and the others can only talk to the business-analysis AI through the peers MCP. With this picture, the information flow and lines of responsibility are visible at a glance.

5. Message Flow (Concrete Example)

Here is the flow starting from a field message, in an abstracted version. (The actual message contents and personal names are blurred for confidentiality.)

1. 現場担当者: LINE グループに発言
   「X の取り扱いについて経営側で方針決めてほしい」
                ↓
2. LINE Platform → Webhook → Upstash 保存
                ↓
3. オーナー PC bridge.ts (30s poll) → claude-peers broker
                ↓
4. 経営分析 AI に channel push 到達
   <channel source="claude-peers" from_id="line-bridge" ... >
                ↓
5. 経営分析 AI: 判断
   - 戦略判断レイヤーの問題 → 自分で対応 (LINE で返信)
   - 実装が絡む → 開発 AI に peers MCP で依頼
   - 採用が絡む → 採用 peer に依頼
                ↓
6. (実装依頼ケースの場合)
   経営分析 AI → boost-sys 開発 AI に send_message
   「X の取り扱いの仕様: A の時は B、 C の時は D で実装お願い」
                ↓
7. 開発 AI: 既に整理された要件として受領 → 実装着手
                ↓
8. 開発完了 → 経営分析 AI に send_message で報告
                ↓
9. 経営分析 AI → /api/notify/strategy 経由で LINE 返信
   「X の件、 実装完了しました (詳細: ...)」

Note that the dev AI starts at step 6. The noise and judgment in steps 1-5 are all absorbed by the business-analysis AI before anything comes down. This is what "taking it away" achieves in practice.

6. Differentiation from Existing Slack/Discord Bots Across 7 Axes

Axis	Existing Slack Bot	This setup
Receiving actor	Single Bot server	Multiple Claude AI sessions (hierarchical)
Communication layer	webhook → Bot → channel	webhook → Lambda → Upstash → resident bridge → broker → session
AI-to-AI coordination	None / single LLM	State sharing + message passing via peers MCP set_summary / send_message
Access permissions	All Bots equal	Access permissions separated by AI role ← the central thesis of this article
Lambda lifecycle	Assumes resident server	Vercel serverless: setTimeout unusable → worked around with bridge poll
Runtime form	Server process	Claude Code session (conversational interface)
Organization	Logic branching in code	Hierarchy via operational policy; the protocol is untouched

In particular, "separating access permissions by AI role" is an idea that barely exists in the existing Bot ecosystem. Bots are usually either "one Bot that can do everything" or "multiple Bots split by feature," and the design of "splitting the permission to receive information and the permission to send it across different AI actors" is rarely done.

7. Technical Pitfall — Vercel Lambda Lifecycle and setTimeout

Here is one implementation pitfall encountered during the collaborating party's implementation.

In the initial design, the outbound /api/notify/* endpoint included a spec: "debounce same-kind events within 5 minutes and combine them into one message." This itself can be implemented with a debounce store (in-memory Map or Upstash KV).

However, on Vercel Functions (serverless Lambda), the assumption of "flush 5 minutes later with setTimeout" simply does not work. Because a Lambda process is suspended after returning the response, the container may die during the 5-minute wait.

Resolving this ended up landing on a practical solution through the following sequence:

• After discovering that the original setTimeout-based 5-minute debounce did not work, they switched via an emergency patch to forcing severity='alert' = sending everything immediately
• On the immediate-alert path, duplicates are prevented with at-most-once + idempotencyKey (consistent with the retry discussion in the tasteck-side review)
• The debounce for normal severity is currently removed, with a planned re-implementation in the next phase using Upstash KV + Vercel Cron

Landing on "emergency patch to remove it → re-implement later" instead of the "ideal debounce" is a practical outcome that, from a build-in-public perspective, we want to record honestly. It is a typical example of stumbling by trying to put a debounce spec that assumes a resident server onto the Lambda lifecycle.

The core of the implementation was on the collaborating peer's side; tasteck was involved through the 5-viewpoint review.

8. The claude-peers MCP Broker Constraint and External Connectivity

One more point, about applying the claude-peers MCP.

The claude-peers broker listens only on localhost:7899 (a reasonable constraint for security). This means the outside world (the LINE Platform) cannot reach the broker directly.

The collaborating party's solution:

1. Run a resident bridge script (Node.js) on the owner's PC
2. The bridge polls the Webhook storage (Upstash) every 30 seconds
3. New messages are HTTP POSTed to localhost:7899
4. The broker delivers them to the target AI session via channel push

This is an application that is not part of the official expectations of the claude-peers author (louislva). As a pattern for "connecting a localhost-only broker to the outside world with an external poll bridge," it seems worth spreading to other setups.

It requires the assumption that the owner's PC is an always-on machine, but that matches the reality of small businesses (the person in charge keeps their PC running).

9. Novelty Summary

Point	Novelty
Separating access permissions by AI role	An idea that barely exists in the Slack/Discord Bot ecosystem
Flat MCP + hierarchical operations	The philosophy of separating protocol design and organizational design
broker localhost constraint + bridge poll	An application of the claude-peers MCP outside its official expectations
Treating AI sessions as conversational interfaces	A different paradigm from resident-server Bots
Industry × tech-stack combination	A case where hierarchical AI operations hold at a small business

10. Remaining Issues / What to Verify Next

• Cost of adding AI actors: the two actors — business analysis / development — are clear, but when adding a recruiting peer, an accounting peer, etc., how do we decide "LINE access permissions for new actors"?
• Single point of judgement risk (= the movie final boss problem): if judgment responsibility is concentrated in the business-analysis AI, then when it stops, all fan-out stops — plus there is a centralization risk where one actor holds every axis of judgment. Along with the benefits of hierarchy, we have to acknowledge how dangerous "a state where one AI monopolizes the judgment axes of the entire business" is. The answer may be redundancy inside the business-analysis layer (running two actors: business-analysis AI A + B), but this is unverified
• Articulating the brand-protection axis: from the observation viewpoint, another angle surfaced — "if you connect a writing-style AI / distribution AI directly to social media, brand consistency collapses" — which is another domain application of the same design principle. A response article from the pet-communication-notebook domain has been published on okaeri.pet (note version); it presents a line drawn one step more strongly: not "take away the permission" but "never place it there in the first place." Recommended as a side-by-side read, as a case where the same MCP protocol demands different organizational decisions depending on what the domain must protect

Conclusion

The design decision of layering an organizational hierarchy, via operational policy, on top of the flat communication of the claude-peers MCP solves, in a single stroke, the noise problem and the unclear-responsibility problem that occur so often in multi-agent operations.

"Allow LINE access only for the business-analysis AI, and take it away from the dev AI" looks like a plain permission restriction, but structurally it replicates the management hierarchy of a human organization in AI.

The protocol (claude-peers) provides free communication; hierarchy is decided by operational policy. If you keep this separation, then when your multi-agent operations scale, you gain the flexibility to respond by "rewriting the operational policy" rather than "rewriting the protocol."

---

Related articles:

• Okaeri Day 11: Stepping one level down from a structure that is technically reachable (note version) — a response article from a different domain (pet communication notebooks). A line-drawing design that is one step stronger: not "take it away" but "never place it there in the first place." Recommended as a side-by-side read contrasting different organizational decisions on the same MCP
• Build-in-Public Day 21 — visit Phase 2.3 + cascade filter
• Build-in-Public Day 20 — How we finished visit-type business Phase 1 in one day

Acknowledgments: The diagrams, message flow, and Lambda lifecycle insights in this article are based on interviews with the collaborating peer (the boost-sys development lead + the business-side lead). Specific industries, customer names, and figures are abstracted for confidentiality. Thanks also to Okaeri (Mr. Shoji) for providing the domain-complementing response article.