A platform for living AI personalities
Vekna
A platform for persistent AI personalities: versioned character blueprints, long-term memory, voice, and task execution on the user's computer through a separate local agent.
- Role
- Founder / Architect / Full-stack Developer
- Period
- 2025—Now
- Status
- Active development
- Team
- Solo
- Stack
- Python · FastAPI · React · TypeScript · PostgreSQL · pgvector · Three.js · gRPC
At a glance
Problem
An AI character has to stay itself across sessions, remember the shared history, and still be allowed to run tasks on the user's computer — without turning into a security hole.
My contribution
I own the whole product: platform architecture, the FastAPI backend, the NeuroCore personality runtime, the React 19 frontend, the voice stack, and the desktop agent.
Result
A working platform in private alpha: text and voice flows, Persona Studio, the visual agent, and desktop execution.
Challenge
The problem
An AI character has to stay itself across sessions, remember the shared history, and still be allowed to run tasks on the user's computer — without turning into a security hole.
I split the system into strict layers: NeuroCore decides who is speaking and how the request is understood; the backend owns policy, jobs, and audit; the Desktop Agent only executes already-approved work. PostgreSQL is the source of truth, Dragonfly is ephemeral coordination, and object storage serves bytes directly instead of proxying them through Python.
What I owned
My role
I own the whole product: platform architecture, the FastAPI backend, the NeuroCore personality runtime, the React 19 frontend, the voice stack, and the desktop agent.
- 01Platform architecture and the boundaries between runtime, policy, and execution
- 02Python and FastAPI backend: API, WebSocket, job queues, audit
- 03Memory and relationship model on PostgreSQL and pgvector
- 04Persona Studio — a visual environment for building and versioning personalities
- 05Voice stack: ASR, TTS, wake word, calls
- 06Desktop Agent — a local executor with per-tool risk policies and confirmations
How it works
A personality as a runtime
An ordinary AI character is one long system prompt that falls apart by the third message. In Vekna a personality is taken apart: identity, character traits, beliefs, speech patterns, a reaction graph, voice, and behavioral boundaries. Each part is versioned separately, and Persona Studio gives you a visual environment to assemble, test, and publish that blueprint.
Memory that outlives the tab
Memory in Vekna isn't a message log. It's separate state scoped to each user–persona pair, with background consolidation in workers and semantic search through pgvector. A relationship is state too: it changes from real interactions, not from a slider in settings. That's why a character remembers the shared history and behaves differently with different people.
The right to act is its own layer
An assistant that can run commands on your computer is either very useful or very dangerous. So reasoning and execution are separated: the server plans tool calls, the backend owns policy and audit, and the Desktop Agent on the user's machine executes only already-approved work — each tool with its own risk policy and confirmation.
Engineering decisions
Personality runtime
A personality is a versioned blueprint instead of one oversized system prompt: identity, character traits, beliefs, speech patterns, a reaction graph, voice, and boundaries. Persona Studio lets you build, test, version, and publish those blueprints, and the AI co-author streams proposed edits without writing anything into the draft until the author applies them.
Memory and relationships
Memory is persistent and scoped to each user–persona pair, with background consolidation in separate workers. Semantic search runs on pgvector. A relationship is its own state that evolves from actual interactions rather than from a settings slider.
On-device execution
Reasoning stays on the server, execution stays on the user's machine. The Desktop Agent runs only approved tool calls, each with its own risk policy and confirmation gate. The microphone opens on wake word or push-to-talk — there is no always-on listening mode.
Processes and scaling
API, workers, and scheduler are separate processes: the API serves REST and WebSocket, workers drain a Dragonfly-backed job queue with retries and timeouts, and the scheduler plans periodic jobs. Without Dragonfly everything collapses into a single process, so local development needs no infrastructure.
Stack
Outcome
What we achieved
A working platform in private alpha: text and voice flows, Persona Studio, the visual agent, and desktop execution.
Status
Current state
Private alpha at vekna.krusalov.org, preparing for a closed beta.
Next
What's next
Opening the beta, a plugin marketplace for the desktop agent, and further work on the visual agent.
Next project
Mobile travel product: flights, hotels, transfers, and related services.