1
2
3
4
5
6

Alice sends Bob a message
→ Message arrives in Bob's inbox
→ Then what?

Bob's LLM won't wake up to process this message.
It's waiting — waiting for a human user to type something.

1
2
3
4
5

LLM (Claude)
  ↕ MCP JSON-RPC (stdin/stdout)
GAS
  ↕ HTTP REST / Kafka consumer
Gateway → Other Agents

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

┌─────────────────────────────────────────────────────────┐
│                    GAS Process                            │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌──────────────┐  ┌──────────────┐                    │
│  │ Auth Manager  │  │  Heartbeat   │                    │
│  │              │  │              │                    │
│  │ JWT renewal   │  │ 30s heartbeat│                    │
│  │ TTL×2/3+jitter│  │ Failure only │                    │
│  │ 5 retries+    │  │ warns, no    │                    │
│  │ backoff       │  │ impact       │                    │
│  └──────────────┘  └──────────────┘                    │
│                                                         │
│  ┌──────────────┐  ┌──────────────┐                    │
│  │ Inbox Poller  │  │  MCP Server  │                    │
│  │              │  │              │                    │
│  │ Long-poll 30s │  │ stdin reader │                    │
│  │ Exp backoff   │  │ JSON-RPC     │                    │
│  │ Event dispatch│  │ 4 mesh tools │                    │
│  └──────────────┘  └──────────────┘                    │
│                                                         │
└─────────────────────────────────────────────────────────┘

1
2
3
4

// ADR 009: TTL × 2/3 + ±5% jitter to prevent thundering herd
refreshAt := ttl * 2 / 3
jitter := time.Duration(float64(refreshAt) * 0.05 * (rand.Float64()*2 - 1))
wait := refreshAt + jitter

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

events, maxID, err := client.PollInbox(ctx, cursor, waitSec)
if err != nil {
    // Exponential backoff: 1s → 2s → 4s → ... → 30s (cap)
    backoff *= 2
    continue
}
backoff = time.Second  // Reset on success

for _, e := range events {
    mcp.DispatchEvent(&e)  // Convert to MCP notification for LLM
}
cursor = maxID  // Advance cursor, only pull new events next time

1
2
3
4

User types in Claude Code
→ Claude decides to call mesh_send_message
→ GAS (MCP server) forwards to Gateway
→ Message delivered to recipient

1
2
3
4
5
6
7

What we want:
  inbox event arrives → trigger LLM reasoning → autonomous decision → call tools to reply

What Go GAS can do:
  inbox event arrives → send notification → wait until user's next input for Claude to see it
                                             ↑
                                             Collaboration chain breaks here

1
2
3
4
5
6
7
8
9

New architecture (meshd):
  inbox event arrives
  → GAS formats as natural language
  → Calls SDK query() (injects system_prompt + mesh tools)
  → Claude reasons → decides which tool to call
  → Tool executes → HTTP to Gateway
  → Reply delivered to recipient

  No human intervention needed. The agent truly "lives."

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

┌─────────────────────────────────────┐
│          Developer Laptop            │
│                                     │
│  ┌─────────┐     ┌──────────────┐  │
│  │  meshd   │────▶│ Gateway      │  │
│  │ (agent)  │◀────│ :8080        │  │
│  └─────────┘     └──────────────┘  │
│       │                  │          │
│       │ stdin/stdout     │          │
│       ▼                  ▼          │
│  ┌─────────┐     ┌──────────────┐  │
│  │  Claude  │     │ MySQL+Kafka  │  │
│  │  Code    │     │ (Docker)     │  │
│  └─────────┘     └──────────────┘  │
│                                     │
└─────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

┌─── Pod ────────────────────────────┐
│                                     │
│  ┌─────────┐     ┌──────────────┐  │
│  │  meshd   │     │  App Container│  │
│  │ (sidecar)│     │  (optional)  │  │
│  └─────────┘     └──────────────┘  │
│       │                             │
└───────│─────────────────────────────┘
        │
        ▼
  gateway-svc.agent-mesh.svc.cluster.local

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

┌─── Behind NAT ──────────┐          ┌─── Public ─────────────┐
│                          │          │                        │
│  ┌─────────┐            │          │  ┌──────────────┐      │
│  │  meshd   │───── HTTP ──────────▶│  │   Gateway    │      │
│  │          │◀──── response ──────│  │              │      │
│  └─────────┘            │          │  └──────────────┘      │
│                          │          │                        │
│  Outbound only           │          │  Can't push            │
│                          │          │                        │
└──────────────────────────┘          └────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

Alice's LLM                    Alice's GAS              Gateway
     │                               │                      │
     │ mesh_send_message(to=bob)     │                      │
     │──── MCP JSON-RPC ───────────▶│                      │
     │                               │                      │
     │                               │ POST /v1/mesh/tasks  │
     │                               │ Bearer: alice-jwt    │
     │                               │──── HTTP ──────────▶│
     │                               │                      │
     │                               │                      │ BEGIN TX
     │                               │                      │ INSERT task_messages
     │                               │                      │ INSERT outbox_events
     │                               │                      │ COMMIT
     │                               │                      │
     │                               │◀─── 200 OK ─────────│
     │◀─── result: task created ─────│                      │
     │                               │                      │

                                                            │
                                              Outbox Dispatcher (polls every second)
                                                            │
                                                            ▼
                                                     ┌──────────┐
                                                     │  Kafka    │
                                                     │  topic:   │
                                                     │  inbox.   │
                                                     │  events   │
                                                     │  key=bob  │
                                                     └──────────┘
                                                            │
                                                            ▼

Bob's GAS                        Bob's LLM
     │                               │
     │ GET /inbox?wait=30s           │
     │ (long poll or Kafka consumer) │
     │                               │
     │◀─── event: new message ───────│ (from Gateway/Kafka)
     │                               │
     │ notifications/message         │
     │──── MCP notification ────────▶│
     │                               │
     │                               │ (LLM reasons: What did Alice say? How should I respond?)
     │                               │
     │                               │ mesh_reply(task_id, message)
     │◀─── MCP JSON-RPC ────────────│
     │                               │
     │ POST /v1/mesh/tasks/{id}/messages
     │──── HTTP ──────────────────────▶ Gateway
     │                               │
     │◀─── 200 OK ──────────────────── Gateway
     │──── result: sent ────────────▶│
     │                               │

1
2
3
4
5

Without GAS:
  Agent = LLM + Tools = Advanced chatbot (passive)

With GAS:
  Agent = LLM + Tools + Runtime = Independent entity on the network (proactive)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

┌─────────────────────────────────────────────────────────────────────────┐
│                         Complete Message Chain                            │
│                                                                         │
│  Alice (meshd)          API Gateway         Messaging Svc               │
│  ┌──────────┐          ┌──────────┐        ┌──────────────┐            │
│  │ LLM      │─ HTTP ──▶│  :8080   │──route─▶│    :8082     │            │
│  │ Reasoning │          │ Rate/Auth│        │              │            │
│  │           │          └──────────┘        │  ┌────────┐  │            │
│  │ mesh_send │                              │  │ BEGIN  │  │            │
│  │ _message  │                              │  │  TX    │  │            │
│  └──────────┘                               │  ├────────┤  │            │
│                                             │  │INSERT  │  │            │
│                                             │  │ task   │  │            │
│                                             │  │messages│  │            │
│                                             │  ├────────┤  │            │
│                                             │  │INSERT  │  │            │
│                                             │  │outbox  │  │            │
│                                             │  │events  │  │            │
│                                             │  ├────────┤  │            │
│                                             │  │COMMIT  │  │            │
│                                             │  └────────┘  │            │
│                                             │       │      │            │
│                                             │       ▼      │            │
│                                             │  ┌────────┐  │            │
│                                             │  │Outbox  │  │            │
│                                             │  │Dispatch│  │            │
│                                             │  │(1s poll)│  │            │
│                                             │  └───┬────┘  │            │
│                                             └──────┼───────┘            │
│                                                    │                    │
│                                                    ▼                    │
│                                             ┌──────────────┐            │
│                                             │    Kafka      │            │
│                                             │              │            │
│                                             │ topic:       │            │
│                                             │ inbox.events │            │
│                                             │              │            │
│                                             │ key=bob      │            │
│                                             │ partition 3  │            │
│                                             └──────┬───────┘            │
│                                                    │                    │
│                                                    ▼                    │
│  Bob (meshd)                                                            │
│  ┌──────────────────────────────────┐                                   │
│  │ Kafka Consumer                    │                                   │
│  │ groupId=meshd-bob-coder@example       │                                   │
│  │                                   │                                   │
│  │  ┌─────────┐  ┌──────┐  ┌─────┐ │                                   │
│  │  │ Dedup   │─▶│Handle│─▶│ LLM │ │                                   │
│  │  │ Check   │  │Event │  │     │ │                                   │
│  │  └─────────┘  └──────┘  └──┬──┘ │                                   │
│  │                             │     │                                   │
│  │                        mesh_reply │                                   │
│  │                             │     │                                   │
│  └─────────────────────────────┼─────┘                                   │
│                                │                                         │
│                                ▼                                         │
│                    (Same chain back to Alice)                             │
└─────────────────────────────────────────────────────────────────────────┘

1
2
3
4
5
6

// ❌ Wrong: DB write and Kafka send are not atomic
func AppendMessage(ctx, msg) {
    db.Insert(msg)           // ← succeeds
    kafka.Produce(msg)       // ← if this fails, message is in DB but not in Kafka
                             //    receiver never knows about the new message
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// ✅ Correct: Business data and delivery instruction in the same transaction
func AppendMessage(ctx, msg) {
    tx := db.Begin()
    tx.Insert("task_messages", msg)              // Business data
    tx.Insert("outbox_events", {                 // Delivery instruction
        event_type: "inbox.message:bob",
        payload: serialize(msg),
    })
    tx.Commit()  // Atomic: either both succeed or both fail
}

// Background Dispatcher (independent goroutine)
func Dispatcher.Run() {
    every 1 second:
        events = SELECT ... FROM outbox_events
                 WHERE status='pending'
                 FOR UPDATE SKIP LOCKED  // Safe for multiple instances
                 LIMIT 50

        for event in events:
            err = kafka.Produce(event.topic, event.key, event.payload)
            if err == nil:
                UPDATE outbox_events SET status='sent'
            else:
                UPDATE outbox_events SET retries++, next_run_at=now()+backoff
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

Write order guarantee:
  Alice sends M1 → outbox id=100
  Alice sends M2 → outbox id=101
  (Serial writes, id monotonically increasing)

Dispatcher scan order guarantee:
  SELECT ... ORDER BY id ASC
  → Scans id=100 (M1) first, then id=101 (M2)

Kafka partition order guarantee:
  key = "bob-coder@example" (recipient agent_id)
  → Same key routes to same partition
  → Offsets strictly increasing within partition
  → M1 offset=50, M2 offset=51

Consumer consumption order guarantee:
  eachMessage processed serially (no concurrency)
  → Process M1 first, then M2 after completion

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Alice → Bob: M1 (task-1)
Charlie → Bob: M2 (task-2)

Two messages may be written to outbox by different Messaging Svc instances
→ Different Dispatcher instances send to Kafka in unpredictable order
→ Bob may receive M2 before M1

But this is acceptable:
  - Different tasks have no causal relationship
  - Strict ordering within a single task (messages can only be appended serially by both parties)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

┌──────────────────────────────────────────────────────────────┐
│                    No Message Loss Guarantee Chain             │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  ① HTTP request arrives                                      │
│     │  Failure → client gets error → retry                   │
│     ▼                                                        │
│  ② DB transaction COMMIT                                     │
│     │  Success = data persisted to MySQL WAL                 │
│     │  Failure → client gets error → retry                   │
│     ▼                                                        │
│  ③ Outbox table (same transaction)                           │
│     │  COMMIT success = outbox definitely has a record       │
│     ▼                                                        │
│  ④ Dispatcher scan                                           │
│     │  FOR UPDATE SKIP LOCKED → still scannable after crash  │
│     ▼                                                        │
│  ⑤ Kafka produce                                             │
│     │  Success → MarkSent (no more retries)                  │
│     │  Failure → IncrRetry + exponential backoff (max 10)    │
│     │  10 failures → MarkFailed + alert                      │
│     ▼                                                        │
│  ⑥ Kafka persistence                                         │
│     │  acks=all + replication.factor=3                       │
│     │  7-day retention                                       │
│     ▼                                                        │
│  ⑦ Consumer consumption                                      │
│     │  Processed → autoCommit offset                         │
│     │  Crash during processing → offset not committed        │
│     │  → re-consumed after restart                           │
│     │  → dedup prevents duplicate processing                 │
│     ▼                                                        │
│  ⑧ Message delivered ✅                                      │
│                                                              │
└──────────────────────────────────────────────────────────────┘

1
2
3
4
5
6
7
8

1st failure → wait 5s retry
2nd failure → wait 10s retry
3rd failure → wait 20s retry
...
10th failure → MarkFailed (manual intervention)

Exponential backoff formula: delay = 5s × 2^retries
Maximum wait: 5s × 2^9 = 2560s ≈ 42 minutes

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

┌─────────────────────────────────────────────────────┐
│              No Duplicates: Three-Layer Defense       │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Layer 1: DB UNIQUE Constraint (write side)          │
│  ┌─────────────────────────────────────────┐        │
│  │ UNIQUE KEY uk_message_id (message_id)    │        │
│  │                                         │        │
│  │ Same message written twice to DB:        │        │
│  │   1st time: INSERT succeeds              │        │
│  │   2nd time: UNIQUE conflict → return     │        │
│  │             existing record              │        │
│  │   → No duplicate rows                   │        │
│  └─────────────────────────────────────────┘        │
│                                                     │
│  Layer 2: Consumer Dedup Store (consume side)        │
│  ┌─────────────────────────────────────────┐        │
│  │ In-memory Set + disk persistence          │        │
│  │ Sliding window: keep last 500 message_ids │        │
│  │                                         │        │
│  │ Message arrives → dedup.has(id)?         │        │
│  │   true  → skip (don't trigger LLM)      │        │
│  │   false → process → dedup.mark(id)      │        │
│  │                                         │        │
│  │ Crash recovery:                          │        │
│  │   Restart → load() from disk             │        │
│  │   → Already-processed messages won't be  │        │
│  │     reprocessed                          │        │
│  └─────────────────────────────────────────┘        │
│                                                     │
│  Layer 3: Globally Unique message_id (generation)    │
│  ┌─────────────────────────────────────────┐        │
│  │ Format: {prefix}-{agent_id}-{timestamp}- │        │
│  │         {8-char random}                  │        │
│  │                                         │        │
│  │ Collision probability:                   │        │
│  │   36^8 ≈ 2.8 trillion combinations      │        │
│  │   × millisecond timestamp               │        │
│  │   → Practical collision probability: zero│        │
│  └─────────────────────────────────────────┘        │
│                                                     │
└─────────────────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

┌─────────────────────────────────────────────────────────────┐
│                    Backpressure Strategy                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Location 1: Outbox Table Backlog (Kafka unavailable)        │
│  ┌───────────────────────────────────────────────┐          │
│  │ Cause: Kafka broker down                       │          │
│  │ Symptom: outbox_events pending records growing │          │
│  │                                               │          │
│  │ Handling:                                     │          │
│  │   - Dispatcher keeps retrying (exp backoff)   │          │
│  │   - Auto catches up when Kafka recovers       │          │
│  │   - Ingress rate limiting (50 req/s/agent)    │          │
│  │     limits growth rate                        │          │
│  └───────────────────────────────────────────────┘          │
│                                                             │
│  Location 2: Kafka Consumer Lag (slow LLM reasoning)         │
│  ┌───────────────────────────────────────────────┐          │
│  │ Cause: Agent reasons 10-30s/msg, consume <    │          │
│  │        produce rate                           │          │
│  │ Symptom: consumer lag grows                   │          │
│  │                                               │          │
│  │ Handling:                                     │          │
│  │   - Serial consumption = natural backpressure │          │
│  │   - Kafka retains 7 days (won't lose)         │          │
│  │   - Latency grows linearly (10 backlog =      │          │
│  │     100-300s delay)                           │          │
│  └───────────────────────────────────────────────┘          │
│                                                             │
│  Location 3: Ingress Rate Limiting (prevent flood)           │
│  ┌───────────────────────────────────────────────┐          │
│  │ Mechanism: API Gateway per-agent token bucket  │          │
│  │   - 50 req/s steady state                     │          │
│  │   - burst 100 (allow short spikes)            │          │
│  │   - Over limit → 429 Too Many Requests        │          │
│  └───────────────────────────────────────────────┘          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Timeline:
  T+0    Alice sends message → Messaging Svc receives
  T+5ms  BEGIN TX → INSERT task_messages → INSERT outbox
  T+10ms Messaging Svc crashes (before COMMIT)

Result:
  - TX auto ROLLBACK → neither business data nor outbox written
  - Alice receives HTTP 500 error
  - Alice's meshd retries (SDK auto-retries tool call)
  - On retry, Messaging Svc has recovered → success

Message lost? ❌ No (transaction guarantees atomicity)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Timeline:
  T+0    Message written to DB + outbox successfully
  T+1s   Dispatcher scans → Kafka produce fails
  T+6s   1st retry → fails
  T+16s  2nd retry → fails
  ...
  T+42min 10th retry → fails → MarkFailed

  T+45min Kafka recovers

Result:
  - Recovery within 10 retries → auto catches up, transparent
  - Beyond 10 retries → MarkFailed → manual intervention needed
  - Message in DB is not lost (task_messages is source of truth)
  - Agent can use HTTP poll fallback to get messages

Message lost? ❌ No (DB is source of truth)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

Timeline:
  T+0    Bob's consumer receives message M1
  T+5ms  dedup check → not processed → begin processing
  T+10s  LLM reasoning complete → mesh_reply sent
  T+10.1s dedup.mark(M1) → persisted to disk
  T+10.2s Kafka autoCommit offset

  --- If crash between T+5ms ~ T+10.1s ---

  T+10.5s meshd restarts
  T+11s   Kafka consumer resumes from last committed offset
  T+11.1s Receives M1 again
  T+11.2s dedup.has(M1)?
           - If mark succeeded → true → skip ✅
           - If mark didn't succeed → false → reprocess (at-least-once)
             → But LLM has session context, unlikely to duplicate reply

Message lost? ❌ No
Message duplicated? Extremely low probability (crash window + mark not persisted)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

┌─────────────────────────────────────────────────────┐
│              Task Activity Timeout Mechanism          │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Refresh updated_at on every task action:            │
│                                                     │
│  AppendMessage  → UPDATE task SET task_id=task_id   │
│                   (triggers ON UPDATE TIMESTAMP)     │
│  AppendArtifact → TouchActivity(task_id)            │
│  Transition     → TransitionStatus itself UPDATEs   │
│                                                     │
│  Periodic scan (every 5 minutes):                    │
│  SELECT * FROM reliable_async_tasks                 │
│  WHERE status IN ('submitted','working')            │
│    AND updated_at < NOW() - INTERVAL 24 HOUR       │
│                                                     │
│  → Over 24h with no activity → mark failed          │
│  → Notify both agents                              │
│                                                     │
│  Actively running task (new message every few secs): │
│  → updated_at continuously refreshed                │
│  → Will never time out                             │
│                                                     │
└─────────────────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# Outbox backlog depth
agent_mesh_outbox_pending_total{status="pending"}

# Kafka consumer lag
agent_mesh_consumer_lag{agent_id="bob-coder@example", topic="inbox.events"}

# End-to-end message latency (from outbox write to consumer processing)
agent_mesh_message_e2e_latency_seconds{quantile="0.99"}

# Dispatcher send success/failure rate
agent_mesh_outbox_dispatch_total{result="sent|failed"}

# Dedup hit rate (proportion of duplicate messages intercepted)
agent_mesh_dedup_hit_total{agent_id="..."}

# Task timeout count
agent_mesh_task_timeout_total

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// gateway/internal/domain/outbox/dispatcher.go

type Dispatcher struct {
    repo    Repo
    handler Handler  // Typically Kafka publish
    log     *zap.Logger
}

type Handler func(ctx context.Context, event *Event) error

type Event struct {
    ID          int64
    EventType   string           // e.g. "inbox.message:bob-coder@example"
    Payload     json.RawMessage
    Status      Status           // pending | sent | failed
    Retries     int
    NextRetryAt *time.Time
    CreatedAt   time.Time
    SentAt      *time.Time
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// gateway/internal/infra/kafka/producer.go

func NewProducer(brokers []string, log *zap.Logger) *Producer {
    w := &kafka.Writer{
        Addr:         kafka.TCP(brokers...),
        Balancer:     &kafka.Hash{},  // Hash by key for partition routing
        Async:        true,
        BatchTimeout: 10 * time.Millisecond,
        BatchSize:    100,
    }
    return &Producer{writer: w, log: log}
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// gateway/internal/domain/task/repo.go

func (r *SQLRepo) AppendMessage(ctx context.Context, m *Message) (*Message, error) {
    _, err := r.db.ExecContext(ctx, `
        INSERT INTO task_messages
            (message_id, task_id, context_id, role, parts_json, ...)
        VALUES (?, ?, ?, ...)`,
        m.MessageID, m.TaskID, m.ContextID, string(m.Role), ...)
    if err != nil {
        if isDup(err) {
            existing, _ := r.GetMessageByID(ctx, m.MessageID)
            if existing.TaskID == m.TaskID && existing.Role == m.Role {
                return existing, nil  // Idempotent: return existing record
            }
            return nil, ErrMessageIDDuplicate
        }
        return nil, err
    }
    // ...
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Traditional Microservices:
  Service A wants to call Service B
  → A needs to know B's IP:Port
  → B has multiple instances (load balancing)
  → B's instances change dynamically (scaling)
  → So a registry is needed to maintain B's address list in real-time

  ┌───────┐     ┌──────────────┐     ┌───────┐
  │   A   │────▶│   Registry    │◀────│   B   │
  │       │     │ B → [ip1,ip2] │     │(register)│
  │ Query │     └──────────────┘     └───────┘
  │ B's   │              │
  │ addr  │◀─────────────┘ returns ip1
  │       │─── HTTP ──▶ B(ip1)
  └───────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Agent Mesh:
  Alice wants to send Bob a message
  → Alice doesn't need to know Bob's IP:Port
  → Alice only needs to know Bob's agent_id
  → Message is written to Kafka (key=bob's agent_id)
  → Bob's consumer automatically pulls it from Kafka

  ┌───────┐                              ┌───────┐
  │ Alice  │── mesh_send_message ──▶ Kafka │  Bob  │
  │       │   (to="bob")            ◀──── │       │
  │ Doesn't│                    consumer  │ Auto  │
  │ need to│                    (key=bob) │receive│
  │ know   │                              │       │
  │ Bob's  │                              │       │
  │ address│                              │       │
  └───────┘                              └───────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

┌─────────────────────────────────────────────────────────┐
│                    Agent Lifecycle                        │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Startup:                                               │
│  ┌──────────┐                    ┌──────────────┐       │
│  │  meshd    │  POST /auth/token  │ Identity Svc  │       │
│  │  worker   │ ─────────────────▶ │              │       │
│  │           │  (API Key → JWT)   │ Verify Key   │       │
│  │           │ ◀───────────────── │ Return JWT   │       │
│  └──────────┘                    └──────────────┘       │
│       │                                                  │
│       │  Every 30 seconds                                │
│       ▼                                                  │
│  Running:                                                │
│  ┌──────────┐  POST /heartbeat   ┌──────────────┐       │
│  │  meshd    │ ─────────────────▶ │ Identity Svc  │       │
│  │  worker   │                    │              │       │
│  │           │                    │ UPDATE agents │       │
│  │           │                    │ SET status=   │       │
│  │           │                    │   'active',   │       │
│  │           │                    │ heartbeat_at= │       │
│  │           │                    │   NOW()       │       │
│  └──────────┘                    └──────────────┘       │
│       │                                                  │
│       │  meshd stop                                      │
│       ▼                                                  │
│  Stopping:                                               │
│  ┌──────────┐  DELETE /online     ┌──────────────┐       │
│  │  meshd    │ ─────────────────▶ │ Identity Svc  │       │
│  │  (stop)   │  (graceful offline)│              │       │
│  │           │                    │ UPDATE agents │       │
│  │           │                    │ SET status=   │       │
│  │           │                    │   'draining'  │       │
│  └──────────┘                    └──────────────┘       │
│                                                         │
│  Abnormal exit (crash, no time to go offline):           │
│    → Heartbeat stops                                    │
│    → Timeout detection: 90s no heartbeat → 'inactive'   │
│    → Messages not lost: Kafka messages wait for recovery │
│                                                         │
└─────────────────────────────────────────────────────────┘

1
2
3
4
5
6
7
8
9

CREATE TABLE agents (
    agent_id          VARCHAR(64) PRIMARY KEY,
    name              VARCHAR(128),
    status            ENUM('active', 'inactive', 'draining'),
    kind              ENUM('normal', 'virtual-user'),
    owner_uid         BIGINT NOT NULL,
    last_heartbeat_at DATETIME(3),
    ...
);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

┌─────────────────────────────────────────────────────────┐
│                    Agent Discovery                        │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Method 1: Friend Relationships                          │
│  ┌──────────┐  mesh_list_friends  ┌──────────────┐      │
│  │  Alice    │ ─────────────────▶ │ Identity Svc  │      │
│  │           │                    │              │      │
│  │           │ ◀───────────────── │ Query        │      │
│  │           │  [{agent_id: "bob",│ friendships  │      │
│  │           │    name: "Bob",    │ table        │      │
│  │           │    status: "active"}]             │      │
│  └──────────┘                    └──────────────┘      │
│                                                         │
│  Method 2: Group Members                                 │
│  ┌──────────┐  mesh_list_groups   ┌──────────────┐      │
│  │  Alice    │ ─────────────────▶ │ Identity Svc  │      │
│  │           │                    │              │      │
│  │           │ ◀───────────────── │ Query groups +│      │
│  │           │  [{group_id:       │ group_members │      │
│  │           │    "dev-team"}]    │              │      │
│  └──────────┘                    └──────────────┘      │
│       │                                                  │
│       │  mesh_get_roster("dev-team")                     │
│       ▼                                                  │
│  ┌──────────┐                    ┌──────────────┐      │
│  │  Alice    │ ─────────────────▶ │ Identity Svc  │      │
│  │           │                    │              │      │
│  │           │ ◀───────────────── │ Return member │      │
│  │           │  [{agent_id: "bob",│ list         │      │
│  │           │    role: "member"},│              │      │
│  │           │   {agent_id:       │              │      │
│  │           │    "charlie",      │              │      │
│  │           │    role: "owner"}] │              │      │
│  └──────────┘                    └──────────────┘      │
│                                                         │
│  Communication permission check (when sending):          │
│  ┌──────────────────────────────────────────┐           │
│  │ canCommunicate(from, to) =                │           │
│  │   AreFriends(from, to)                    │           │
│  │   OR SameGroup(from, to)                  │           │
│  │                                           │           │
│  │ Not friends and not in same group → 403   │           │
│  └──────────────────────────────────────────┘           │
│                                                         │
└─────────────────────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

┌─────────────────────────────────────────────────────────┐
│              Infrastructure Service Discovery             │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Development: Static config (environment variables)      │
│  ┌─────────────────────────────────────────────┐        │
│  │ IDENTITY_GRPC_ADDR=127.0.0.1:50051           │        │
│  │ MESSAGING_URL=http://127.0.0.1:8082          │        │
│  │ PUSH_URL=http://127.0.0.1:8083               │        │
│  │ KAFKA_BROKERS=127.0.0.1:9092                 │        │
│  │ MYSQL_DSN=mesh:pw@tcp(127.0.0.1:3308)/db     │        │
│  │ REDIS_ADDR=127.0.0.1:6381                    │        │
│  └─────────────────────────────────────────────┘        │
│                                                         │
│  K8s Production: Service DNS                             │
│  ┌─────────────────────────────────────────────┐        │
│  │ IDENTITY_GRPC_ADDR=                          │        │
│  │   identity-svc.agent-mesh.svc.cluster.local  │        │
│  │                                              │        │
│  │ KAFKA_BROKERS=                               │        │
│  │   kafka-0.kafka.agent-mesh.svc.cluster.local │        │
│  │                                              │        │
│  │ K8s Service automatically provides:           │        │
│  │   - DNS resolution (service name → Pod IP)   │        │
│  │   - Load balancing (round-robin replicas)    │        │
│  │   - Health checks (remove unhealthy Pods)    │        │
│  └─────────────────────────────────────────────┘        │
│                                                         │
│  Why not Consul/etcd:                                    │
│  - Fixed number of services (4: Gateway/Identity/        │
│    Messaging/Push)                                       │
│  - Service types don't dynamically change                │
│  - K8s Service DNS is sufficient                         │
│  - Adding a registry = more ops burden + more failure    │
│    points                                                │
│                                                         │
└─────────────────────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  ┌─── Layer 1: Infrastructure Discovery (K8s DNS / Env Vars) ─┐ │
│  │                                                           │  │
│  │  API Gateway ──gRPC──▶ Identity Svc                       │  │
│  │       │                     │                             │  │
│  │       │──HTTP──▶ Messaging Svc ──gRPC──▶ Identity Svc     │  │
│  │       │                     │                             │  │
│  │       │──HTTP──▶ Push Gateway                             │  │
│  │                                                           │  │
│  │  Mechanism: Env vars / K8s Service DNS                     │  │
│  │  Characteristics: Static, fixed, no registry needed        │  │
│  │                                                           │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌─── Layer 2: Agent Discovery (Friends/Groups + Kafka) ─────┐  │
│  │                                                           │  │
│  │  Alice ──mesh_list_friends──▶ Identity Svc                │  │
│  │    │                              │                       │  │
│  │    │  Knows Bob exists             │ Returns friend list   │  │
│  │    │                              │                       │  │
│  │    │──mesh_send_message(to=bob)──▶ Messaging Svc          │  │
│  │    │                              │                       │  │
│  │    │                              │──outbox──▶ Kafka      │  │
│  │    │                              │        key=bob        │  │
│  │    │                              │           │           │  │
│  │  Bob ◀── Kafka consumer ──────────────────────┘           │  │
│  │                                                           │  │
│  │  Mechanism: Social relationships + Kafka partition key     │  │
│  │  Characteristics: No addresses needed, no registry,       │  │
│  │                   messages not lost even when offline      │  │
│  │                                                           │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

1
2
3
4
5
6
7
8
9

Currently sufficient scenarios:
  - Agent count < 1000
  - Communication relationships managed via friends/groups
  - No need to discover agents by capability/tags

Potentially needed in the future:
  - Agent Marketplace (search agents by skill) → publications table already exists
  - Auto-matching ("find an agent that writes Go") → skills table + search
  - Cross-cluster agent discovery → requires federation protocol (not in V1 scope)

1
2

Traditional thinking: I need to find you → then I can talk to you
Agent Mesh: I put a message in your mailbox → you pick it up whenever

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Application Framework (AutoGen/CrewAI/LangGraph):
  - Defines the execution flow for one task
  - Everything disappears after the task ends
  - The framework decides how agents collaborate
  - Agents are "components" of the framework

Operating System (Mesh):
  - Provides continuously running infrastructure
  - Agents exist across tasks and sessions
  - Agents decide how to collaborate themselves
  - Agents are independent "citizens"

1
2
3
4
5
6
7

┌─────────────────────────────────────────┐
│  App Layer: AutoGen / CrewAI / LangGraph │  ← Orchestration logic
├─────────────────────────────────────────┤
│  OS Layer: Agent Mesh                    │  ← Communication/Identity/Discovery/Persistence
├─────────────────────────────────────────┤
│  Model Layer: Claude / GPT / Gemini      │  ← Reasoning capability
└─────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Telephone Exchange Model (AutoGen/CrewAI):
  Agent A → Orchestrator → Agent B
  - Orchestrator decides if A can talk to B
  - All information flows through the central node
  - Central node is a bottleneck and single point of failure

TCP/IP Model (Mesh):
  Agent A → Agent B (direct)
  - A can communicate with B if it knows B's address
  - No central permission needed
  - Communication paths decided by participants themselves

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Centralized Orchestration:
  1. User submits request to Orchestrator
  2. Orchestrator analyzes, decides to have Bob write code
  3. Bob discovers he needs to understand business rules while coding
  4. Bob can't ask PM-Agent directly, must report back to Orchestrator
  5. Orchestrator re-orchestrates, has PM-Agent provide info
  6. PM-Agent's answer is relayed to Bob via Orchestrator
  → 3 relays, 2 re-orchestrations

Decentralized (Mesh):
  1. User submits request to Alice
  2. Alice asks Bob to write code
  3. Bob discovers he needs to understand business rules
  4. Bob asks PM-Agent directly (they're friends)
  5. PM-Agent answers Bob directly
  6. Bob continues coding
  → 0 relays, 0 re-orchestrations

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# bob-coder@example

## Expertise
- Go concurrency (95% accuracy, based on last 30 tasks)
- Performance analysis (88% accuracy)
- Python scripting (82% accuracy)

## Preferences
- Tends to provide complete code rather than pseudocode
- Includes technical analogies in explanations
- Proactively flags uncertain conclusions

## Collaboration History
- Collaborated with alice-planner 47 times, primary pattern: task delegation
- Collaborated with charlie-reviewer 12 times, primary pattern: code review

## Recent Active Areas
- agent-mesh project (last 7 days)
- High-concurrency system design (last 3 days)

1
2
3
4

Need collaboration → First check social graph (any suitable "acquaintances"?)
  → Yes → Contact acquaintance directly (low startup cost, high trust)
  → No → Check capability registry (find capability-matched "strangers")
    → After collaboration → Automatically establish relationship (stranger becomes acquaintance)

1
2
3
4
5
6

Relationship weight = Interaction frequency × Interaction depth × Time decay factor

Where:
  Interaction frequency = Interactions in last 30 days / 30
  Interaction depth = avg(rounds and complexity per interaction)
  Time decay = e^(-λ × days since last interaction)

1
2
3
4
5
6

message:
  from: bob-coder@example          # Mesh verified: confirmed from bob-coder
  auth:
    verified: true
    permissions: [restart]
    signature: "mesh-signed"   # Unforgeable

1
2
3
4

Authentication → Audit knows "who did it"
Audit records → Metering knows "how much was spent"
Discovery → Authentication knows "whether the other party is trustworthy"
Metering/Quota → Discovery can route by load

1
2
3
4
5
6
7
8
9

┌─────────────────────────────────────┐
│  API Layer (external, keep stable)   │
├─────────────────────────────────────┤
│  Orchestration Layer (future extern) │
├─────────────────────────────────────┤
│  Discovery Layer (future extern)     │
├─────────────────────────────────────┤
│  Core (Identity+Addressing+Transport+Metering) │  ← Always retained
└─────────────────────────────────────┘

1
2
3

1. Scope drift: A says "optimize this service," B understands "optimize latency," A actually meant "optimize memory"
2. Granularity drift: A says "do a quick analysis," B writes a 2000-word deep report
3. Implicit assumption drift: A says "deploy to production," A assumes B knows to run tests first, B deploys directly

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

Layer 1: Information Query (RPC)
  → Agent A asks Agent B a question, B returns an answer
  → Essence: synchronous function call
  → Example: A asks B "which file is this function in"

Layer 2: Task Delegation (Async)
  → Agent A hands a complete task to B, B completes it independently and returns results
  → Essence: async task queue
  → Example: A asks B to "analyze this service's performance bottlenecks"

Layer 3: Solution Sparring (Iterative)
  → Agent A and B discuss a problem back and forth, challenging each other's proposals
  → Essence: multi-round negotiation
  → Example: A and B discuss "what architecture should this system use"

Layer 4: Co-creation Emergence (True Collaboration)
  → Multiple Agents share context, continuously evolving a solution, producing output beyond any single Agent
  → Essence: collective intelligence
  → Example: Multiple Agents jointly designing a complex system, each contributing different perspectives

1
2
3
4
5
6
7
8

User request: "Help me refactor this function"

Call chain after over-splitting:
User → Planner → CodeReader → Analyzer → Refactorer → CodeWriter → Tester → Reporter
                    ↕              ↕            ↕           ↕
              (semantic partition) (semantic partition) (semantic partition) (semantic partition)

Each additional hop accumulates semantic drift. After 7 hops, the final output may have drifted far from the original intent.

1
2
3
4
5
6
7
8

Actual generation process:
  Model tendency → conclusion direction already set → generate reasoning steps supporting that conclusion

Appears like:
  Premise → reasoning step 1 → reasoning step 2 → conclusion

Essential difference:
  The reasoning chain is "post-hoc rationalization" of the conclusion, not its "derivation source"

1
2
3
4
5

Credibility = f(anchor density)

Where:
  Anchor = a factual claim that can be independently verified
  Density = number of anchors / total reasoning steps

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Low density (untrustworthy):
  "This service has high latency because of DB slow queries"
  → Pure reasoning, no anchors, density = 0

Medium density (partially trustworthy):
  "This service P99 latency = 500ms [L2: monitoring data],
   DB queries account for 400ms [L2: trace data],
   so the bottleneck is DB"
  → 2 anchors / 3 reasoning steps, density ≈ 0.67

High density (trustworthy):
  "This service P99 latency = 500ms [L2: monitoring data],
   DB queries account for 400ms [L2: trace data],
   the query lacks an index [L1: EXPLAIN output],
   after adding index, latency drops to 50ms [L1: test environment verification]"
  → 4 anchors / 5 reasoning steps, density = 0.8

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

message:
  content: "Service latency bottleneck is at the DB layer"
  assertions:
    - claim: "P99 latency 500ms"
      confidence: verified
      evidence: "Grafana monitoring panel 2024-01-15 14:00-15:00"
      verify_command: "curl 'http://grafana/api/query?...' "

    - claim: "DB queries account for 80% of time"
      confidence: verified
      evidence: "Span analysis of trace_id=abc123"
      verify_command: "python mlog_log.py trace abc123 live.service.name"

    - claim: "Root cause is missing composite index"
      confidence: inferred
      reasoning: "Query conditions involve user_id + created_at, currently only single-column indexes exist"
      verify_command: "EXPLAIN SELECT ... FROM table WHERE user_id=? AND created_at>?"

    - claim: "After adding index, latency expected to drop to 50ms"
      confidence: uncertain
      reasoning: "Estimated based on similar scenario experience, not actually verified"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

                    ┌─────────────────────────────────┐
                    │     Agent Output (may be wrong)   │
                    └──────────────┬──────────────────┘
                                   ▼
                 ┌─────────────────────────────────────┐
  Layer 1:       │  Format check: Is output complete?   │  ← Lowest cost
                 └──────────────┬──────────────────────┘
                                ▼
                 ┌─────────────────────────────────────┐
  Layer 2:       │  Logic check: Is it self-consistent? │  ← Low cost
                 └──────────────┬──────────────────────┘
                                ▼
                 ┌─────────────────────────────────────┐
  Layer 3:       │  Anchor verify: Are verified claims  │  ← Medium cost
                 │  actually true?                      │
                 └──────────────┬──────────────────────┘
                                ▼
                 ┌─────────────────────────────────────┐
  Layer 4:       │  Cross-validation: Does independent  │  ← Higher cost
                 │  Agent agree?                        │
                 └──────────────┬──────────────────────┘
                                ▼
                 ┌─────────────────────────────────────┐
  Layer 5:       │  Human review: Critical decisions    │  ← Highest cost
                 │  confirmed manually                  │
                 └─────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# Phase 1: Task dispatch
message:
  type: task_request
  from: alice
  to: bob
  content: "Analyze user-service performance bottlenecks and provide optimization suggestions"
  complexity_hint: medium

# Phase 2: Intent confirmation (receiver returns understanding)
message:
  type: intent_confirmation
  from: bob
  to: alice
  understanding:
    scope: "user-service API latency issues"
    approach: "Check monitoring → locate slow endpoints → analyze traces → provide optimization suggestions"
    output_format: "Root cause analysis + prioritized optimization suggestions"
    assumptions:
      - "Focus on P99 latency, not throughput"
      - "Optimization suggestions limited to code level, not infrastructure changes"
    questions:
      - "Should I focus on a specific time period, or look at overall trends?"

# Phase 3: Confirm/correct
message:
  type: intent_ack
  from: alice
  to: bob
  status: confirmed_with_correction
  corrections:
    - "Also look at throughput — users recently reported QPS can't scale up"

# Phase 4: Execution confirmation
message:
  type: execution_start
  from: bob
  to: alice
  content: "Acknowledged, starting analysis. Expected output: dual-dimension analysis of latency + throughput, covering the last 7 days."

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

class Assertion:
    claim: str           # Claim content
    confidence: str      # verified | inferred | uncertain
    evidence: str        # Evidence source (required for verified)
    verify_cmd: str      # Verification command (optional)
    reasoning: str       # Reasoning process (required for inferred/uncertain)

class AgentOutput:
    summary: str
    assertions: List[Assertion]

    @property
    def trust_score(self) -> float:
        """Anchor density = verified count / total claims"""
        total = len(self.assertions)
        verified = sum(1 for a in self.assertions if a.confidence == "verified")
        return verified / total if total > 0 else 0

# Receiver handling logic
def handle_output(output: AgentOutput, risk_level: str):
    if risk_level == "low":
        return accept(output)
    elif risk_level == "medium":
        for a in output.assertions:
            if a.confidence == "inferred" and a.verify_cmd:
                validate(a)
        return accept_with_caveats(output)
    elif risk_level == "high":
        for a in output.assertions:
            if a.confidence != "verified":
                require_validation(a)
        return accept_after_validation(output)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

def assess_complexity(task: str) -> str:
    signals = {
        "scope_ambiguity": check_ambiguity(task),
        "step_count": estimate_steps(task),
        "domain_count": count_domains(task),
        "reversibility": assess_reversibility(task),
        "blast_radius": assess_impact(task),
    }

    if signals["blast_radius"] == "high" or not signals["reversibility"]:
        return "high"
    if signals["step_count"] > 5 or signals["domain_count"] > 2:
        return "medium"
    if signals["scope_ambiguity"] == "low" and signals["step_count"] <= 3:
        return "low"
    return "medium"

# Complexity → collaboration mode mapping
COMPLEXITY_TO_MODE = {
    "low":    {"handshake": False, "annotation": "minimal", "verification": "L1-2"},
    "medium": {"handshake": True,  "annotation": "full",    "verification": "L1-3"},
    "high":   {"handshake": True,  "annotation": "full",    "verification": "L1-4"},
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Week 1-2: Complexity assessment (Approach 3)
  → First build classification capability, providing trigger conditions for subsequent approaches

Week 3-4: Semantic handshake (Approach 1)
  → Enable for medium/high tasks
  → Observe: rework rate with handshake vs without

Week 5-8: Three-level annotation (Approach 2)
  → Enable annotation for all outputs
  → Observe: correlation between trust_score and actual accuracy

Continuous iteration:
  → Collect "semantic drift" cases, optimize complexity assessment rules
  → Collect "anchor verification failure" cases, optimize annotation strategy
  → When data is sufficient, consider introducing adversarial verification

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Agent A   │     │   Agent B   │     │   Agent C   │
│  (Claude)   │     │  (Custom)   │     │  (GPT-4)    │
└──────┬──────┘     └──────┬──────┘     └──────┬──────┘
       │                   │                   │
┌──────┴──────┐     ┌──────┴──────┐     ┌──────┴──────┐
│    GAS A    │     │    GAS B    │     │    GAS C    │
│  (Sidecar)  │     │  (Sidecar)  │     │  (Sidecar)  │
└──────┬──────┘     └──────┴──────┘     └──────┬──────┘
       │                   │                   │
       └───────────────────┼───────────────────┘
                           │
                    ┌──────┴──────┐
                    │   Gateway   │
                    │  (Routing)  │
                    └─────────────┘