# Show HN: Veyra

> Source: <https://github.com/iondodon/veyra>
> Published: 2026-08-19 08:02:41+00:00

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:

``` php
current -> releases/v0
```

Later:

``` php
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:

``` php
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:

``` php
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.