AI Agents I Built (7/7) — Inter-Agent Content Relationships: How Data Flows
A structure where agents hand off work to each other without human relay
Key Summary
- Inter-agent content flow is modeled across three primary paths: life records → writing, investment analysis → writing, infrastructure events → writing
- Reverse flow is also designed — research output cycles back as reference data for decision-making agents
- Declaring
[content]relationship tags explicitly in the ontology schema allows agents to resolve content source origins structurally
Background
Running a multi-agent system surfaces a recurring design problem: "Agent A produces output that Agent B must consume — how do you wire that connection?"
Each agent operating independently is a given. The problem is inter-agent data delivery. If a human manually relays every handoff, the system does not scale. As the number of agents grows, the number of connections to manage grows quadratically.
This problem is most visible in the content domain. Where does blog material come from? Investment analysis insights, life decision records, events from server operations — all originate in different agent domains. Without a designed path for this data to reach the writing agent, human intervention is required at the content sourcing stage.
Body
1. Content Relationship Modeling: Three Primary Flows
Inter-agent content flow is modeled by three components: source agent, destination agent, and the type of data being transferred.
Flow 1: Life Organizer → Writing Director [content]
This is the path by which generalizable insights from life-record agent output are delivered as content material.
The Life Organizer agent records decision-making processes, value conflicts, and confirmation-bias-blocking outcomes as structured data. Items within those records that are classified as "patterns applicable across other contexts" are forwarded to the Writing Director.
Data examples:
- insight_type: value_conflict — patterns of mismatch between declared values and enacted values → source material for a personal ontology series
- insight_type: bias_block — real-world records of the confirmation-bias blocking mechanism firing → source material for AI practical engineering posts
- insight_type: decision_support — cases where an agent's counter-argument influenced a decision → source material for "AI as a tool" content
Flow 2: Stock Information Director → Writing Director [content]
This is the path by which insights from the quant analysis agent are delivered as content material.
The Stock Director performs signal analysis, portfolio scoring, and market trend analysis. What gets forwarded as content is not stock recommendation data — it is analysis methodology and system design experience.
Transfer data structure:
{
"type": "content_source",
"category": "methodology", // not a stock recommendation
"topic": "signal_analysis_pattern",
"context": "design experience including trial and error"
}
This distinction matters. Without an explicit definition of which data the system classifies as content material, data that must not be published can enter the pipeline.
Flow 3: Home Server Manager → Writing Director [content]
This is the path by which infrastructure operation events are delivered as content material.
The Home Server Manager is the agent hub and infrastructure monitoring agent. When events such as server downtime, network issues, or monitoring alerts occur, the corresponding response process is automatically tagged as a content candidate.
Event → content conversion patterns: - Server failure → root cause analysis + recovery process + automation improvements → infrastructure operations post - Ontology structuring process → design decision records → system design series
2. Reverse Flow — Research Data Cycles Back into Decision-Making
The content relationship model is not unidirectional.
Writing Director → Life Organizer [data]
Research data collected during content creation flows back as reference material for the decision-making agent.
Example: during AI agent trend research, data on "scalability limits of multi-agent systems" serves as blog material but simultaneously constitutes domain knowledge that influences agent system design decisions. Forwarding this data back to the Life Organizer makes it available in the next decision-making cycle.
Cycle structure:
Experience record → Content material → Research → Domain knowledge → Better decisions → New experience record
When this cycle runs, the two agents reinforce each other. The output of one agent raises the input quality of the other.
3. The Actual Delivery Mechanism via the Message Hub
Once content relationships are defined in the ontology, the message hub handles actual delivery.
Content material delivery sequence:
1. Source agent — detects emergence of a shareable insight
2. Message hub → Writing Director: task_request {type: "content_source", payload: {...}}
3. Writing Director → Message hub: ACK {status: "received", queue_position: N}
4. Writing Director internally: research → compile → verify → draft → publish pipeline executes
Step 2 is the critical point. Rather than a human remembering "I should write a blog post from this analysis" and manually passing it along, the agent references the [content] relationship in the ontology and delivers it directly.
Automation boundaries are defined explicitly: - Automated: material delivery, research, draft writing - Not automated: publish decision, tone/perspective judgment — final confirmation is made by a human
4. Why [content] Relationships Are Declared Explicitly in the Ontology Schema
The ontology that defines inter-agent relationships uses relationship type tags.
| Tag | Meaning |
|---|---|
[infra] |
Infrastructure dependency — one agent provides the execution environment for another |
[tech] |
Technical dependency — code, patterns, or stack is shared |
[data] |
Data flow — structured data is transferred |
[content] |
Content material flow — output from one agent becomes content source material for another |
There are two reasons for defining the [content] tag separately.
From the agent's perspective: the Writing Director queries the list of agents connected to it via [content] to identify content sources. When a new agent is added or an existing agent changes, the system can immediately determine whether the [content] relationship is affected.
From the system's perspective: failing to declare [content] relationships explicitly makes them implicit dependencies — equivalent to uncommented global variables in code. The system functions, but the origin of values is untraceable. As the number of agents grows, these implicit relationships become a primary driver of system complexity.
Ontology definition example:
Life Organizer → Writing Director [content]
// life decision/experience insights → blog/twitter material
Writing Director → Life Organizer [data]
// research output → decision-making reference data
Lessons Learned
Initially, material delivery was handled manually. When analysis output was produced, it was copied and pasted directly into writing tasks. This works with a small number of agents. As the agent count grows, the human becomes the bottleneck — the number of relationships scales as the square of the agent count.
There was a period when automation scope was set incorrectly. Automation was attempted not just for material delivery, but for writing and publishing as well. The result was degraded content quality. Material delivery can be automated; perspective and tone in content require human judgment. Setting the automation boundary at the data transfer stage was the correct call.
In the early period before relationship type tags were classified, there was ambiguity. It was unclear which agents were in a content-material relationship, a technical dependency relationship, or an infrastructure relationship. Only after classifying [content], [tech], [data], and [infra] tags and declaring them in the ontology did the nature of each relationship become traceable.
Conclusion
In a multi-agent system, the hard problem is not implementing individual agents. It is routing data between agents along the correct paths.
Content relationship modeling rests on two principles. First, relationship types are explicitly tagged in the ontology ([content], [data], [tech], [infra]). Second, actual delivery is delegated to the message hub.
With this structure in place, inter-agent data flow becomes traceable, and the impact of adding new agents or modifying existing ones on the content pipeline can be assessed in advance. Humans focus solely on final judgment; the system handles material discovery and delivery.
Series overview: Series index
๋๊ธ
๋๊ธ ์ฐ๊ธฐ