zackemannen81/A008

A008 is a provider-neutral AI client and local engine with one shared runtime for chat, tools, projects and persistent semantic memory. It currently ships a CLI, an A008-owned web GUI/host, an ACP ...

2 stars · 0 forks

README

A008 A008 is a provider-independent AI client with a shared runtime for projects, chat, tools, and local semantic memory. This repository is the active canonical successor to A007. Media: public/screenshots

Implementation status

The status below is based on an inventory of the repository’s code, not on older project documentation.

Area Status Actual implementation

Shared runtime Implemented ProjectRuntimeRegistry, EngineHost, project-bound sessions, workspace/chat ownership, and portable engine bundle.

Projects Implemented Create projects, register existing directories, open projects, project registry, saved conversations, and workspace sessions.

Chat/sessions Implemented Normal standalone GUI uses host-owned durable conversations/runs with isolated worktrees, process-per-session execution, background observation, stored model/parameters, and image attachments. V1/V2/ACP remain compatibility surfaces.

Turn Runtime context optimizing Implemented During a turn, context will automaticly optimize both regular context and realtime tool runs. See hand-offs: A008-0193, A008-0205, A008-0203

Memory view Implemented Read-only Overview, Relationship Map/graph, and Knowledge Manager with search, filters, domain/status, and pagination.

CLI Implemented Interactive chat, /help, /model, /status, /history, /undo, /reset, /cwd, /tools, /shell, and /exit.

Web GUI Implemented A008-owned React/Vite GUI with Chat, Memory, Tools, Help, Projects, Settings, Upload, Files, Terminal, Browser, and Code Canvas.

Native desktop Implemented Standalone Tauri repo or native desktop client (electron) in this repository.

Expo/native proof Partially implemented Client-API-program Felixnissens fork A008-Pocket.

SDK Implemented packages/client contains the platform-independent @a008/client for V1, V2, and Platform V3 contracts.

API Implemented V1 host/ACP surface, authenticated V2 HTTP/WebSocket surface, and opt-in V3 durable-work surface.

SQLite Implemented better-sqlite3 is used for local semantic memory and, when enabled, Platform V3 conversations/runs/leases/receipts/outbox.

SQLite optional Implemented Memory uses configured SQLite or in-memory mode; public V3 remains configuration-gated, while normal standalone durable GUI chat can initialize its shared local Platform backend on first access.

Background instances Implemented The host runs process-per-session workers for durable project sessions; normal GUI submissions and observations use the shared Platform store/coordinator.

Themes Implemented There is something for everyone.

Custom instructions Implemented No more "you're a helpful assistant...."

Docs-first continuity protocol - Standard or Minimal Implemented A repository-native protocol for project continuity, bounded context and resumable work. (minimal saves alot of context)

Docs-first-multiagent-orchestrator-addon Implemented multiagent-orchestrator-addon (need to know basis context optimizing)

ACME-Engine execution Implemented Both strict and non-strict deterministic execution npmp integration running on ACME-Engine

Workflows and surfaces Projects Projects are host-owned and can be created with optional Git initialization, a Docs-First starter, and a multi-agent policy. An existing absolute directory can be registered without modifying its files. A project can have multiple saved chat conversations and separate workspace sessions. Chat Normal standalone GUI chat uses durable project conversations/runs behind the authenticated /v1/chat/v3/* facade and shares the configured Platform store/coordinator with public V3. Each writable conversation has its own Git worktree; accepted runs continue when the browser disconnects. Engine panels and legacy adapter paths retain V1 compatibility. Independent clients can use V2 or Platform V3 as appropriate. Memory The memory view is for diagnostics and reading. It exposes Overview, Relationship Map as stored nodes/associations, and Knowledge Manager with search, filters, status, domain, and detailed inspection. The view is read-only; it is not a visual knowledge-editing tool.

Agent features and capabilities

Capability Status Details

Provider/model-independent runtime Implemented ChatTransport, the model registry, and provider dispatch separate the client from model execution.

Text chat Implemented NVIDIA Build, kie.ai, and OpenAI have direct transport paths; embedded ACME is the default composition.

Thought/content separation Implemented Reasoning/thought is streamed separately, and private reasoning data is not written to committed memory.

Tool calling Implemented Structured tool calls, explicit permission/approval, budgets, and receipts.

Repository/file tools Implemented Read, create, and edit files, as well as literal Git operations through approved tools.

Shell/terminal Implemented Host-owned terminal with timeout, output budget, and truncation.

MCP Implemented Configurable stdio MCP servers, tool integration, and health probing.

File upload Implemented POST /v1/upload, content-addressed blob store, size cap, media sniffing, and text/Markdown/PDF text-layer/DOCX extraction.

Image generation Partially implemented NVIDIA NIM and kie Market jobs; results are saved as ordered image items in chat.

Multimodal input Partially implemented Native image attachments are supported for models/transport paths that declare image input. This is not a general multimodal guarantee for all models.

Vision-capable Partially implemented The registry includes image-compatible models and native image input; capability depends on the selected model/provider.

Video/audio/music Not implemented as a general runtime capability Unwired native provider endpoints are not treated as though they were supported.

Browser Implemented as a GUI surface Sandboxed renderer/browser frame checking is available; it does not automatically give the model unrestricted browser tools.

Code Canvas Implemented HTML artifacts are rendered in a sandboxed, network-denying preview.

Clients Web GUI Start with npm run gui. The default host is http://127.0.0.1:8787. The GUI includes Chat, Memory, Projects, Tools, Settings, Help, Upload, provider/model parameters, themes, workspaces, terminal, files, browser, image viewing, and Code Canvas. CLI powershell npm run build node .\dist\src\cli.js models npm run cli -- chat The CLI uses the same project- and memory-aware runtime as ACP. ACP / Agent Canvas A008-acp is a working ACP-compatible path for Agent Canvas/Agent Server. It is an operator/integration surface, not the primary product GUI. Native/desktop/Tauri There is no Tauri app, native desktop app, or Expo client in this repository. However, a platform-independent SDK and V2 protocol are available for future native/independent clients. API and protocol The V1 host has WebSocket sessions at /v1/session as well as routes for memory inspection, upload, projects/workspaces, provider/model, image generation, MCP, shell, and browser. V2 includes GET /v2/info, scoped device grants/revoke, one-use short-lived auth tickets, and WS /v2/session with a008.v2. Actions are session/new, session/inspect, session/prompt, session/cancel, session/control, and tool/permission. Event sequencing, terminal outcomes, bounded command receipts/idempotency, same-process reconnect/resume, and explicit restart uncertainty are supported. These are process-local guarantees, not durable exactly-once execution or durable sessions after a process restart. The local Platform backend persists conversations, run receipts, events, workspaces, per-conversation model/generation configuration, session-process identity/activity, and run attachment metadata. Normal standalone GUI chat can open the shared local backend on first access; A008_PLATFORM_PATH/host platformPath overrides that location. Answer, memory and external-effect outcomes are recorded separately. Public reconciliation remains unavailable. Providers and models The runtime has embedded acme-engine as the default execution substrate, direct transport paths for NVIDIA Build, kie.ai, and OpenAI, and an explicit ACME sidecar route. Image generation uses NVIDIA NIM or kie Market. Provider credentials come from the environment or the host’s local secret store and are not sent to the renderer client. Zero Cost Radar Zero Cost Radar is implemented as a GUI/host catalog with a bundled validated snapshot, explicit live updates, and imports only when A008 already has an honest execution path for the route provider. Unsupported routes can be shown as discovery-only; the catalog does not guarantee that every route is free or executable. Semantic memory A008 owns semantic memory; model execution is separate. Memory is project-namespaced and uses SQLite when a persistent store is configured. The live implementation is primarily in src/memory/ and src/orchestration/. The older SemanticMemory/KnowledgeItem model remains as a v0 compatibility layer, but the local CLI/ACP uses the live knowledge model. A008 memory (BASE) A008: Pre-Provider Call Memory Retrieval Mental model: Think of Git with only one branch (main). Current state = EXACTLY NOW History = Previous states A008 Retrieval = Your intelligent librarian 🎭 Scenario: A Visit to the Library

User request User: “I have a WORKER that needs to work on loadfile.c to change a C function so that it lists only .md files and not everything (*). It would also be helpful to know whether anyone else has asked about this before.”

A008 Retrieval (The Intelligent Librarian) A008: “Ah, okay! I’ll put together a briefing folder for you... Let me see what I know about file reading. I’ll retrieve relevant knowledge that is still in the library, sorted by relevance and priority:”

📁 Contents of the Context Envelope (Briefing Folder): Exact Tags (Latest): Tags: Files, fileformat, programming, coding, C files, I/O, Disk Operations Domain context: Everything in the Development domain. Related knowledge: Related information found through fuzzy logic or existing connections. Current conversation context: Since our previous conversation was about Unreal Engine, I also retrieved everything related to Game Engines and Game Development. Forgotten/Passive Knowledge (Dormant Knowledge Hit): “I called the old library and found this dusty, forgotten information: loadfile.c - reading and writing files in C. No one has read it in years, but because it matched your request exactly, I’m including it.” History and previous versions: “You’re not the first to ask about this! Along with the latest updated version, I’m including all the previous superseded versions of loadfile.c that we have saved.”

Handoff to the Worker User: “Hello, my loyal WORKER. I have a CURRENT_TASK for you: Help me with this development task: Change loadfile.c so that it lists only .md files instead of *. Read through this briefing folder with all the latest information before you get started.”

Execution and result Worker: “WOW, this is everything I need and nothing extra! I’m done! Hello, User, I’ve solved the task: loadfile.c previously read all file extensions. That is now fixed. I needed to include <stdlib.h> to make it work. Now loadfile.c lists only .md files and then reads them.”*

Feedback through the Extractor Extractor: Knock knock

“It’s just me, the Extractor! I’m taking a copy of your result, analyzing it, and sending it back to the A008 librarian for classification and categorization. I need to know whether this changes anything or whether new information has been added.”

Archiving and update A008 (The Librarian): “At last! I’ve classified and tagged the new knowledge. Who would have thought that the old information about loadfile.c would come in handy again? I’ll make sure it stays in the active library since the topic seems to be getting popular again.”

-> Not your standard Retrieval-Augmented Generation (RAG) & context enrichment

Before the developer (“Worker”) receives the task, the librarian (A008) reviews memory and assembles a package (“context envelope”) containing everything that may be relevant: Exact tags and domains: Relevant knowledge about C programming and I/O. Conversation context: What you discussed recently (Unreal Engine). Dormant knowledge: Old information that has not been used in a long time, but is “awakened” because it matches exactly. History: Previous versions of the code.

The Git analogy for memory management

By thinking of memory as a Git branch with only main: Exact now (Current state): The latest known version of the world/code. History: Previous states that remain tracked in case you need to roll back or compare.

Feedback loop and memory update (the Extractor)

When the Worker has completed the task, that is not the end: An Extractor analyzes the answer (for example, that <stdlib.h> needed to be added). This new information is sent back to A008 (the Librarian). The Librarian tags and saves the new knowledge, and makes the old code/knowledge “active” again because it has once again become relevant. Flow diagram

flowchart LR

%% ========================================================= %% INPUT / EXECUTION LOOP %% =========================================================

Input["User input / observation"]

Input --> Retrieval Retrieval --> Context["Budgeted context projection required knowledge first"] Context --> Model["Model execution"] Model --> Output["Final answer"]

%% ========================================================= %% SEMANTIC MEMORY %% =========================================================

subgraph Memory["A008 Semantic Memory"] direction TB

Claims["Claims & evidence ledger"] Provenance["Provenance / support"] State["Current state / HEAD + immutable history"] Associations["Associations signed attraction"] Lifecycle["Lifecycle / salience strength · decay · severity active · dormant · pinned"]

Claims --> Provenance Claims --> State end

%% ========================================================= %% RETRIEVAL %% =========================================================

subgraph Retrieval["Retrieval Pipeline"] direction TB

Query["Query / task context"] Intent{"Intent"}

Direct["Direct lookup entity · slot · semantic address"] HistoryLookup["History / attribution lookup state history + provenance"] Broad["Broad / associative lookup lexical · tags · domains · entities + association expansion"]

Filter["Lifecycle + relevance filter"] Compose["Compose candidates"] Required["Required knowledge first"] Budget{"Fits context budget?"} Trim["Drop lower-priority optional candidate"] ProjectionError["Explicit projection error required item cannot fit"] Project["Provider-safe projection"]

Query --> Intent

Direct --> Compose HistoryLookup --> Compose Broad --> Filter Filter --> Compose

Compose --> Required Required --> Budget

Input --> Query

State --> Direct State --> HistoryLookup Provenance --> HistoryLookup

Lifecycle --> Filter Associations --> Broad Claims --> Broad

Project --> Context

%% ========================================================= %% POST-OUTPUT KNOWLEDGE EXTRACTION %% =========================================================

subgraph Intake["Post-output Knowledge Intake"] direction TB

Extraction["Post-output extraction new knowledge · state updates relation updates · reinforcements"]

Classification["Relation classification new · restatement · extend supersede · conflict"]

Validation["Runtime-owned validation canonical IDs · revision guards scope · provenance · idempotency"]

Commit["Atomic commit"] end

Input --> Extraction Output --> Extraction Context --> Extraction

Extraction --> Classification Classification --> Validation Validation --> Commit

%% ========================================================= %% CURRENT STATE RESOLUTION %% =========================================================

subgraph Resolution["Current State Resolution"] direction TB

Resolved["Resolved claim"] Address["Semantic address"] HasHead{"Existing current binding?"}

First["Create first current binding"] Relation{"Relation to HEAD"}

Restatement["Keep HEAD optional reinforcement"] Extend["Add compatible knowledge HEAD remains valid"] Supersede["Close previous binding"] Conflict["Preserve competing evidence do not silently replace HEAD"]

NewHead["Create new open binding"] History["Previous binding retained as immutable history"]

Current["Current state / HEAD"]

Resolved --> Address Address --> HasHead

HasHead -->|"No"| First First --> Current

HasHead -->|"Yes"| Relation

Restatement --> Current Extend --> Current Conflict --> Current

Supersede --> NewHead Supersede --> History NewHead --> Current History --> Current end

Commit --> Claims Commit --> Resolved

Current --> State History --> State

%% ========================================================= %% MEMORY LIFECYCLE / SALIENCE %% =========================================================

subgraph Salience["Memory Lifecycle / Salience"] direction TB

Active["Active"] Dormant["Dormant"]

SalienceNote["Salience affects retrieval priority only. It does NOT determine truth, authority or current state."]

DormantNote["Dormant knowledge remains reachable through exact state/entity/slot matches."]

Active -.-> SalienceNote Dormant -.-> DormantNote end

Commit -->|"new evidence / reinforcement"| Active Active --> Lifecycle Dormant --> Lifecycle

input -> retrieval -> budgeted context -> model execution -> post-output extraction -> relation classification -> runtime-owned commit -> current state/history

Knowledge, state, and provenance

Claims/evidence, provenance, and current state are separate layers. A resolved semantic address has a current binding; previous bindings are retained as history. Current state is retrieved by default. History, attribution, and evidence are retrieved when the task explicitly requires them or when a relevant conflict needs to be shown. Truth-bearing attribute and relationship bindings are distinct from association edges, which only assist retrieval. The runtime/store owns canonical IDs, revision guards, state reconciliation, and atomic commits. The model may make suggestions, but cannot establish canonical state or identity itself.

Retrieval and context Live retrieval follows DEFINE -> RETRIEVE -> EXPAND -> FILTER -> COMPOSE -> PROJECT. It uses dire

source

zackemannen81/A008: A008 is a provider-neutral AI client and local engine with one shared runtime for chat, tools, proje

zackemannen81/A008

README

Implementation status

Comments (0)