Knowledge Center Architecture: 20+ Departments. Standalone "Connected" Agents vs. Child "Inline" Agents?
I’m trying to build a large-scale Knowledge Center and looking for community feedback on the best path forward.
The Setup:
• Document Storage: SharePoint (Document libraries per department).
• Requirement: Users must be able to scope their query to a specific folder or file at runtime (dynamic grounding).
• Scale: 20+ distinct departments.
The Core Question:
How should I structure the relationship between the main routing agent and the departments? I’m torn between two designs:
Option 1: Inline (Child) Agents
• The Idea: Keep everything inside one Parent Agent, using the "Inline Agent" feature to group instructions and knowledge.
• The Bottleneck: Dev workflow. Can multiple developers actually work on different inline agents simultaneously without locking the canvas? Also, does the entire solution become a "monolith" that requires a full republish for every minor department update?
Option 2: Standalone (Connected) Agents
• The Idea: Each department is its own independently published agent, called by the Parent via the Agent-to-Agent (A2A) protocol.
• The Bottleneck: Complexity and latency. Will the hand-off feel slow? More importantly, can a Parent Agent still effectively synthesize a single answer using data pulled from multiple "Connected" agents?
Other Ideas I'm Considering:
• Knowledge vs. Topics: Should departments just be "Knowledge Sources" or "Topics"? I don’t want to make the orchestration deterministic by using topics. Just setting them as knowledge source would not get right responses during cross department synthesis
• Dynamic Scoping: What is the most reliable way to force the agent to ground only in a specific SharePoint folder path passed at runtime? I have seen dynamic variables but what if I have many subfolders and it needs grounding in multiple subfolders.
Looking for ideas from anyone who has experience or any suggestions with this.