vault backup: 2026-02-25 16:59:33
This commit is contained in:
79
WORK/Projects/Agent Orchestrator.md
Normal file
79
WORK/Projects/Agent Orchestrator.md
Normal file
@@ -0,0 +1,79 @@
|
|||||||
|
# Agent Orchestrator
|
||||||
|
|
||||||
|
*Origin: Frontend design skill test evolved into a real work project idea*
|
||||||
|
|
||||||
|
## Problem Statement
|
||||||
|
|
||||||
|
We have multiple AI agents at work but no unified interface:
|
||||||
|
- Natural language SQL search agents
|
||||||
|
- Company knowledge base agents
|
||||||
|
- [Likely others...]
|
||||||
|
|
||||||
|
Users currently bounce between different interfaces or don't know which agent to use for their query.
|
||||||
|
|
||||||
|
## Solution Concept
|
||||||
|
|
||||||
|
A single **Orchestrator** interface that:
|
||||||
|
- Provides one entry point for all agent queries
|
||||||
|
- Intelligently routes requests to the appropriate specialized agent
|
||||||
|
- Shows visual feedback of the routing decision
|
||||||
|
- Maintains conversation context across agent handoffs
|
||||||
|
- Allows manual agent override when needed
|
||||||
|
|
||||||
|
## Visual Direction
|
||||||
|
|
||||||
|
From the initial frontend test:
|
||||||
|
- Dark corporate aesthetic with warm gold accents
|
||||||
|
- Editorial typography (Crimson Pro + Plus Jakarta Sans)
|
||||||
|
- **Key feature**: Visual orchestration flow showing the handoff in real-time
|
||||||
|
- Sidebar with specialized agents (color-coded by function)
|
||||||
|
- Auto-resizing input with agent selector
|
||||||
|
|
||||||
|
## Current Agent Inventory
|
||||||
|
|
||||||
|
| Agent | Function | Status |
|
||||||
|
|-------|----------|--------|
|
||||||
|
| SQL Search | Natural language to SQL queries | Active |
|
||||||
|
| Knowledge Base | Company docs/knowledge search | Active |
|
||||||
|
| [Others?] | | |
|
||||||
|
|
||||||
|
## Architecture Thoughts
|
||||||
|
|
||||||
|
### Intent Classification
|
||||||
|
- Route to "sql" when query involves data/tables/metrics
|
||||||
|
- Route to "knowledge" when query asks about policies/procedures
|
||||||
|
- Fallback to general or multi-agent mode
|
||||||
|
|
||||||
|
### Context Persistence
|
||||||
|
- Conversation thread maintained across agent handoffs
|
||||||
|
- Results from one agent can inform another
|
||||||
|
- Shared memory for the full session
|
||||||
|
|
||||||
|
### Agent Registry
|
||||||
|
- Dynamic discovery of available agents
|
||||||
|
- Each agent defines its capabilities and routing triggers
|
||||||
|
- Easy to add new agents
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
- [ ] What agents exist beyond SQL and knowledge?
|
||||||
|
- [ ] How do agents currently expose their APIs?
|
||||||
|
- [ ] Authentication/authorization model?
|
||||||
|
- [ ] Self-hosted vs SaaS deployment?
|
||||||
|
- [ ] Existing tech stack constraints?
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
1. Inventory all existing agents and their interfaces
|
||||||
|
2. Define the orchestrator API contract
|
||||||
|
3. Determine routing logic (LLM-based vs rules-based)
|
||||||
|
4. Build POC with 2-3 agents
|
||||||
|
5. Design system architecture diagram
|
||||||
|
|
||||||
|
## Related Files
|
||||||
|
|
||||||
|
- Initial UI prototype: `frontend/subagent-orchestrator-chat/index.html`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Elaborate further here...*
|
||||||
Reference in New Issue
Block a user