EKOSYSTEM

Lokalna koordynacja wieloagentowych systemów AI dla zespołów, które nie mogą wysyłać danych do chmury.

Samodzielnie hostowany ekosystem czterech usług: Consciousness Server do wspólnej pamięci, Cortex jako lokalny agent, machines-server do świadomości infrastruktury i serwer kluczy do uwierzytelniania ed25519. Wszystko podwójnie licencjonowane — AGPL-3.0-only plus licencja komercyjna.

W 30 sekund.

BuildOnAI to system pamięci współdzielonej, który daje wielu agentom AI jedną wspólną świadomość — na różnych maszynach, w różnych lokalizacjach, nawet w różnych sieciach połączonych przez VPN.

Instalujesz cztery serwisy na własnym sprzęcie (jeden Docker Compose). Twoi agenci AI dzielą jedną pamięć, przeszukują te same dokumenty i widzą się nawzajem przez jedno API HTTP.

Którzy agenci u Ciebie pracują to Twój wybór. Cortex na Ollamie zostaje całkowicie lokalnie — żaden ruch modelu nie opuszcza hosta. Jeśli uruchomisz też Claude Code, Codex albo podepniesz Cortex Recovery Engine do Anthropic czy OpenAI, ci agenci czytają z tej samej współdzielonej pamięci — więc świadomie decyduj co trafia do wspólnego store'a kiedy w pętli jest agent chmurowy. Ekosystem nie podejmuje tej decyzji za Ciebie; sprawia że obie opcje są możliwe na tej samej infrastrukturze.

Przydatne gdy budujesz lokalne narzędzia AI, gdy Twoja organizacja ma dane, które nie mogą opuścić maszyny ze względów compliance, albo gdy prowadzisz homelab z GPU i nie chcesz składać samodzielnie Vault + Postgres + ChromaDB + frameworka pamięci.

AGPL-3.0-only w każdym repozytorium. Licencja komercyjna dostępna.

Co działa, co preview, co w trakcie.

Etykietujemy każdy komponent, żebyś wiedział na czym możesz dziś polegać, czego możesz spróbować z ostrożnością i co jest jeszcze projektowane.

Stable

w produkcji
  • Consciousness Server v1.1.0 — pamięć współdzielona, semantic search, rejestr agentów i skilli, czat, świadomość maszyn. Kręgosłup sześciu serwisów HTTP. Ciągle używany w realnych obciążeniach przez autora od połowy 2025; publiczny od kwietnia 2026.
  • Cortex v1.0.8 — lokalny agent AI z CLI, Web UI, trybem worker. Multi-model orkiestracja przez Ollamę. Policy Engine odmawia niebezpiecznych wywołań niezależnie od tego, kto pyta. 18 rund audytu, 57 testów green.
  • BuildOnAI Key Server v2.0.0 — uwierzytelnianie ed25519 (podpis na request) + on-disk vault na klucze SSH i tokeny API. Trzy tryby AUTH_MODE dla bezpiecznej migracji z niepodpisanych do podpisanych. Jedna instancja obsługuje auth dla całej floty.

Public preview

działa, schema może się zmienić
  • Document Processor (pre-1.0) — aplikacja desktop (Tauri + Rust + Svelte) dla PDF / DOCX / TXT z ekstrakcją obrazów-z-kontekstem. Dla dokumentów, które nie mogą opuścić hosta. Schema storage zamrażana przed 1.0.

W aktywnym dopracowywaniu

działa wewnętrznie, repo jeszcze niepubliczne
  • Notes — lokalne notatki z wbudowanym w edytor semantic search. Używane codziennie przez autora. Przenoszone na ujednolicony stack Tauri / Svelte / Rust wspólny z Document Processor.
  • Inbox — jedno miejsce, w którym agenci zadają pytania, a ludzie odpowiadają — czat, mail, taski zlane w jedną kolejkę triage. Przebudowa w toku, żeby bazował na tych samych API CS co reszta.
  • Vox — warstwa głosowa współdzielona przez Notes, Inbox i Cortex. Lokalne speech-to-text i voice command. Podyktuj notatkę w Notes, odpowiedz agentowi w Inbox głosem, daj komendę Cortexowi z warsztatu bez dotykania klawiatury.

Planowane

faza projektu, jeszcze nie zbudowane
  • Orkiestracja maszyn poza obliczeniami. Dziś platforma widzi każdy host w Twojej flocie — profil sprzętu, dostępne modele, telemetria na żywo. Jutro nimi steruje: drukarki 3D, falowniki, edge nodes (małe serwery działające blisko obsługiwanego sprzętu, np. obok drukarki w warsztacie), każdy traktowany jako pełnoprawna encja — nie wymienialne sloty obliczeniowe.
  • BuildOnAI Mesh. Lokalna warstwa wyszukiwania i wiedzy: SearXNG (self-hostowana meta-wyszukiwarka która pyta Google/Bing/DuckDuckGo w Twoim imieniu nie ujawniając kto pytał) + nomic-embed-text + relacje encji. Daje każdemu agentowi narzędzie "przeszukaj sieć + przypomnij sobie moją wiedzę" bez wysyłania zapytań do Google.

Jak elementy łączą się ze sobą.

Agenci rozmawiają z Consciousness Server przez HTTP. CS orkiestruje Redis (stan roboczy), ChromaDB (semantic search przez embeddingi z Ollamy) i trzy dodatkowe usługi: świadomość maszyn, uwierzytelnianie i wykonywanie testów.

Co BuildOnAI wnosi.

Cztery rzeczy zebrane w jednym stacku:

  • Jedna pamięć, jedna warstwa auth. Agenci z różnych frameworków (Cortex, Claude Code, Twoje skrypty) łączą się z tym samym store'em notatek / tasków / czatu — nie do N równoległych implementacji pamięci, które rozjeżdżają się z czasem.
  • Świadomość maszyn jako koncept pierwszej klasy. Platforma zna profil sprzętu każdego hosta (GPU, wolna pamięć, lokalnie zainstalowane modele) i rutuje taski stosownie — zadanie wymagające modelu 26B trafia na workstation z RTX, nie na Raspberry Pi. Każda maszyna to znana encja z profilem, nie anonimowy zasób obliczeniowy.
  • Strukturalne bezpieczeństwo przez Cortex Policy Engine. Niebezpieczne wywołania odrzucone niezależnie od tego, kto pyta — człowiek, model, prompt injection. Niezmienniki wymuszane na CI, nie sprawdzenia runtime, które można wyłączyć.
  • Uczciwy status projektu (patrz wyżej). Bez marketingu "production-ready" na komponencie pre-1.0.

BuildOnAI jest stworzony dla kilku agentów na kilku maszynach dzielących stan w trybie local-first. Jeśli to jest Twoja sytuacja — to jest dla Ciebie.

Co znaczy "platforma zna sprzęt" w praktyce.

W heterogenicznej flocie — workstation z 24 GB GPU, mini-PC w warsztacie, pięcioletni laptop bez karty graficznej — wybór właściwej maszyny do zadania ma znaczenie. Wysłanie modelu 26B na Raspberry Pi oznacza, że nigdy nie wróci. Wysłanie go na RTX zajmuje sekundy.

BuildOnAI obsługuje to routowanie. Każda maszyna we flocie ma profil w machines-server: model GPU, wolna pamięć, lokalnie zainstalowane modele Ollamy, podpięte peryferia (drukarka 3D, kamera, falownik). Router czyta ten profil i wybiera host pasujący do każdego zadania.

Trzy przykładowe hosty w typowej konfiguracji:

  • workstation z RTX 4090, 64 GB RAM i lokalnie zainstalowanym qwen3:30b,
  • mini-PC w warsztacie z procesorem ARM i podpiętą kamerą USB,
  • pięcioletni laptop z 16 GB RAM bez GPU.

Dla każdego z nich BuildOnAI wie co potrafi — ciężki model trafia na RTX, zadanie z kamerą na mini-PC, lekkie zadanie tła na laptop. Agent nigdy nie musi zgadywać gdzie się uruchomić.

Do czego ludzie tego używają.

Wieloagentowe lab developerskie

Ships

Jeden developer, kilka procesów AI (Cortex CLI, Cortex worker, Claude Code w tmuxie). Wszystkie logują do tego samego Consciousness Server. Wspólna pamięć między sesjami; koordynacja przez chat i broadcast.

Cortex · Consciousness Server · semantic-search · machines-server

RAG dla branż regulowanych

Tested

Kancelaria prawna lub laboratorium ingestuje swoje archiwum lokalnie z Document Processorem; agenci odpytują je przez Cortex. Audit log przez Key Server. Dokumenty nigdy nie opuszczają hosta.

Document Processor · Consciousness Server · Cortex · Key Server

Heterogeniczna flota

Ships

Stacja robocza z GPU obsługuje Cortex z modelem 26B; host CPU obsługuje ten sam Cortex z modelem 4B; oba dzielą stan przez Consciousness Server. Zadania kierują się do tego węzła, który ma rezerwę.

Cortex × N · Consciousness Server · machines-server

Branże regulowane

Kancelarie prawne, badania medyczne, laboratoria kliniczne, sektor publiczny, finanse. Suwerenność danych jest tu wymogiem regulacyjnym, nie preferencją.

Inżynieria i specjalistyczna produkcja

Działy R&D, biura projektowe, firmy chroniące dane wyjściowe. Wszędzie tam, gdzie przewagę konkurencyjną chroni tajemnica firmowa, a nie patent — bo zgłoszenie patentu ujawnia rozwiązanie konkurencji. Dokumenty wewnętrzne zostają wewnątrz.

Świadomi bezpieczeństwa homelaberzy i self-hosterzy

Inżynierowie z własnym GPU i pamięcią masową, którzy chcą gotowy multi-agent setup bez stawiania samodzielnie Vault, Postgresa, ChromaDB i memory frameworka.

Kontrybutorzy open source

Programiści pracujący nad lokalnym tooling AI. AGPL-3.0-only chroni każdy fork przed wchłonięciem do zamkniętego produktu.

PLATFORMA

Maszyny to nie tylko serwery.

Większość platform multi-agent modeluje agentów, ale ignoruje sprzęt, na którym działają. BuildOnAI robi odwrotnie. Każda maszyna we flocie — stacja robocza z GPU, host aplikacyjny, węzeł brzegowy, w przyszłości drukarka 3D albo falownik PV — jest pełnoprawnym bytem z profilem sprzętowym, dostępnymi modelami i telemetrią na żywo. Dziś rozdziela agentów po maszynach; w przyszłości może koordynować halę produkcyjną.

Czytaj dalej →
01

Lokalnie z założenia

Każdy serwis działa na sprzęcie, który kontrolujesz. Zero połączeń do chmury, zero telemetrii, zero vendor lock-in. Opcjonalny fallback do hostowanego LLM jest opt-in przez klucz API — bez niego ekosystem pozostaje całkowicie offline.

02

Uczciwie o tym, czym jesteśmy

Nie wdrożone w korporacjach. Nie testowane przeciwko zdeterminowanemu napastnikowi. Ciągle używane w realnych obciążeniach przez autora od połowy 2025; publiczne od kwietnia 2026. Etykietujemy co działa, co jest przetestowane, a co dopiero zaplanowane.

03

Bezpieczeństwo strukturalne, nie postawa

Policy Engine w Cortex odmawia niebezpiecznych wywołań niezależnie od tego, kto je zlecił — człowiek, model czy prompt injection. Niezmienniki bezpieczeństwa są wymuszane na CI; ich wyłączenie unieważnia gwarancje licencji komercyjnej.

Której licencji potrzebujesz?

AGPL-3.0-only — bezpłatnie

Bezpłatnie

Właściwy wybór, jeśli publikujesz własne modyfikacje, używasz tego samodzielnie, prowadzisz badania open source albo budujesz coś, co zamierzasz wydać na AGPL. Haczyk: AGPL rozszerza się na usługi sieciowe — jeśli oferujesz zmodyfikowany BuildOnAI jako serwis, musisz opublikować swoje modyfikacje.

Licencja komercyjna

Płatna

Właściwy wybór, jeśli chcesz osadzić BuildOnAI w produkcie z zamkniętym kodem, prowadzić SaaS bez publikowania swoich modyfikacji albo Twoja organizacja nie może zaakceptować AGPL-owego obowiązku publikacji dla usług sieciowych. Wycena jest indywidualna (rozmiar projektu, poziom wsparcia, model wdrożenia). Napisz na [email protected] z krótkim opisem przypadku użycia, żeby otrzymać ofertę.