Files
cleveragents-core/docs/architecture.md
T
freemo f1ab5d90dc
CI / unit_tests (push) Waiting to run
CI / benchmark-publish (push) Waiting to run
CI / build (push) Waiting to run
CI / docker (push) Blocked by required conditions
CI / helm (push) Waiting to run
CI / status-check (push) Blocked by required conditions
CI / lint (push) Waiting to run
CI / typecheck (push) Waiting to run
CI / security (push) Waiting to run
CI / quality (push) Waiting to run
CI / integration_tests (push) Waiting to run
CI / e2e_tests (push) Waiting to run
CI / coverage (push) Blocked by required conditions
CI / benchmark-regression (push) Blocked by required conditions
docs: update documentation for v3.8.0 unreleased features
- Promote [Unreleased] CHANGELOG entries to [3.8.0] (2026-04-05)
- Add Shell Danger Detection section to docs/api/tui.md covering
  ShellDangerLevel, DangerousPattern, ShellSafetyService, and
  SafetyCheckResult with full API reference and usage examples
- Add InvariantService section to docs/api/core.md documenting
  the new DI-registered singleton, its methods, and emitted events
- Update docs/architecture.md Plan Lifecycle section to document
  invariant reconciliation as a phase transition gate
- Update README.md Highlights with shell danger detection, inline
  permission questions, invariant reconciliation, UKO provenance
  tracking, and JSON-RPC 2.0 A2A wire format
- Create docs/modules/shell-safety.md with full module guide
  covering purpose, key classes, built-in patterns, custom pattern
  registration, TUI integration, and testing guidance

ISSUES CLOSED: #1003 #997 #1391 #1004 #891 #1501 #1577 #1941 #2334
2026-04-05 19:33:19 +00:00

10 KiB

Architecture Overview

CleverAgents is a Python-first AI agent orchestration platform. It provides a unified CLI (agents), an interactive TUI, an embedded runtime, and service orchestration tools for building and running complex, long-running AI-driven workflows.

This document gives a developer-oriented overview of the system. For the authoritative specification see docs/specification.md. For individual design decisions see the ADR index.


High-Level Component Map

graph TD
    subgraph "Entry Points"
        CLI["CLI<br/>(agents / cleveragents)"]
        TUI["TUI<br/>(agents tui)"]
        SERVER["Server<br/>(agents server)"]
    end

    subgraph "Application Layer"
        A2A["A2A Facade<br/>(local / HTTP)"]
        DI["DI Container<br/>(application.container)"]
        SERVICES["Application Services<br/>(plan, session, actor, skill, tool, …)"]
    end

    subgraph "Domain Layer"
        PLAN["Plan Lifecycle<br/>(Strategize → Execute → Apply)"]
        ACTOR["Actor System<br/>(config, loader, compiler)"]
        RESOURCE["Resource DAG<br/>(handlers, inheritance)"]
        DECISION["Decision Tree<br/>(record, version, rollback)"]
    end

    subgraph "Infrastructure Layer"
        DB["Database<br/>(SQLAlchemy + Alembic)"]
        SANDBOX["Sandbox<br/>(checkpoint, rollback)"]
        OBS["Observability<br/>(logging, metrics, audit)"]
        EVENTS["Event Bus<br/>(reactive streams)"]
        PLUGINS["Plugin Manager"]
    end

    subgraph "Integration Layer"
        LANGGRAPH["LangGraph Bridge"]
        MCP["MCP Adapter"]
        LSP["LSP Client"]
        ACMS["ACMS<br/>(context management)"]
        UKO["UKO Runtime<br/>(knowledge ontology)"]
    end

    CLI --> A2A
    TUI --> A2A
    SERVER --> A2A
    A2A --> DI
    DI --> SERVICES
    SERVICES --> PLAN
    SERVICES --> ACTOR
    SERVICES --> RESOURCE
    SERVICES --> DECISION
    PLAN --> LANGGRAPH
    ACTOR --> LANGGRAPH
    LANGGRAPH --> MCP
    LANGGRAPH --> LSP
    SERVICES --> ACMS
    ACMS --> UKO
    SERVICES --> DB
    SERVICES --> SANDBOX
    SERVICES --> OBS
    SERVICES --> EVENTS
    SERVICES --> PLUGINS

Layered Architecture

CleverAgents follows a strict layered architecture (ADR-001):

Layer Package Responsibility
Entry Points cli, tui User-facing interfaces
Application application DI wiring, service orchestration
Domain domain, actor, skills, tool, resource Business logic
Infrastructure infrastructure Database, sandbox, events, observability
Integration a2a, mcp, lsp, langgraph, acms External protocol adapters
Core core, shared, config Cross-cutting utilities

Dependencies flow downward only — upper layers may import from lower layers but never the reverse.


Plan Lifecycle

The plan lifecycle is the central abstraction (ADR-006):

Action ──► Strategize ──► Execute ──► Apply
  │            │              │          │
  │        (estimate)    (validate)  (diff review)
  │                           │
  └───────────────────────────┘
           (correction / rollback)
Phase Description
Action User intent captured as a plan request
Strategize LLM generates a structured plan with operations
Execute Operations executed against resources via tools
Apply Validated changes committed; diff reviewed and approved

Phase transitions are gated by:

  • Validation pipeline — rule-based checks with severity levels
  • Definition-of-Done — explicit criteria evaluated before Apply
  • Advisory locking — prevents concurrent modification of the same plan
  • Invariant reconciliationInvariantReconciliationActor runs automatically at each phase transition (start_strategize, execute_plan, apply_plan); failures raise ReconciliationBlockedError and emit INVARIANT_VIOLATED events, blocking the transition until invariants are satisfied

Actor System

Actors are the execution units (ADR-010, ADR-031):

  • Defined in YAML with a LangGraph node graph
  • Each node binds an LLM, a set of tools, and optional LSP/MCP sources
  • Compiled by ActorCompiler into a runnable CompiledActor
  • Registered in ActorRegistry and resolved by name at runtime
# examples/actors/graph_workflow.yaml
name: openai/gpt-4o
entry_node: planner
nodes:
  planner:
    model: gpt-4o
    tool_sources: [builtin, mcp://bash-tools]
  executor:
    model: gpt-4o-mini
    tool_sources: [builtin]
edges:
  - from: planner
    to: executor
    condition: needs_execution

Tool System

Tools are the atomic capabilities available to actors (ADR-011):

  • Registered in ToolRegistry with a ToolSpec (JSON Schema) and executor
  • Four-stage lifecycle: activate → validate → execute → deactivate
  • Sources: builtin, mcp, lsp, skill
  • Safety profiles control sandbox requirements, human approval gates, and cost limits
  • Read-only enforcement blocks write-capable tools on read-only plans

Skill System

Skills are composable capability bundles (ADR-012, ADR-028):

  • Loaded from YAML or AgentSkills.io-compatible directories
  • Three-tier progressive disclosure: discover → activate → deactivate
  • Each skill exposes one or more tools to the actor
  • SkillRegistry tracks all registered skills; SkillRefreshResult reports changes

Resource System

Resources are managed external entities (ADR-008):

  • Organized as a DAG (Directed Acyclic Graph) with dependency tracking
  • Type hierarchy with multiple inheritance and field merging (ADR-042)
  • Built-in types: file, directory, sqlite, postgresql, mysql, duckdb, container.docker, container.podman, lsp.*, cloud.*
  • Each type has a handler implementing CRUD, checkpoint, and rollback

Context Management (ACMS)

The Advanced Context Management System manages what context is sent to the LLM at each phase (ADR-014):

  • Tier 1 — Always-present system context
  • Tier 2 — Phase-specific context (plan, project, actor)
  • Tier 3 — Dynamic retrieval (semantic search, UKO inference)

The UKO Runtime (Universal Knowledge Ontology) provides graph-based knowledge inference and persistence for Tier 3 context strategies.

Key UKO capabilities:

  • Typed triples with provenance — every triple carries sourceResource, validFrom, and isCurrent metadata
  • Temporal versioning — a revision chain tracks ontology state across indexing runs, enabling point-in-time queries
  • Implicit inferenceUKOInferenceEngine produces uko:implicitSiblingOf, uko:implicitContains, and uko:implicitDependsOn triples with confidence 0.7
  • Graph persistenceUKOGraphPersistence serialises/restores state via JSON-file or in-memory backends across application restarts

A2A Protocol Boundary

All CLI, TUI, and server interactions cross the A2A boundary (ADR-026, ADR-047):

  • Local modeA2aLocalFacade maps operations to direct Python calls
  • Server modeA2aHttpTransport (stub; full implementation pending)
  • Version negotiation via A2aVersionNegotiator

MCP Integration

External tool servers are integrated via the Model Context Protocol (ADR-029):

  • MCPToolAdapter manages server lifecycle and tool discovery
  • McpClient provides lazy start and auto-stop
  • SandboxPathRewriter prevents path traversal
  • MCPRefreshHook keeps skill registrations in sync with server changes

LSP Integration

Language Server Protocol servers provide code intelligence tools (ADR-027):

  • LSPClient manages server lifecycle and capability negotiation
  • LSP tools are registered in ToolRegistry with source="lsp"
  • Per-node LSP bindings in actor YAML control which server each node uses

Dependency Injection

All application services are wired via the DI container (ADR-003):

from cleveragents.application.container import Container

container = Container()
plan_service = container.plan_service()
session_service = container.session_service()

The container is the single source of truth for service instantiation. Never construct services directly in application code.


Observability

(ADR-025)

  • Structured logging via cleveragents.config.logging
  • Metrics processing via cleveragents.config.metrics_processor
  • Audit logging via infrastructure.observability
  • Token/cost tracking per plan and per day with budget enforcement

Key Design Decisions

Decision ADR Summary
Layered architecture ADR-001 Strict layer boundaries, no upward imports
Namespace system ADR-002 provider/name qualified identifiers
Dependency injection ADR-003 Single DI container, no service locator
Plan lifecycle ADR-006 Four-phase lifecycle with gating
LangGraph integration ADR-022 LangGraph as graph execution engine
Sandboxing ADR-015 Checkpoint/rollback for all resource writes
Template security ADR-032 Sandboxed Jinja2 with allowlist
TUI framework ADR-044 Textual-based full-screen TUI with first-run experience, persona system, session export/import
Server architecture ADR-048 ASGI server with Kubernetes deployment