80 lines
2.3 KiB
Markdown
80 lines
2.3 KiB
Markdown
# 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...*
|