This stack balances maturity, ecosystem support, and alignment with our architectural goals
Context
CleverAgents requires a cohesive technology stack that supports a CLI-first interface, LLM orchestration with multiple providers, structured data persistence, code intelligence indexing (full-text, vector, and graph), reactive event processing, sandboxed execution, and both local and server deployment modes. The stack must be Python-only for consistency and alignment with the LLM ecosystem. Every technology choice must have a clear rationale and defined minimum version.
Decision Drivers
Must be Python-only for consistency and alignment with the LLM ecosystem (LangChain, MCP SDK)
Requires CLI-first interface, LLM orchestration with multiple providers, and structured data persistence
Need configurable backends at every infrastructure layer (full-text, vector, graph indexing) swappable via configuration
Must support both local single-process and multi-user server deployment modes
Testing stack must cover behavioral (BDD), integration, unit, and property-based testing
Every technology choice must have a clear rationale and defined minimum version for reproducibility
Decision
CleverAgents is built on Python >= 3.13 as the sole implementation language. The stack is organized by functional area, with specific libraries chosen for CLI, LLM runtime, data persistence, indexing, configuration, testing, code quality, infrastructure, and observability.
Design
Core Runtime
Technology
Min Version
Role
Python
>= 3.13
Primary language. Type hint maturity, async/await, pattern matching, performance.
Hatchling
>= 1.21.0
PEP 517 build backend. Lightweight, standards-compliant.
uv
>= 0.8.0
Package installer and resolver. 10-100x faster than pip. Used in CI, Docker, and Nox.
DI container. DeclarativeContainer with Singleton, Factory, Configuration providers.
watchdog
>= 4.0.0
File system monitoring. Auto re-indexing on file changes.
numpy
>= 2.1.0
Vector operations for embedding similarity and confidence score aggregation.
uvicorn
>= 0.30.1
ASGI server for hosting the ACP JSON-RPC 2.0 endpoint in server mode.
Constraints
The entire codebase is Python-only. No secondary languages for core functionality.
Version constraints are minimum versions; newer compatible versions are acceptable.
All dependencies must be installable via uv and declared in pyproject.toml.
Configurable backends (Tantivy vs. SQLite FTS5, FAISS vs. Qdrant, Neo4j vs. rdflib) must be swappable via configuration without code changes, enabled by the hexagonal architecture.
The Docker production image must use python:3.13-slim with a non-root user.
Consequences
Positive
A single language across the entire stack simplifies hiring, tooling, and maintenance.
The LLM ecosystem (LangChain, MCP SDK) is Python-native, avoiding FFI overhead.
Configurable backends at every infrastructure layer allow adaptation to different deployment scales.
The testing stack (Behave + Robot + pytest + Hypothesis) covers behavioral, integration, unit, and property-based testing.
Negative
Python's runtime performance is lower than compiled languages; CPU-intensive operations (embedding computation, large index operations) rely on native extensions (numpy, FAISS, Tantivy).
The large dependency tree increases the attack surface and requires active dependency management.
Supporting multiple configurable backends per infrastructure layer increases the testing matrix.
Risks
Major version upgrades to LangChain or Pydantic could require significant migration effort.
Tantivy and FAISS are native extensions that may have platform-specific build issues.
The breadth of the stack means that not all developers will be expert in every component.
Alternatives Considered
None — specification-driven requirement. The technical stack is enumerated in the specification with specific version constraints and rationales for each choice.
Compliance
Dependency pinning: pyproject.toml declares minimum versions for all dependencies. uv.lock pins exact versions for reproducible builds.
CI matrix: The Forgejo CI pipeline tests against Python 3.11, 3.12, and 3.13 to ensure version compatibility.
Vulnerability scanning: Automated dependency vulnerability scanning (e.g., pip-audit or safety) runs in CI.
Build verification: Docker image builds are tested in CI to catch platform-specific build failures for native extensions.
Performance benchmarks: ASV tracks key performance metrics across commits to detect regressions from dependency changes.