01 first run
Run it and see an answer
Requirements, install, model setup, the first conversation. The shortest road from zero to a working agent.
Quick startDocumentation
First tell us
what you want to do
The materials are laid out by task, not by area of the code. Below are the entry points, from "install it and get the first answer" to "add my own connector".
The program is distributed under BSL 1.1, the licence terms are published and ready-made releases sit beside them. The repository is closed for now, so the program is inspected by running it: what it does on your machine and where it goes on the network is visible from the program itself.
Entry points
If you want to...
02 platforms
Work out where it installs
Linux, Windows, a server, the browser extension, Android.
Install03 config
Configure the model and channels
Model providers, channel tokens, environment variables, tool restrictions and confirmations.
docs/setting.md
04 internals
Understand how it is built
The agent loop, channels, memory, the scheduler, the policy layer and the local HTTP API. What is Go, what is Python, and why.
docs/arhitektura.md
05 access
Open access to data safely
The full security model: confirmations, the boundary around untrusted data, connector isolation, what stays local and what is transmitted.
docs/bezopasnost.md
06 services
Connect a specific service
The connector catalogue: which tools each one provides, which variables it needs, and where that service loses data silently.
docs/connectors/README.md
07 service
Run it as a permanent service
The systemd unit, a dedicated user, the data directory, the journal, and what to do when a channel dies.
docs/lichnayaObkatka.md
08 skills
Add a skill or a plugin
The plugin manifest, the SKILL.md format, permissions for secrets and network, and the lock file that pins contents.
Skills and plugins09 contribute
Write your own connector
A connector is done when it has discovery, a completeness check, tests against a local server, and its own documentation page.
CONTRIBUTING.md
In brief
How the project is built
A Go core
One binary: the agent loop, channels, memory, the scheduler, the access policy and a local HTTP API. No external dependencies at all - go.mod holds only the module name and the language version. The reason is simple: a client gets it installed on a laptop, not on a cluster.
Python connectors
Ordinary MCP servers over stdio on the standard library. Each one runs and is tested separately and can work in any compatible MCP host. Even if the core has to be replaced, the connectors will outlive the change.
Checks that fail the build
make check-wiringlooks for things that are declared and called by nobody. Over three days of development the same thing happened eleven times: code written, covered by tests, green in CI - and nothing to invoke it.- An architecture guard: files with a legitimate connector call are listed by name.
- The connector registry is reconciled against the directory tree in both directions.
- Tests are discovered by directory rather than listed: two hand-maintained lists diverged, and the tests of two connectors were never running at all.
A soft list that stops nobody gets read exactly once. That is why these checks fail the build instead of printing a warning.
Did not find the answer?
Write what you need to do and we will say whether it exists in the code and where to look.