-
Notifications
You must be signed in to change notification settings - Fork 8
/
Copy path.cursorrules
160 lines (130 loc) · 3.86 KB
/
.cursorrules
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
# Agent OS Platform Design
## System Overview
The Agent OS Platform is a FastAPI-based system for running AI agents with dynamic tool creation and secure execution capabilities.
## Core Architecture
### Components
1. **Master Container (FastAPI)**
- Handles user interactions
- Manages agent lifecycles
- Coordinates tool execution
- Runs on Python 3.13 (slim image)
2. **E2B Integration**
- On-demand sandbox creation for tool execution
- One sandbox per tool execution
- Short-lived containers (destroyed after tool completion)
- Maximum execution time: 10 minutes (OpenAI limit)
- Firecracker microVM-based isolation
- Supports any Linux-compatible framework
- Handles package installation and I/O
3. **Redis Message Bus**
- Inter-component communication
- State management
- Event distribution
4. **Tool Registry**
- Firestore-based tool storage
- Tools stored as standalone Python code
- Each tool includes all dependencies
- No caching or hot-reloading
### Development Environment
1. **Local Development**
- Docker Compose based setup
- E2B for sandbox isolation
- Redis for message passing
- Firestore emulator for storage
2. **Production Environment**
- Similar to local but with real Firestore
- E2B for production sandboxes
- Potential future K8s migration
## Security Model
### Tool Execution
1. **E2B Sandbox**
- Created on-demand for each tool execution
- Destroyed immediately after tool completion
- No session pooling or reuse
- Clean environment for each execution
- Resource limits enforcement
- Network isolation
- Secure file system access
2. **Tool Validation**
- Static code analysis
- Security checks
- Dependency scanning
- Automated testing
### Access Control
1. **Authentication**
- Firebase Authentication
- JWT validation
- Role-based access
2. **Authorization**
- Tool execution permissions
- Admin capabilities
- User isolation
## System Self-Improvement
### AI-Driven Updates
1. **Code Generation**
- AI creates/modifies platform code
- Generates pull requests
- Must pass all tests
- Manual review required
2. **Tool Creation**
- AI generates new tools
- Automated validation
- Security scanning
### Quality Assurance
1. **Testing**
- Very high coverage requirement
- Integration tests
- Security tests
- Performance benchmarks
2. **Monitoring**
- Execution metrics
- Error tracking
- Resource usage
- User analytics
## Implementation Notes
### Current State
- Single container deployment
- File-based tool storage
- Basic security validation
- Manual tool approval
### Migration Path
1. **Phase 1: E2B Integration**
- Add E2B sandbox support
- Implement on-demand container creation
- Add container cleanup after tool execution
- Implement security checks
- Add execution timeouts (10-minute limit)
2. **Phase 2: Message Bus**
- Redis integration
- State management
- Event system
3. **Phase 3: Tool Registry**
- Move to pure Firestore storage
- Remove file-based storage
- Implement standalone tool format
### Design Principles
1. **Simplicity**
- Minimal abstractions
- Clear responsibilities
- Direct communication
2. **Security**
- Isolated execution
- Validated tools
- Access control
3. **Maintainability**
- Clear documentation
- High test coverage
- Automated improvements
## Maintenance Instructions
This file (.cursorrules) serves as the source of truth for system design.
When making significant changes:
1. Update this file first
2. Ensure consistency with implementation
3. Remove or update other docs if needed
4. Keep this file in sync with:
- README.md (high-level overview)
- docker-compose.yml (deployment)
- backend/services/* (implementation)
---
Last Updated: [Current Date]
Update this file when making architectural changes.