Models are swappable
A local model, Codex, and Claude Code can all sit behind EVE at different times. None of them own EVE's memory or state.
Personal Project · Extended Virtual Environment
EVE
A persistent, modular AI companion and orchestration platform. EVE owns memory, permissions, and routing; models, agents, integrations, devices, and applications are interchangeable capabilities around it.
What EVE is
EVE (Extended Virtual Environment) is a persistent control plane, not a chat window. It stays running, keeps its own memory of my projects and decisions, and understands what machines and capabilities are available to it — independent of whatever model happens to be answering a given request.
The long-term goal is something closer to a practical, personal assistant: a system I can talk to naturally, that remembers context across sessions, can use tools and physical devices, and can delegate specialized work to the right AI agent for the job — while EVE itself stays in charge of state, permissions, and history.
Natural conversation is the intended interface for that experience, but EVE's usefulness doesn't depend on any single model or on voice being finished. Swap the model out and EVE still remembers everything it owned before the swap.
EVE is not
- Another chatbot with a memory plugin
- An AI coding wrapper with a UI on top
- A hard-coded automation dashboard
- A local LLM with a handful of tools bolted on
The core idea
Everything about EVE's architecture follows from one split.
EVE is persistent. Intelligence and capabilities are modular.
EVE owns
- Identity and conversation state
- Long-term memory
- Project state
- Environments
- Permissions and policies
- Capability discovery
- Task routing
- Execution history
- Approvals
- Machine awareness
- Module lifecycle
- Auditing
Capabilities are modular
Applications, devices, and integrations are installable modules, not logic hard-coded into EVE's core.
EVE is the broker
Agents and modules don't call each other directly. Every delegation flows through EVE, so it stays observable and permissioned.
Humans stay in control
Configurable autonomy levels and approval gates mean installing a module or taking a high-impact action never happens silently.
What interacting with EVE could look like
These illustrate the intended experience, not a finished product. Each one is labeled by how real it is today.
“Hey EVE, make a new Logic Pro project at 120 BPM in B minor.”
EVE discovers that an installed Logic Pro module exposes
logic.project.create and logic.tempo.set,
checks permissions, and invokes them directly — no model
needs to know how Logic Pro works.
“Hey EVE, let's plan a C# Avalonia app that does X.”
EVE enters a planning conversation, remembers the decisions we make, builds a project specification, and eventually delegates implementation to Codex, Claude Code, or a local coding model.
“Hey EVE, what's the temperature in the living room?”
An installed environmental module exposes
temperature.read. EVE finds it, calls it, and answers
— the model is just phrasing a number it didn't have to
produce.
“Hey EVE, what's the last project I worked on?”
This is primarily a query against EVE's own persistent state, not an LLM trying to recall a past conversation. The memory layer this depends on is under active development.
Modular capability architecture
EVE Core doesn't contain integration logic for every application or device. It runs a module runtime instead, and modules declare what they can do.
EVE Core
Module Runtime
Logic Pro module
Git module
ESP32 module
CAD module
future modules…
AI Agents
Codex
Claude Code
Local models
Machines
EVE Server
Windows workstation
MacBook
other machines
Core Systems
Memory
Voice
Projects
Manifest-driven discovery
A developer builds an EVE module — conceptually a C# project implementing the EVE module SDK — packages it, and hands it to EVE. EVE installs it, reads its manifest, and adds its capabilities to the registry. Core code doesn't change.
Core logic never looks like “if the user asks about temperature, call an ESP32.” Instead, EVE determines intent, searches the capability registry, checks permissions and environment constraints, and invokes whatever module or agent actually advertises the matching capability.
Example manifest capabilities
logic.project.create
logic.project.open
logic.project.save
logic.tempo.set
logic.key.set
temperature.read
humidity.read
relay.set
Isolation, not trust by default
Modules are meant to be isolated from EVE Core where practical, so a faulty or malicious module can't crash or compromise the rest of the runtime. Installation and permission grants go through the same approval flow as any other high-impact action.
How a request flows
The path from something I say to work actually getting done and remembered.
- 1User
- 2EVE
- 3Understand intent
- 4Retrieve relevant memory / context
- 5Discover capabilities
- 6Plan
- 7Choose module / agent / machine
- 8Permission / approval check
- 9Execute
- 10Observe result
- 11Update memory / history
Agents and models
EVE is not a local LLM with tools. Models and agents are workers it can call — useful for reasoning, planning, and implementation — not the thing that holds EVE's state.
EVE
Memory / State
Planner / Router
Capability Registry
Permissions
Local model
Low-latency conversation, intent parsing
Codex
Delegated implementation work
Claude Code
Delegated implementation work
Modules
Application & device capabilities
Machines
Where execution actually happens
Local models are intended to eventually handle low-latency conversation, intent interpretation, and lightweight reasoning, while more capable agents get invoked for harder tasks. Routing, state, permissions, capability management, and durable memory stay with EVE regardless of which model is attached.
Machine-aware execution
EVE can operate across multiple machines. A capability can exist on only one of them, and EVE is expected to know which.
EVE Server / Mac
Always-on host
- EVE Core
- Voice
- Memory
- Logic Pro module
- macOS capabilities
Windows workstation
GPU-heavy work
- RTX GPU
- Windows development tools
- CUDA workloads
- Windows-specific modules
MacBook
Mobile / on-the-go
- Development tools
- Mobile development
- Additional capabilities
Environments stay isolated
Personal/home resources and office/work resources don't automatically merge into one unrestricted pool. Each configured environment keeps its own machines, storage, and permissions scoped to itself.
Persistent memory
Memory belongs to EVE, not to whichever model is currently attached. Swapping the model shouldn't mean losing context on a project I started months ago.
“What's the last project I worked on?” is meant to be answered by querying EVE's own state, not by hoping a language model remembers a prior chat session.
What EVE remembers
- Identity and conversation state
- Project history and current state
- Decisions made during planning conversations
- Execution and agent activity history
- Approvals and policy decisions
Safety, permissions, auditability
Extensibility only works if adding a capability can't quietly expand what EVE is allowed to do.
Scoped permissions
Every module and agent capability carries the permissions it needs. EVE checks them before every invocation, not once at install time.
Approval gates
Configurable autonomy levels mean high-impact actions — installing a module, touching real hardware — can require explicit approval.
Module isolation
Modules are meant to run isolated from EVE Core where practical, so one broken or malicious module can't take down the runtime.
Execution history
Every routed request, tool call, and agent action is meant to be logged, so behavior stays auditable after the fact.
Current state vs. future vision
This page describes the target architecture. Here's what's actually true right now.
Today
- Project dashboard and command launcher across machines
- Kicks off builds, deployments, and scripts from one place
- Environment-scoped machines, storage, and permissions
Being built
- Persistent memory architecture
- Capability registry and module runtime
- Planner / router that brokers work to specialized agents
- Git isolation and approval-level policies
Vision
- Voice as a primary interface
- Installable third-party-style modules (Logic Pro, ESP32, CAD)
- Isolated, sandboxed module execution
- EVE helping author and delegate its own new modules
Go deeper
The full specification covers this in detail — memory architecture, agent routing, Git isolation strategy, the planner loop, approval levels, and a complete worked example — across 54 sections with diagrams.
Architecture Specification
Rendered directly from the source Markdown document, unedited, including every diagram and callout.