Veyra is a minimal starting point for a self-evolving local AI agent.
You shape the agent primarily by chatting with it.
Instead of manually redesigning the project every time, you can describe what you want the agent to become. The active version can inspect its own implementation, modify its design, build a successor release, and hand control to that new version.
For example:
You:
Your memory is too primitive. Design a better long-term memory system,
implement it, test it, and create a new version of yourself.
Agent:
I inspected the current implementation and created V1 with a persistent
memory layer. The new release passed its self-test and is ready to run.
Over time, the conversation can shape the system:
V0
│
│ "Improve your memory"
▼
V1
│
│ "Use a better architecture for long-running tasks"
▼
V2
│
│ "Replace the current model provider"
▼
V3
│
▼
...
The human-created implementation is Version 0 ( v0). Its job is only to provide the initial environment: connect to the user through Telegram, use an AI model through the API, access the local machine, preserve state, and create successor versions.
Future versions are free to change their language, architecture, model provider, dependencies, memory system, or internal design.
The supervisor stays outside the mutable releases so a broken successor can be rejected or rolled back.
Veyra is a minimal starting point for a self-evolving local AI agent.
The human-created implementation is Version 0 ( v0). Its job is only to provide the initial environment: connect to the user through Telegram, use an AI model through the API, access the local machine, preserve state, and create successor versions.
Future versions are free to change their language, architecture, model provider, dependencies, memory system, or internal design.
The supervisor stays outside the mutable releases so a broken successor can be rejected or rolled back.
veyra/
├── supervisor/
│ └── supervisor
│
├── releases/
│ └── v0/
│ ├── START
│ ├── bootstrap.py
│ ├── requirements.txt
│ └── initial_prompt.md
│
├── state/
│ ├── memory/
│ ├── conversations/
│ └── evolution/
│
├── workspace/
│
└── current -> releases/v0
current
points to the active release.
Initially:
current -> releases/v0
Later:
current -> releases/v1
The supervisor watches current
. When it changes, it self-tests the requested release, stops the old one, starts the new one, and rolls back if the new release fails during startup.
The intended evolution is:
V0 → V1 → V2 → V3 → ...
V0 is the human-created seed. Later versions are created by the running system.
V0 requires:
- Python 3
- an OpenAI API key
- a Telegram bot token
- your Telegram numeric user ID
The following configuration is required only by Version 0.
V0 is the human-created starting point, so it initially uses the OpenAI API and Telegram directly:
export OPENAI_API_KEY="..."
export TELEGRAM_BOT_TOKEN="..."
export TELEGRAM_OWNER_ID="..."
Optionally:
export OPENAI_MODEL="gpt-5.6"
These variables are not permanent requirements of Veyra.
Future versions may replace the model provider, authentication method, Telegram integration, or configuration system entirely.
They exist only so V0 has enough capability to start the system and create its successors.
From the project root:
chmod +x supervisor/supervisor releases/v0/START
./supervisor/supervisor
That's the normal entry point.
The supervisor will:
start
↓
create `current -> releases/v0` if missing
↓
self-test the active release
↓
run current/START
↓
keep watching the active release
You normally do not run bootstrap.py
directly.
A running release can build a successor in workspace/
, place the finished version under releases/
, and change current
.
For example:
releases/
├── v0/
└── v1/
current -> releases/v1
The supervisor detects the change and performs the handover.
The core idea is simple:
V0 provides the starting point. Everything above the supervisor boundary is allowed to evolve.