Architecture
AME-1 — Technical Brief
An extensible modular monolith: one Rust binary carrying a specified 21-module mind, every dependency behind a swappable adapter, every new capability an extension package.
The design doctrine
The design doctrine, stated bluntly: the LLM is a component, not the orchestrator. A metareasoning pipeline decides what runs; the LLM proposes; symbolic machinery verifies. An “agent,” in current usage, is scaffolding around an LLM — the LLM at the center. This architecture inverts that; the honest picture is a mind whose faculties are separate components, with the LLM as exactly one of them:
| Faculty | Component |
|---|---|
| Imaginationfluent, associative, unreliable | the local LLM — any model, your choice: it proposes candidate understandings and drafts, and nothing it says is trusted unverified |
| Judgmentdeterministic, provable | neuro-symbolic metareasoning — the pipeline decides what runs, the symbolic inference engine derives and proves, the consistency gates check every claim against the record: that is where the determinism comes from |
| Memoryprovenance-tracked, admission-gated | the fourteen stores — episodes, facts, sources, relationships, affect: every write behind the admission gate, every fact carrying its provenance and its confidence |
| Consciencemandatory, stake-scaled | the ethics gates + consequence simulation — every action checked before it happens, high-stakes actions simulated first, fail-closed throughout |
| Attentioncapacity-limited, salience-driven | the global workspace — the capacity-limited conscious set: salience competition decides what the mind attends to, and what wins is broadcast |
The anatomy — 21 modules
The architecture is defined in full — 21 modules across 7 functional layers, decomposed into more than 120 specified submodules, every major decision carried by an ADR — and built module by module against hard gates.
AME-1 — The Module Map
Interface
Interface
Where the character meets people, surfaces, and other characters.
Interaction Interfaces — the human gateway: voice, text, GUI, API — every human-originated exchange enters and leaves here, stateless and standardized.
UI Manager — one UI layer for every surface: coordinates the user interfaces across devices and domains, extensible through packages.
Communication Framework — the wire: service discovery, connections, authentication, messaging — for client-server and character-to-character exchanges.
Cognitive
Cognitive
The thinking machinery: understanding, attention, provenance.
Cognition & Reasoning — turns raw input into structured knowledge: semantic analysis, symbolic inference, neural reasoning, pattern recognition — with the LLM integrated as one component.
Global Workspace — consciousness science as information architecture: owns the attention-filtered, capacity-limited working set of what the character is currently aware of and reasoning about.
Source Management — the provenance authority: every source registered — humans, documents, sensors, LLMs, other characters — so every stored fact traces back, with confidence.
Identity & Agent
Identity & Agent
The someone itself, and the people it knows.
Character Management — the character's lifecycle: identity, personality, affect, goals — the someone, managed as data.
User Model — long-term profiles of the humans: preferences, tendencies, and the relationship itself — trust and familiarity, evolving in both directions.
Action Pipeline
Action Pipeline
From intention to act — inspired by the brain's motor hierarchy.
Action Initiation — the control layer: converts reasoning outputs and external signals into prioritized action triggers, routed to planning or fast-path execution.
Action Planning — the strategic layer: the approach, the temporal schedule, and the validation of every plan.
Action Execution — the doing layer: one orchestrator for all four action modalities — communicate, manipulate, navigate, perceive.
Evaluation & World
Evaluation & World
Consequences simulated before actions run.
Scenario Evaluation — simulates and evaluates candidate action scenarios during planning, and learns from real execution outcomes to refine its models.
World Model — the state of the world: a live-maintained domain view, frozen into consistent point-in-time snapshots for simulation and reasoning.
Memory & Knowledge
Memory & Knowledge
The record: fourteen stores behind an admission-gated entry.
Memory & Knowledge — the long-term memory backbone: persistent storage and retrieval for every knowledge type through one coordinated entry point, across fourteen specialized stores:
symbolic · fuzzy · episodic · source · pattern · ontology · affect · character profile · world · user profile · relationship · action · ethics · claim
Knowledge Integration — the door for contributed knowledge: validation and sandboxing, so nothing a package provides can compromise consistency, safety, or explainability.
Governance
Governance
The conscience, the locks, and the trace.
Ethics & Constraints — every proposed action checked against configurable ethical, legal, and safety rules before it happens.
Security Manager — the authorization authority: permissions, sandboxes, data access, egress — fail-closed by construction: no error, timeout, or missing verdict ever yields an allow.
Audit — system-wide traceability and accountability: every module's activity captured in a structured, character-aware record.
Actuation
Actuation
The hands: acting on the world through adapters.
Capability Actuation — translates validated actions into concrete operations on devices, applications, and systems — heterogeneous effectors behind uniform adapters, with ground-truth feedback.
Platform Services
Platform Services
The ecosystem's machinery.
Package Manager — the full extension-package lifecycle: discovery, installation, activation, update, removal — the central authority on what is present and active, across sandboxed trust tiers.
Observability
Observability
The system watching itself.
System Observability — real-time health monitoring, cross-module performance correlation, unified alerting: each module watches its own domain; this one watches the system.
The module map: 21 modules, one architecture. Every module is specified; the system is built module by module against hard gates. Each layer opens to its modules and their purposes.
Architecture overview
A modular monolith, deliberately. All modules compile into one Rust binary — modules are logical boundaries with typed contracts, not deployment units. Rust for the always-on profile: no GC pauses, ~millisecond startup, a footprint that fits beside your other applications. The designed personal deployment is 2–3 processes — the binary, PostgreSQL, and a lightweight message bus — on ordinary consumer hardware. Local-first is the architecture, not a mode: LLMs run through Ollama on the same machine, and embeddings/NLP run in-process via ONNX, no sidecar services. And the monolith is not a prison: because every cross-module interaction is a typed event, a module can be externalized into its own process or service when a deployment needs it — the contract stays, only the transport changes.
Three-tier event architecture. Tier 1 is a global backbone (NATS JetStream in personal deployments, Kafka in enterprise), partitioned by assistant identity, with a long-retention audit stream. Tier 2 is per-module buses — in-process channels with a per-event durable/ephemeral classification, where durable events get a write-ahead log and replay-on-crash. Tier 3 is sub-module, always in-memory. Every event is a typed envelope with correlation IDs and schema versions; a canonical three-step dispatch invariant (typed request → trait dispatch → typed completion) keeps every cross-module interaction visible on the bus — auditability and replay as structural properties, not logging conventions. And the tiers are the scaling story: because every cross-module interaction is already an event on a partitioned backbone, the same architecture that runs one household on NATS runs a large organization on Kafka — characters partition by identity across the cluster, and scaling is deployment configuration, not redesign.
Storage: PostgreSQL as the one-stop shop. The knowledge graph is plain SQL — recursive CTEs for traversal, pgvector for embeddings, JSONB for documents — one battle-tested process instead of four databases. Every data path goes through a backend trait (GraphBackend, VectorBackend, EventBus, LlmAdapter, …): swapping to Neo4j, Qdrant, or Kafka for an enterprise profile is configuration, not code. One binary serves every deployment profile — Personal → Domotic → Enterprise — by YAML alone, with data preserved across upgrades.
Stack summary
AME-1 — One Binary, Three Deployments
Personal
one person, one machine
Personal
The designed personal deployment: the binary, PostgreSQL, and a lightweight message bus — 2–3 processes on ordinary consumer hardware. Local-first is the architecture, not a mode: nothing on the serve path requires a cloud.
Home
the household — domotic profile
Home
The domotic profile: the Personal stack on a home server, opened to the household — several characters, several people, the shared devices of the house. It is, give or take, the profile the lab develops against day to day.
Enterprise
the organization
Enterprise
The organization profile: the same binary and the same contracts, with role-based access control, advanced audit, federation — and the infrastructure swapped to the organization's standards by configuration, not code.
Processes
one machine · 2–3 processes · Docker
AME-1 — one Rust binary PostgreSQL NATS JetStreamPersonal · processes
What actually runs: 2–3 OS processes — the binary, PostgreSQL, and the message bus — on one machine. The Dioxus UI is Rust compiled to WebAssembly, sharing types with the binary: no drift. The processes ship as Docker containers. The red line is the conversation — the only path that matters to the person in the room.
home server · same processes · Docker
AME-1 — one Rust binary PostgreSQL NATS JetStreamHome · processes
The same processes on the home server; the household's screens are surfaces to the one binary, not extra servers. The conversation still crosses one red line — it just reaches more rooms.
cluster · instances for capacity · Docker
AME-1 binary — × N instances Store cluster Kafka clusterEnterprise · processes
The same processes, multiplied where load demands: instances of the binary added for capacity, the backbone as a broker cluster, the store as the organization's cluster. Every process ships as a Docker container, ready for the organization's own orchestration — and every one still behind the same typed contracts.
Characters
One character, one user
Personal · characters
One character — yours. Single-character, single-user by design: the simplest possible privacy story, because there is no shared state to arbitrate.
A family of characters
multi-character · multi-user
Home · characters
Several characters, several people: each character knows its household, and relationships are tracked per person — who asked, who prefers what, who may do what.
Characters per department
partitioned by identity
Enterprise · characters
Specialized characters per department, each plugged only into what it is authorized to use, every action logged — and every store, query, and event stream partitioned by a mandatory character-identity type.
The binary
One Rust binary
2–3 processes total
Personal · the binary
All 21 modules compile into one binary — modules are logical boundaries with typed contracts, not deployment units. Rust with tokio async and sqlx compile-checked SQL: no GC pauses, ~millisecond startup, a footprint that fits beside your other applications.
The same binary, home server
Home · the binary
The identical binary on the home server; the household's screens and devices connect as surfaces. Nothing is forked — the home is a configuration of the same system.
Many instances, one binary
scaling = configuration
Enterprise · the binary
Scaling is deployment configuration, not redesign: because every cross-module interaction is already an event on a partitioned backbone, characters partition by identity across the cluster — capacity grows by adding instances of the same binary. A module can even be externalized into its own service when a deployment needs it: the contract stays, only the transport changes.
Storage
PostgreSQL + pgvector
one process, not four databases
Personal · storage
The one-stop shop: the knowledge graph in plain SQL (recursive CTEs for traversal), vectors via pgvector, documents as JSONB — one battle-tested process instead of four databases.
PostgreSQL + pgvector
same shop, household-sized
Home · storage
The same one-stop shop, sized for a household — every family member's data partitioned by character identity in the same store, with data preserved across upgrades.
The organization's choice
PostgreSQL · Neo4j · Qdrant · MongoDB · … (via custom adapters)
Enterprise · storage
Every data path crosses a backend trait (GraphBackend, VectorBackend, …) — the seams are built into every module, so matching the organization's standards (Neo4j for graph, Qdrant for vectors, MongoDB for documents) is configuration — and any other store the organization runs is a custom adapter away, never a rewrite.
Events
NATS JetStream
Tier-1 backbone
Personal · events
The global Tier-1 backbone, lightweight: partitioned by character identity, with a long-retention audit stream. Tier-2 buses stay in-process, write-ahead-logged where events are durable.
NATS JetStream
partitioned per family member
Home · events
The same backbone: every character's stream partitioned by identity, the household's actions all on the audit stream.
Kafka cluster
the same backbone, broker-scale
Enterprise · events
The architecture that runs one household on NATS runs a large organization on a Kafka cluster — the same partitioned backbone, the same typed envelopes and audit stream, at broker scale.
Inference
Ollama — local LLMs
+ in-process ONNX
Personal · inference
Local models through Ollama — the model is a component, not the orchestrator, and no model is prescribed: you run the one you prefer and your hardware carries. The architecture specifies the seat, never the sitter. Embeddings and NLP run in-process via ONNX: no sidecar services, nothing leaves the machine.
Ollama — local LLMs
the house keeps its words
Home · inference
The household's models run at home — the household's pick, sized to the home server: the family's conversations are inferred on the family's hardware, not on someone else's servers.
Local pool or cloud
via the LLM adapter
Enterprise · inference
Through the LlmAdapter: a local inference pool or the organization's chosen provider — chosen by policy, compliance, or preference, never by the framework (llama.cpp and vLLM adapters planned, cloud adapters likewise). The model changes, the governance never moves.
Governance
Full pipeline, single-user
gates & audit always on
Personal · governance
The full ethics and security pipeline at single-user scale — the gates, fail-closed semantics, and audit are core architecture, not an enterprise add-on.
Shared devices · basic roles
Home · governance
The house's devices arrive through actuation adapters with feedback verification; basic role separation keeps the household's members apart where it matters; every action is logged.
Advanced RBAC · federation
advanced audit
Enterprise · governance
Role-based access control and advanced audit across departments — and federation: characters collaborating across organizations by exchanging conversation, never databases.
Three deployments of the same system — Personal, Home, Enterprise — one row per stack layer. Nothing is forked between columns: the differences are YAML profiles — the whole configuration story, with no config env vars and a single bootstrap selector — and every technology swap crosses an adapter seam.
Configuration and extension
Three layers that never mix: a stable core; adapters for every dependency — storage, events, inference, devices, federation, interfaces; and extension packages in sandboxed trust tiers. The extension surface is virtually infinite, and technology evolution is absorbed by design: a new model, protocol, or device class is a new adapter or a new package — never a rewrite. That includes the ecosystem’s own protocols: an MCP server can plug in as a sandboxed connector package, its tools becoming capabilities inside the envelope — every invocation gated, logged, and auditable like any other action. Where most agent stacks wire MCP tools straight into the LLM, here they enter through the actuation layer: the tools arrive; the governance never moves.
Extension packages
ontologies · vocabularies · ethics rulesets · personalities · connectors · device drivers
Adapters
storage · events · inference · devices · federation · interfaces
The core
21 modules — never forked
Three layers that never mix — hover each one, from the stable core outward to the open ecosystem.
The core
The specified architecture: the 21 modules and their typed contracts. Configured for every deployment — from one person to an organization — and never forked: every character everywhere runs the same core.
Adapters
The technology seams. Every dependency sits behind a swappable interface — storage, events, inference, devices, federation, interfaces — so the infrastructure can change without the mind changing. A new database, model, protocol, or device class is a new adapter, never a rewrite.
Extension packages
The open ecosystem: capabilities, connectors, bodies of knowledge, personalities, device drivers — buildable by any developer or organization, shipped in sandboxed trust tiers: config → knowledge → sandboxed code → privileged. An MCP server plugs in as a connector package: the tools arrive, the governance never moves.
The three layers of every AME-1 deployment: a core that never forks, adapters that absorb technology change, and an extension ecosystem that grows without touching either.
Innovation points (the ones competitors don’t have)
- Memory that refuses facts. Every write to the knowledge graph passes a three-way admission gate — Admit / Quarantine / Reject — designed against demonstrated memory-poisoning attacks, with fail-closed semantics (“could not check” never admits) and a veto keyed on the stored fact’s confidence, so an attacker can’t disarm it by hedging.
- The LLM as a registered source. For knowledge acquisition the LLM is just another source in the registry — lowest trust, structured output only, self-reported confidence treated as a rejection signal, queries depersonalized. Recorded knowledge gaps drive acquisition the other way first: ask the user, LLM last.
- One confidence ledger. A unified confidence architecture — Source → Claim → Reasoning → Action — with explicit formulas at every seam and a breakdown on every output. Sources carry per-domain trust track records: a source trusted on medicine isn’t trusted on politics.
- A machine self-model, taken literally. Capabilities, permission denials, ethical blocks, and knowledge gaps are first-class graph facts. “What can you do?” is answered from data, not a prompt; per-domain coverage metadata lets the assistant say how much it knows and how stale it is. A Global Workspace module (Dehaene’s C1 as information architecture: salience competition, ignition, broadcast conscious set) governs what the system is attending to.
- Governance in the pipeline, not on the output. Every action passes a mandatory ethics gate — and an utterance is an action, gated before a byte leaves, at a depth scaled to stakes; high-stakes cases get consequence simulation in copy-on-write branch-worlds before execution. The security layer is fail-closed by construction: no error path, timeout, or missing verdict resolves to allow, and an audit-write failure converts a grant into a deny.
- Privacy as a type-system fact. Every store, query, and event stream is partitioned by a mandatory assistant-identity newtype — an unfiltered query is rejected at the API boundary. Egress is consent-stamped and deny-by-default. Federation exchanges conversation, never databases.
- Extensible without touching the core. Ontologies, domain vocabularies, ethics rulesets, personalities, connectors, and device adapters ship as packages across sandboxed trust tiers (config → knowledge → sandboxed code → privileged); actuation runs through adapters with ground-truth feedback verification.
Questions and suggestions welcome: contact@ame-labs.eu.