Local AI Infrastructure Notes (4/15) — Building an Inter-Agent Message Hub

A dual-path agent communication architecture separating fire-and-forget webhooks from ACK-based task messages

Summary

  • Multiple agents require a communication structure — without one, each agent becomes a silo
  • Insight delivery (fire-and-forget) and task requests (ACK-required) demand distinct design patterns
  • Separating the webhook path from the message path enables simultaneous handling of simple notifications and trackable work items

Background

When there is only one agent, communication is unnecessary. The agent executes a task and returns a result to the user.

The problem begins with multiple agents. When an insight discovered by a stock analysis agent must be written up by a content agent. When an investment strategy from a life-organization agent should influence the portfolio direction of a stock agent. If those connections can only be made through a human intermediary, the human becomes a bottleneck.

A hub where agents can exchange messages directly is required. However, not all messages are equivalent. Passing along a "for your reference" insight and issuing a "please do this task and confirm when done" request require different mechanisms.

Body

1. Why Two Communication Paths

Routing all communication through a single API leads rapidly to complexity explosion. Simple insight delivery would still require waiting for an ACK, and critical task requests would be buried under notification traffic.

The solution is path separation:

Path Purpose Pattern Tracking
Webhooks Insight / notification delivery fire-and-forget None
Agent Messages Task requests / responses ACK required Full

Webhooks (fire-and-forget): The sender emits "here is what I found" and moves on. Whether the receiver reads it is irrelevant to the sender. Insights, monitoring data, and status updates travel this path.

Agent Messages (ACK-based): The sender emits "please do this task" and waits for the receiver to return an acknowledgement (ACK). Task requests, post-transfer processing confirmations, and collaborative inter-agent work travel this path.

2. Webhook Path — Lightweight, Fast Delivery

The webhook API pattern is minimal:

POST /api/webhooks
{
  "content": "content to deliver",
  "tags": ["tag1", "tag2"],
  "source": "sending-agent"
}

No response is awaited. HTTP 200 means delivery is complete. When the receiver reads it and how it processes the content are outside the sender's concern.

Use cases for this path: - A research agent records discovered data to the hub - A monitoring agent reports service health - An agent shares a detected pattern for other agents to reference

Overhead is negligible, allowing agents to share insights freely. Information that might only prove useful later can be emitted without hesitation.

3. Agent Message Path — Communication Requiring Tracking and Confirmation

Task-request messages require a higher level of reliability.

POST /api/agent-messages
{
  "fromAgent": "sending agent",
  "toAgent": "receiving agent",
  "messageType": "task_request",
  "intent": "description of task intent",
  "body": {
    "text": "specific request content"
  },
  "dedupeKey": "unique-key"
}

Core mechanisms of this path:

Inbox pattern: Each agent maintains its own inbox.

GET /api/agent-inbox/{agentName}

When an agent activates, it checks its inbox and processes any pending messages.

ACK (acknowledgement): On receiving a message, the agent must return an ACK.

POST /api/agent-messages/{messageId}/ack
{
  "status": "acked",
  "response": { ... }
}

If no ACK arrives, the message was not processed. This enables retry logic and timeout handling.

Deduplication: dedupeKey prevents the same message from being processed more than once. If a message is retransmitted due to a network issue, any message sharing the same key is processed exactly once.

4. Agent Naming Convention

Agent names require a consistent convention. While the API auto-normalizes names, the canonical form uses Korean names with spaces.

  • Correct: "๊ธ€ ์ž‘์„ฑ ๋””๋ ‰ํ„ฐ", "์ฃผ์‹ ์ •๋ณด ๊ด€๋ฆฌ ๋””๋ ‰ํ„ฐ"
  • Avoid: "๊ธ€-์ž‘์„ฑ-๋””๋ ‰ํ„ฐ", "write_score_agent"

The reason is straightforward. The name a user uses to refer to an agent must match the system's internal identifier. Using hyphens or underscores for technical convenience generates recurring "which name is correct?" confusion.

5. Real-World Case: Passing Blog Material Between Agents

Here is one flow where this architecture operates:

  1. The life-organization agent reviews a user's experience or decision and determines "this could become blog material"
  2. It delivers an insight via webhook: POST /api/webhooks — tags include "blog-material"
  3. The content agent checks the hub for relevant insights at session start
  4. If the material is deemed viable, the agent initiates its pipeline via the message path: research → source file compilation → verification → blog draft
  5. Once the blog draft is complete, the agent sends a confirmation request to the user

The key point: steps 1–2 use webhooks (fire-and-forget); the remainder is the content agent's autonomous pipeline. Insight delivery stays lightweight; actual work execution is autonomous within each agent.

If the life-organization agent needs to directly instruct the content agent to "write a post on this topic," it uses the message path (POST /api/agent-messages). The content agent returns the result via ACK upon completion.

Design Pitfalls and Response Patterns

Single-path design problem: Routing all communication through one API forces even insight notifications to require ACK, increasing processing load on every agent. Critical task requests get buried in notification traffic — a priority inversion. Separating paths means each communication type carries only the overhead it actually needs.

Name mismatch problem: Using different agent names internally and externally causes inbox lookup failures. Apply normalization at the API level, but keep the user-visible name and internal identifier identical as a hard rule.

Missing dedupeKey risk: When a message is retransmitted due to network timeout, the absence of dedupeKey results in duplicate task execution. Including a deterministic unique key in every task-request message is mandatory. Key generation strategy: the pattern {fromAgent}:{toAgent}:{intent}:{timestamp} minimizes collision probability.

Conclusion

With one agent, no communication structure is needed. With two, it becomes "nice to have." With three or more, it is non-negotiable.

The core design principle is simple: lightweight delivery via webhooks, trackable work via messages. That single distinction brings communication complexity down to a manageable level.

In inter-agent communication, the hard part is not technical implementation. The design challenge is judging "what level of reliability does each type of communication require?" The message hub's role is to encode that judgment as structure.

Series overview: Series index

๋Œ“๊ธ€

๋Œ“๊ธ€ ์“ฐ๊ธฐ

์ด ๋ธ”๋กœ๊ทธ์˜ ์ธ๊ธฐ ๊ฒŒ์‹œ๋ฌผ

Agent Memory Engine (2/10) — Building an AI Agent Memory System with SQLite Alone

← 1/10 SQLite Memory Engine f… ๐Ÿ“š Series Index 3/10 memcore Completed → A memory engine that runs without daemons, without dependencies, anywhere ํ•ต์‹ฌ ์š”์•ฝ This post covers how to design an AI agent memory engine (memcore) on a single-file SQLite backend. - Structure: 25 modules, ~6,464 lines, 22 DB tables - Principles: no daemon, single-file portability, no required external dependencies, host-agnostic - Core techniques: 4-layer hybrid search (topic · vector · FTS5 · LIKE), U-tag dialectic-based confidence evolution, ingestion-layer bias rejection rules What This Post Covers One approach to building AI agent memory without a server or cloud vector DB. Specifically: (1) the limitations of text-file-based memory, (2) vector DB alternatives compared and selection criteria, (3) how to layer search tiers, (4) how to evolve confidence scores over time, and (5) how to block biased memory accumulation at the ingestion stage. Design Principles: Why Single-File SQLite Text-file-based ...
Read more »

"ML Foundations (9/9) — PyTorch vs TensorFlow, and the Road to Local LLMs"

์ด๋ฏธ์ง€
← 8/9 Deep Learning Architec… ๐Ÿ“š Series Index (series end) The final part. So far we've focused on models. Now we focus on the tools that actually run them . We'll lay out the philosophical difference between PyTorch and TensorFlow, and trace how Hugging Face transformers , llama.cpp , MLX , and Ollama built the bridge to running large language models on your own machine. By the end you should have the full mental model of "download a pretrained LLM and serve it locally." 0. Learning Objectives Explain the eager-vs-graph difference between PyTorch and TensorFlow. Explain, in graph terms, how autograd automates the backward pass. Use Hugging Face transformers ' AutoModel , AutoTokenizer , and pipeline abstractions. Describe llama.cpp's GGUF quantization, INT4 inference, and CPU-first flow. Describe Apple MLX's use of unified memory and how it differs from PyTorch. Run a local LLM with Ollama and call it through an OpenAI-compatible API. ...
Read more »

"RAG Core Study (14/26) — Evaluation Sets with RAGAS & DeepEval"

์ด๋ฏธ์ง€
Series overview: Series index ๐Ÿ“š Series Index Without an evaluation set, every RAG improvement is a story, not evidence. RAG systems fail in more than one place: retrieval, context selection, answer generation, and grounding. That means "looks better" is not a metric. Part 14 explains how to build a golden dataset , how RAGAS and DeepEval fit into the workflow, and why teams must separate retrieval quality from answer quality if they want tuning decisions to hold up. 0. Prerequisites Part 13 reranking — system quality now depends on multi-stage ranking. Part 1 grounding — a correct-looking answer is not enough. Part 12 Hybrid — multiple retrieval settings need comparison on fixed data. 1. Learning Objectives Build a small but useful golden dataset for RAG. Distinguish retrieval metrics from answer metrics . Use RAGAS and DeepEval in the right roles. Avoid the common traps in judge-model-based evaluation. 2. ํ•ต์‹ฌ ์š”์•ฝ An evaluation set for RAG is ...
Read more »

"ML Foundations (8/9) — Deep Learning Architectures: CNN, RNN, Attention"

์ด๋ฏธ์ง€
← 7/9 Deep Learning Training ๐Ÿ“š Series Index 9/9 PyTorch vs TensorFlow → What did we keep adding on top of an MLP? Vision went CNN, sequences went RNN/LSTM, and eventually both converged on Attention and the Transformer. Each architecture is easier to remember if you read it as what it gave up to gain something else . This part is the one-line summary of the decisive inflection points: LeNet → AlexNet → ResNet → LSTM → Attention → Transformer. 0. Learning Objectives Explain why CNN's convolution, pooling, and weight sharing match images so well. Trace what got unblocked from LeNet → AlexNet → VGG → ResNet as depth grew. State BPTT for RNNs and the vanishing/exploding gradient problem. Write the LSTM gate equations (forget, input, output) with intuition. Write the attention formula in query/key/value form and the scaled dot-product variant. State the precise reasons Transformers replaced RNNs (parallelism + long-range dependencies). 1. ํ•ต์‹ฌ ์š”์•ฝ CNN : weight sharin...
Read more »

"ML Foundations (7/9) — Deep Learning Training: Optimizers, Regularization, Initialization"

← 6/9 Neural Networks ๐Ÿ“š Series Index 8/9 Deep Learning Architec… → Building an MLP, as we did in Part 6, is not the same as getting it to train well . The right optimizer, regularization, initialization, and learning rate — when these line up, deep networks converge. When they don't, the network refuses to learn at all. This part is the catalog of those crafts, with formulas, paper citations, and code in one place. 0. Learning Objectives Compare and write the update rules for SGD, Momentum, Nesterov, and Adam. Explain how Dropout, BatchNorm, and LayerNorm work and where they belong in a model. Derive the variance formulas for Xavier and He initialization and match them to activations. Implement step, cosine, and warmup learning-rate schedules in PyTorch. Explain why gradient clipping is effectively required for RNNs and Transformers. Diagnose the most common training failures (NaN, plateau, overfitting) and apply first-line fixes. 1. ํ•ต์‹ฌ ์š”์•ฝ SGD : \(w \leftarro...
Read more »

OpenClaw to Hermes Migration (2/13) — What to Preserve, Partially Port, or Discard

← 1/13 Current Structure Inve… ๐Ÿ“š Series Index 3/13 What Moves to Hermes → A code review record classifying operational scripts into three tiers: preserve, partial-preserve, and discard. What This Post Covers An asset classification framework (preserve / partial-preserve / discard) for migrating a legacy agent system to a successor A concrete case applying the Strangler Fig + Subset Migration strategy to a memory pipeline Classification results evaluated across LOC, external dependencies, and replaceability axes A method for slimming down a bloated single file (1,310 LOC) using the migration as a natural entry point Problem Definition: Port Everything or Cut Deep? The OpenClaw inventory comprises multiple agents, multiple scheduler/daemon processes, and multiple operational scripts. When moving to the successor system, Hermes, the choice is not binary. A full port carries accumulated technical debt along with it; a minimal port discards hard-won domain logic. Code-revie...
Read more »

AI Agents I Built (5/7) — Building an Automated Blogger API Publishing System

← 4/7 My Life Organizer Agent ๐Ÿ“š Series Index 6/7 Dual → Designing a Markdown-Based Auto-Publish Pipeline with Blogger API v3 + OAuth 2.0 Key Summary Blogger API v3 + OAuth 2.0 enables a pipeline that converts Markdown files into publishable HTML posts blogger_publish.py handles the full flow — frontmatter parsing → body cleanup → HTML conversion → CSS injection → API post — in a single script For bulk publishing, quota management (delay, retry, TOC suppression) is the critical design concern Platform Selection Criteria API access is mandatory for AI agent-driven content publishing. A comparison of platforms: Platform API Cost AdSense Decision WordPress.com REST API Paid plan required Paid only Cost overhead Ghost REST API Self-hosted or paid Manual setup Ops overhead Blogger v3 API Free Native integration Adopted Blogger is free, exposes a REST API, and integrates natively with AdSense. For personal blog automation, this combination i...
Read more »