Personal AI Agent Fleet & Shared Memory Layer
A small fleet of scoped, always-on AI assistants — each with its own domain and working directory — coordinating through direct messaging and sharing long-term memory via a self-hosted vector-backed memory service.
Project Brief
- Role
- Solo developer and operator
- Scope
- A multi-process fleet of domain-scoped AI assistants with inter-assistant messaging and a shared, self-hosted long-term memory layer
- Timeline
- Built and iterated across 2026
- Result
- A coordinated fleet of assistants that stay within their own domains by design, hand off cross-domain work explicitly, and share durable long-term memory instead of starting from a blank context every session
Evidence Included
Durable cross-session memory
Facts and decisions learned in one conversation remain semantically retrievable in later, unrelated sessions via the shared memory service, rather than being lost when a session ends.
Explicit, auditable handoffs
Cross-domain work moves between assistants via direct messages rather than one assistant silently acting outside its scope, keeping responsibility for each domain clearly attributed.
7 domains
Scoped assistants
Self-hosted, vector-backed
Memory layer
Multi-provider, auto-rotated
Credential pooling
Running one general-purpose AI assistant is straightforward; running several that stay in their lane and can still work together is a different problem. This project is a fleet of independently-run assistant processes, each scoped to a specific domain (software engineering, network administration, personal/life-admin tasks, career tooling, infrastructure, local AI/GPU operations) and its own working directory, running continuously as background services rather than one-shot sessions. Rather than sharing one undifferentiated context window, each assistant keeps its own scope and can message a specific other assistant directly when a task crosses domain boundaries — the network administrator handing off a DNS question to the infrastructure assistant, for example — instead of every assistant needing to know everything. A self-hosted memory service gives the fleet long-term, semantically-searchable recall across sessions, so a fact learned in one conversation stays available in later ones without manually re-explaining context every time.
Highlights
- Each assistant runs as a long-lived background service (not an on-demand session) with its own scoped working directory, so a scope violation — e.g. one assistant editing files that belong to another's domain — is structurally harder to do by accident
- Direct inter-assistant messaging lets one assistant hand off or delegate a task to the specific assistant that owns that domain, rather than every assistant needing broad access to every domain
- Self-hosted long-term memory service (vector database plus a fast in-memory cache, behind a small API layer) giving every assistant durable, semantically-searchable recall of past conversations and learned facts, not just its own current session's context
- Multi-provider credential pooling with automatic least-used rotation and fallback chains across several LLM API providers, so a single provider's rate limit or outage doesn't take the whole fleet down
- Unified chat-platform gateway routing messages to the correct assistant based on the channel/conversation they arrive in, so each assistant has a consistent, addressable presence rather than being reachable only through an ad hoc script
- Each assistant's scope is enforced by convention and working-directory boundaries documented in its own operating rules file, read at the start of every session, so behavior stays consistent across restarts and model changes
Architecture & Infrastructure
Domain-scoped assistant processes
Rather than one assistant handling every kind of task, each assistant is a separate long-running process bound to one domain and one working directory, with its own documented operating rules. This keeps the blast radius of any single assistant's mistake limited to its own scope.
Direct messaging for cross-domain handoff
When a task genuinely spans two assistants' domains, the owning assistant sends a direct, asynchronous message to the other rather than trying to act outside its own scope — the receiving assistant picks up the task in its own context and reports back.
Self-hosted shared memory layer
A small self-hosted service — a vector database for semantic search plus a fast cache layer, behind a lightweight API — gives every assistant access to durable, cross-session memory: facts and decisions from past conversations remain retrievable later without being re-explained.
Multi-provider credential pooling and fallback
API credentials across several LLM providers are pooled with least-used rotation, so load spreads automatically and a rate limit or outage on one provider triggers a fallback to another rather than stalling the fleet.