Architecture
Maestro follows a layered architecture where each component has a clear responsibility.
Overview
Section titled “Overview”┌─────────────────────────────────────────────────────────────┐│ CHANNELS ││ [Telegram] [CLI] [REST API] │└─────────────────────────────┬───────────────────────────────┘ │┌─────────────────────────────▼───────────────────────────────┐│ ORCHESTRATOR ││ Routes requests to specialized agents │└─────────────────────────────┬───────────────────────────────┘ │┌─────────────────────────────▼───────────────────────────────┐│ AGENTS ││ [Personal Assistant] [Coder] [+ Custom] │└─────────────────────────────┬───────────────────────────────┘ │┌─────────────────────────────▼───────────────────────────────┐│ INFRASTRUCTURE ││ [Memory/SQLite] [Tools] [Projects] [Observability] │└─────────────────────────────────────────────────────────────┘Layers
Section titled “Layers”Channels
Section titled “Channels”Channels are interfaces that receive user input and return responses. Each channel:
- Receives messages from a specific platform (Telegram, CLI, HTTP)
- Transforms platform-specific formats into a common message format
- Routes messages to the orchestrator
- Returns responses in the platform’s expected format
All channels connect to the same orchestrator and share memory.
Orchestrator
Section titled “Orchestrator”The orchestrator is a specialized agent that:
- Analyzes incoming messages to understand intent
- Decides which agent is best suited to handle the request
- Routes the request to that agent
- Returns the agent’s response
The orchestrator has access to agent metadata (names, descriptions) but doesn’t do the actual work.
Agents
Section titled “Agents”Agents are LLM-powered workers with specific roles:
- System prompt defining their personality and capabilities
- Tools they can use (calculator, datetime, code execution)
- Model configuration (which Claude model, temperature, etc.)
Agents can be:
- Static: Defined in YAML files under
config/ - Dynamic: Created at runtime through conversation
Infrastructure
Section titled “Infrastructure”Shared services that all components use:
- Memory: SQLite-backed conversation persistence
- Tools: Registry of capabilities agents can use
- Projects: Git repository management
- Observability: Logging, token tracking, cost estimation
Request Flow
Section titled “Request Flow”1. User sends "Help me write a Python script" ↓2. Telegram channel receives message ↓3. Channel passes message to orchestrator ↓4. Orchestrator analyzes: "This is a coding task" ↓5. Orchestrator routes to coder agent ↓6. Coder agent: - Loads conversation history from memory - Calls Claude with system prompt + history + tools - Executes tools if needed (claude_code) - Returns response ↓7. Response flows back through channel to userData Flow
Section titled “Data Flow”Memory
Section titled “Memory”Each conversation is identified by a session ID:
- Telegram: Chat ID
- CLI: Fixed ID per terminal session
- API: Provided by caller
Memory stores:
- Message history (user messages, assistant responses)
- Tool calls and results
- Session metadata
Projects
Section titled “Projects”The project system maintains isolated workspaces:
- Each cloned repo gets its own directory
- Agents operate within the active project’s context
- Claude Code runs commands in the project directory
Code Organization
Section titled “Code Organization”src/├── agents/ # Orchestrator logic├── api/ # REST API (Hono framework)├── channels/ # Telegram, CLI adapters├── core/ # Agent runtime, types, registry├── llm/ # Anthropic provider├── memory/ # SQLite persistence├── observability/ # Logging, cost tracking└── tools/ # Tool system └── builtin/ # Built-in tools