AudioForge / AGENT_ARCHITECTURE.md
OnyxlMunkey's picture
c618549
# AudioForge Agent Architecture
## Problem Statement
Python 3.13 compatibility issues with ML libraries (PyTorch, AudioCraft, xformers) that only support Python 3.11/3.12.
## Solution: Microservices Agent Architecture
Instead of monolithic deployment, separate concerns into independent agents.
## Architecture Overview
```
┌─────────────────────────────────────────────────────────────┐
│ Client (Browser) │
└─────────────────────┬───────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Frontend (Next.js - Port 3000) │
└─────────────────────┬───────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Main API Service (FastAPI - Python 3.13) │
│ - User management, authentication │
│ - Database operations (PostgreSQL) │
│ - Job orchestration │
│ - WebSocket for real-time updates │
│ Port: 8001 │
└─────────────────────┬───────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Message Queue (Redis/Celery) │
│ - Task distribution │
│ - Job status tracking │
│ - Result aggregation │
└─────────────────────┬───────────────────────────────────────┘
┌─────────────┼─────────────┬─────────────┐
▼ ▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Music Agent │ │ Vocal Agent │ │ Mixing Agent │ │ Master Agent │
│ Python 3.11 │ │ Python 3.11 │ │ Python 3.11 │ │ Python 3.11 │
│ Port: 8002 │ │ Port: 8003 │ │ Port: 8004 │ │ Port: 8005 │
│ │ │ │ │ │ │ │
│ - MusicGen │ │ - Bark │ │ - Demucs │ │ - Mastering │
│ - AudioCraft │ │ - RVC │ │ - Mixing │ │ - Effects │
│ - Encodec │ │ - TTS │ │ - Stems │ │ - Normalize │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
```
## Benefits
### 1. **Dependency Isolation**
- Each agent has its own Python version
- No version conflicts between packages
- Easy to update individual components
### 2. **Scalability**
- Scale agents independently based on load
- Music generation heavy? Spin up more music agents
- Horizontal scaling per service
### 3. **Fault Tolerance**
- If one agent crashes, others continue working
- Retry failed tasks automatically
- Graceful degradation
### 4. **Development Velocity**
- Teams can work on different agents independently
- Deploy agents separately
- Test in isolation
### 5. **Resource Optimization**
- GPU allocation per agent type
- CPU-only agents for lightweight tasks
- Memory limits per service
## Implementation Plan
### Phase 1: Create Agent Services (Week 1)
1. **Music Generation Agent** (`agents/music/`)
- Python 3.11 environment
- FastAPI service on port 8002
- Endpoints: `/generate`, `/status`, `/health`
- Dependencies: torch, audiocraft, transformers
2. **Vocal Generation Agent** (`agents/vocal/`)
- Python 3.11 environment
- FastAPI service on port 8003
- Endpoints: `/generate`, `/status`, `/health`
- Dependencies: bark, RVC, TTS libraries
3. **Post-Processing Agent** (`agents/processing/`)
- Python 3.11 environment
- FastAPI service on port 8004
- Endpoints: `/mix`, `/separate`, `/master`, `/health`
- Dependencies: demucs, librosa, pydub
### Phase 2: Update Main API (Week 1-2)
1. **Orchestrator Service** (`backend/app/services/orchestrator.py`)
- Manages workflow across agents
- Handles task distribution
- Aggregates results
- Error handling and retries
2. **Agent Communication** (`backend/app/clients/`)
- HTTP clients for each agent
- Async/await for non-blocking calls
- Circuit breaker pattern
- Health checks
### Phase 3: Message Queue Integration (Week 2)
1. **Celery Tasks** (`backend/app/tasks/`)
- Background job processing
- Task routing to appropriate agents
- Result callbacks
- Progress tracking
2. **Redis Integration**
- Job queue management
- Status updates
- Caching
- Pub/Sub for real-time updates
### Phase 4: Docker Compose (Week 2-3)
```yaml
version: '3.8'
services:
# Main API - Python 3.13
api:
build: ./backend
ports: ["8001:8001"]
depends_on: [postgres, redis]
# Music Agent - Python 3.11
music-agent:
build: ./agents/music
ports: ["8002:8002"]
environment:
- PYTHON_VERSION=3.11
- TORCH_VERSION=2.1.0
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
# Vocal Agent - Python 3.11
vocal-agent:
build: ./agents/vocal
ports: ["8003:8003"]
# Processing Agent - Python 3.11
processing-agent:
build: ./agents/processing
ports: ["8004:8004"]
# Infrastructure
postgres:
image: postgres:16-alpine
redis:
image: redis:7-alpine
# Celery Workers
celery-worker:
build: ./backend
command: celery -A app.tasks worker --loglevel=info
depends_on: [redis]
```
## API Contract Example
### Main API → Music Agent
**Request:**
```json
POST http://localhost:8002/generate
{
"prompt": "Epic orchestral soundtrack",
"duration": 30,
"model": "facebook/musicgen-medium",
"temperature": 1.0,
"top_k": 250,
"callback_url": "http://api:8001/callbacks/generation/123"
}
```
**Response:**
```json
{
"task_id": "music_gen_abc123",
"status": "processing",
"estimated_time": 45
}
```
**Callback (when complete):**
```json
POST http://api:8001/callbacks/generation/123
{
"task_id": "music_gen_abc123",
"status": "completed",
"audio_path": "/storage/audio/music/abc123.wav",
"metadata": {
"duration": 30.5,
"sample_rate": 32000,
"model": "facebook/musicgen-medium"
}
}
```
## Migration Path
### Option A: Gradual Migration (Recommended)
1. Keep existing monolithic service running
2. Deploy music agent alongside
3. Route new requests to agent
4. Monitor and validate
5. Migrate other services one by one
6. Deprecate monolithic service
### Option B: Big Bang Migration
1. Build all agents
2. Test thoroughly in staging
3. Switch over in one deployment
4. Higher risk, faster completion
## Monitoring & Observability
### Metrics to Track
- Request latency per agent
- Success/failure rates
- Queue depth
- Agent health status
- Resource utilization (CPU/GPU/Memory)
- Generation time per model
### Tools
- Prometheus for metrics
- Grafana for dashboards
- Jaeger for distributed tracing
- Structlog for centralized logging
## Cost Considerations
### Infrastructure
- **Current:** 1 server with all dependencies
- **Agent:** Multiple smaller services
- **Savings:** Scale only what you need
### Development
- **Initial:** Higher (build agents)
- **Ongoing:** Lower (easier maintenance)
- **Team:** Can parallelize work
## Alternative: Subprocess Approach
If full microservices is too heavy, consider:
```python
# backend/app/services/music_generation.py
import subprocess
import json
class MusicGenerationService:
def __init__(self):
self.python311 = "C:/Python311/python.exe"
self.agent_script = "./agents/music_agent.py"
async def generate(self, prompt: str, duration: int):
# Call Python 3.11 subprocess
result = subprocess.run([
self.python311,
self.agent_script,
"--prompt", prompt,
"--duration", str(duration)
], capture_output=True, text=True)
return json.loads(result.stdout)
```
**Pros:** Simpler, no network overhead
**Cons:** Harder to scale, less fault-tolerant
## Recommendation
**Start with Agent Architecture** because:
1. ✅ Solves Python version issues permanently
2. ✅ Better scalability for future growth
3. ✅ Industry standard for ML services
4. ✅ Easier to add new models/features
5. ✅ Better resource utilization
6. ✅ Aligns with modern cloud-native patterns
## Next Steps
1. Create `agents/` directory structure
2. Build Music Agent first (highest priority)
3. Update orchestrator to call agent
4. Test end-to-end workflow
5. Deploy to staging
6. Monitor and iterate
## Timeline Estimate
- **Week 1:** Music Agent + Orchestrator updates
- **Week 2:** Vocal & Processing Agents + Celery
- **Week 3:** Docker Compose + Testing
- **Week 4:** Production deployment + Monitoring
**Total:** 3-4 weeks for full implementation