Architecture Overview¶

G6 is built for AI agents that need to reason reliably over time. Every component must be independently verifiable (formal methods can check them), composable (pipelines combine them), and stateful (learning persists across sessions). This drives every design choice in the system.

The result is a cognitive infrastructure platform: 270 registry components organized into seven intelligence classes, delivered through multiple protocol adapters.

Mental model: three layers¶

Before the diagram, here is G6 in plain language:

1. Protocol layer — How you connect. MCP (for AI assistants), REST (for web apps), CLI (for terminals). All three hit the same component registry.
2. Orchestration layer — How components are discovered and composed. The ComponentRegistry auto-discovers 270 registry components at startup. Typed pipelines compose them into multi-step workflows with trio-powered async execution.
3. Intelligence layer — The 270 registry components themselves, grouped into seven classes. Each class addresses a distinct cognitive capability, from learning and self-modification to formal verification and safety.

System architecture¶

flowchart TD
    subgraph Client
        CC[Claude Code / MCP Client]
    end

    subgraph Transport
        SSE[HTTPS / SSE]
        STDIO[stdio]
    end

    subgraph Infrastructure
        NG[nginx<br/>TLS + Auth + Rate Limit]
    end

    subgraph G6["G6 Cognitive Layer"]
        MCP[MCP Server<br/>FastMCP]
        REST[REST Server<br/>FastAPI]
        CLI[CLI<br/>Textual TUI]
        REG[Component Registry<br/>270 registry components]
    end

    subgraph Intelligence["Seven Intelligence Classes"]
        SL[Self-Learning]
        SM[Self-Modification]
        FE[Failure Engineering]
        AE[Alignment Engineering]
        FM[Formal Methods]
        SML[Symbolic ML]
        SI[Self-Improvement]
    end

    subgraph Backend
        LLM[LLM Backends<br/>Ollama / OpenRouter]
    end

    CC -->|Cloud| SSE --> NG --> MCP
    CC -->|Local| STDIO --> MCP
    MCP --> REG
    REST --> REG
    CLI --> REG
    REG --> SL & SM & FE & AE & FM & SML & SI
    SL & SM & FE & AE & FM & SML & SI --> LLM

The seven intelligence classes¶

1. Self-Learning¶

Converts expensive LLM reasoning into cached deterministic algorithms. After an agent solves a problem once, the solution is distilled into a reusable pattern that runs without LLM calls.

Components: adapt_memory, adapt_pandas, adapt_sklearn, adapt_optimisation, adapt_pygad

2. Self-Modification¶

CEGIS synthesises code from sketches with holes, verified against an oracle function. The agent can rewrite its own components under safety gates -- CSF risk bounds, tests, and human approval -- before any modification takes effect; formal verification is applied where the change is expressed in a supported formal model and a backend is available, not universally guaranteed.

Components: meta_programming, cegis, adapt_healing

3. Failure Engineering¶

Constructive safety with explicit bounds -- not just post-hoc guardrails. The CSF framework checks that an action's modeled risk is below a threshold before execution, rather than only catching failures after they happen.

Components: csf, adapt_healing, grounding

4. Alignment Engineering¶

Specification-driven alignment with evaluation feedback loops. Specs define what "correct" means, evals measure it, and the prompt library stores proven-safe interaction patterns.

Components: align_specs, align_evals, align_csf, align_prompt_library

5. Formal Methods¶

SAT, SMT, DPLL, and Z3 integration — 405 tools across the formal_methods MCP surface. When you need a proof, not a guess.

Component: formal_methods

6. Symbolic ML¶

Retrieval, search, and knowledge grounding. Multiple retrieval strategies (TF-IDF, ColBERT, BM25, Elasticsearch) so the agent can find relevant information before reasoning about it.

Components: ctx_rag, ctx_colbert, ctx_elastic, ctx_search, ctx_recursive

7. Self-Improvement¶

Evolutionary skill synthesis — the system proposes new strategies, tests them against validation data, and promotes winners. This is the T2-T3 mechanism that lets G6 improve its own learning rules, distinct from Self-Modification's code-level rewriting.

Component: evoskill

How data flows: a worked example¶

Here is what happens when you ask "Analyse sales data from Q4":

1. Your AI assistant matches the request to the adapt_pandas MCP gateway tool
2. The MCP server receives the JSON call and runs it through middleware (auth, rate limit, tier check)
3. The gateway parses operation: "analyze" and dispatches to AdaptPandasBlock.process()
4. The block loads the dataset, runs the analysis, and returns a Result[DataOutput]
5. If the result is .ok, it's serialized to JSON and sent back over the transport
6. If the result is .fail, the error message includes a [RESOURCE_LIMIT] or [PANDAS_ERROR] tag so the assistant can diagnose and retry
7. Your assistant presents the analysis in the conversation

Each step is typed, bounded, and independently testable.

Key design decisions¶

Model agnostic — G6 works with any LLM backend. The llm_router component abstracts provider differences, so switching from OpenRouter to Ollama to a local model is a configuration change, not a rewrite. This eliminates vendor lock-in and lets you choose the cost/quality tradeoff per task.

Safety first -- Post-hoc guardrails can catch known failure modes, but they cannot prove absence of harm. The Constructive Safety Framework (CSF) provides a pre-execution risk budget: each action's configured hazard prior is checked against a configurable epsilon, and execution only proceeds if the modeled risk stays inside that budget. This makes safety decisions auditable rather than implicit.

Composable — Monolithic AI systems can't be verified piece-by-piece. G6's 270 registry components connect via typed pipelines (AIBlock >> AIBlock), where each block has explicit input, output, and state types. Where a component's contract is formally specified and a backend is available, you can formally verify it in isolation; composing verified components is not by itself a guarantee of correctness in every pipeline (see Theoretical Foundations).

Railway-oriented — Exceptions create hidden control flow that's hard to reason about. Every operation returns Result[T] — either .ok(value) or .fail(error). Errors are data, not interruptions, so they compose through .map(), .flat_map(), and .or_else() without try/catch blocks.

Resource bounded — Unbounded agents are unpredictable. Every operation runs within ResourceBounds that cap tokens, time, and cost. When bounds are exceeded, the operation fails explicitly with a [RESOURCE_LIMIT] tag rather than silently consuming resources.

Architecture deep dives¶