About DaxBax Neo

DaxBax Neo is a control panel for a team of AI agents running on your own servers. It shows what every agent is doing right now, lets you create or turn off agents, connect services and messengers to them, and assign them scheduled tasks — without logging into each server by hand over SSH.

An agent in Neo is a Claude Code (or Codex) instance running on your own server, shown in Neo as an “employee”: it has a name, a card, its own connections, and — if you turn it on — its own browser and its own topics in Telegram. The agents themselves run on your servers; Neo is how you manage and watch them, not a service that does the work for you somewhere in the cloud.

What it’s made of

Servers — the machines your agents actually run on. You connect a server once, and Neo can then run one or several agents on it.
Agents — individual AI “employees”, each with its own context and connections.
Projects — shared context for several agents at once: who you are, what you do, who your clients are. Any agent attached to a project sees that description in its own instructions.
Integrations — messengers (Telegram, MAX) and your own services (REST API, webhooks, MCP servers) that an agent can use.
Scheduled tasks — what an agent does on a schedule, without you.
Sessions — agents’ live terminals, and their browser sessions when you ask an agent to sign in somewhere under your own account.

Who this documentation is for

People who actually use Neo: setting up servers and agents, connecting services, watching tasks and what agents are doing. This is not an API reference — Neo has no public API for third-party integrations the way an ordinary SaaS product does with a token. Everything is managed through this interface.

Getting Started

The shortest path from signing in to your first working agent.

On the sign-in page you can register with email and password, or sign in through a connected provider (Google, Yandex — what’s available depends on the domain you’re signing in through). Registering gives you your own, isolated workspace right away — your servers, agents and connections aren’t visible to anyone else.

Forgot your password? There’s a “Forgot password?” link on the sign-in page: it emails you a link to set a new one, without needing the old one.

2. Connect a server

Servers → “Add server”. Give it an address, a user, and a sign-in method:

DaxBax Neo key (default) — Neo generates a key for this server and shows you one command to run on the server, adding the key’s public half to authorized_keys.
Your own key — paste an existing private key in full (first and last line included).
Password — Neo signs in once, adds its own key, and uses that from then on; you can keep the password saved if the server refuses key-based sign-in.

The user doesn’t need to be root — passwordless sudo is enough.

3. Create an agent

Agents → “New agent”. Give it a name (the technical name is generated for you) and pick a verified server for it to run on. You can attach it to a project right away, so it gets the team’s shared context, and choose its memory: isolated, or shared with another agent on the same server.

Once created, the agent shows up under Sessions — that’s where you see its live terminal.

4. Connect what you need

Integrations: messengers (Telegram, MAX) and generic options — your own REST API, incoming webhooks, MCP servers. Connect a service once and assign it to the agents that need it.

5. Scheduled tasks, if you need them

Scheduled tasks: what an agent should do on a schedule (cron, every N minutes, or once) and which agents it’s assigned to. Any member of your workspace can manage tasks; only agents with their own persistent Claude session can take them.

From here, read the section for each topic in more depth.

Servers

A server is a machine that actually does the agents’ work. Neo doesn’t store anything on it besides its own SSH key (or certificate) and whatever the connections and agents you set up on it need.

Adding a server

Servers → “Add server” → “Connect a worker node”: address, port, user, and a sign-in method.

Sign-in methods:

DaxBax Neo key (default). Neo generates a dedicated key for this server and shows you a single command to run on it, adding the public half to authorized_keys. From then on Neo signs in only with this key.
Your own key. Paste an existing private key in full (first and last line included). If the key is passphrase-protected, the passphrase is only used once, to read the key, and is never stored — the key itself is kept encrypted, without the passphrase.
Password. By default, the password is used once: Neo signs in, adds its own key to authorized_keys, checks that the key works, and then signs in with the key from then on, forgetting the password. If the server refuses key-based sign-in, you can keep the password saved instead, and Neo will keep using it (including answering sudo prompts).

Neither the key nor the password is ever shown back through the interface — the audit log records the method used, never the secret itself.

The user doesn’t need to be root: passwordless sudo is enough (<user> ALL=(ALL) NOPASSWD:ALL). The “Verify” button refuses the server without it.

Changing the address or user

Changing the host, port, or user requires re-verifying the connection.

One server, several agents

More than one agent can be attached to the same server; they can share it, but each has its own memory — isolated, or shared with one specific other agent on the same server, chosen when the agent is created.

SSH certificates instead of a standing key

Some workspaces have an extra layer of protection turned on: instead of a standing key, Neo signs each connection with a short-lived certificate (valid for about 30 minutes) issued by a separate certificate service. If this is on for your workspace, servers move over to it on their own, in the background, with nothing for you to do — the old key simply stops being used. Settings → “SSH certificates” shows how many servers have already moved over.

Agents

An agent in Neo is a Claude Code (or Codex) instance running on one of your servers, shown in the interface as a separate “employee”: its own name, card, connections and state.

Creating an agent

Agents → “New agent”: a name (any language — the technical name is generated for you) and the server it will run on. You need at least one verified server; if you don’t have one yet, you can add it right from this same screen.

You can also:

attach the agent to a project — it then gets the project’s shared context (who you are, what you do, who your clients are);
give it isolated memory, or share memory with another agent already running on the same server.

Once created, the agent appears right away under Sessions.

The agent’s browser

You can turn on a browser of the agent’s own (agent card → “Browser sessions”). It keeps a persistent profile: a sign-in done once is kept and reused automatically from then on.

If the agent needs to sign in somewhere under your own personal account, it never types the password itself and never asks you for it in chat — it sends a sign-in request, which you see and approve under Sessions (see Sessions).

Telegram topics

Agent card → “Telegram topics”: an agent can run a whole Telegram group through its own topics, each one a separate conversation with its own context — /new in a topic restarts it, closing a topic archives it. All of an agent’s topics share its long-term memory. A group is bound with a code shown on the agent’s card (/bind <code> sent in the group) — a group the bot was simply added to gets nothing until the code is sent. The bot needs to be a group admin, or have privacy mode turned off in @BotFather — otherwise it won’t see messages inside topics.

If Neo is temporarily unreachable

The browser and Telegram topics run on a license that keeps working for up to a week even if Neo doesn’t answer — a short outage on either side won’t turn these features off.

Sessions: watching agents work, and signing in for them

Sessions shows what every agent on all your servers is doing right now.

Live terminal

Every agent has its current working session — what it’s typing and seeing in its own terminal. You can open it, watch it, and type into it yourself if you need to steer or correct the agent on the fly.

Browser sessions

If an agent has its own browser turned on (agent card → “Browser sessions”), this is where its main use shows up: an agent sometimes needs to sign in somewhere under your own personal account — a site that won’t open without a login. When that happens:

the agent sends a sign-in request — you see it right here in Sessions;
you open the agent’s browser from this screen, see the sign-in page, and take control;
you sign in yourself, as usual;
you hand the browser back to the agent.

While you haven’t handed it back, the agent’s commands to the browser wait. The agent itself never sees or remembers the password — it only learns that the sign-in succeeded. The browser profile is kept, so you won’t need to sign in again next time: it’s remembered the same way an ordinary browser remembers a login.

Telegram topics in Sessions

If an agent has Telegram topics turned on, each topic (a separate conversation) shows up here too, with its messages and the “Restart” / “Archive” actions.

Projects

A project is shared context for several agents at once: who you are, where you’re based, what you do, who your clients are. That text becomes part of the working instructions of every agent attached to the project — every “employee” of the project sees it.

Why it’s useful

If several agents are working on the same thing, you don’t have to explain who you are and what your company does to each one separately — you write it once, in the project, and any agent you attach gets that context immediately.

Creating and editing

Projects → “Create project”: a name, and a description of the company and the project. You can see how the card will look in the list (“Project preview”) before saving it.

Changes to the description can be applied to every agent in the project at once.

Attaching an agent to a project

Done when the agent is created (the optional “Project” field) — an agent with no project only works with its own context.

Integrations and connections

Integrations is a catalog of services you can connect, and a list of what’s already connected. A service is connected once, then assigned to whichever agents need it.

Messengers

Telegram and MAX — an agent can either have a dedicated bot of its own (answers only for it, instantly), or a shared bot through a connection that routes messages to the right agent.

Telegram also has topics: an agent runs each topic of a group as its own separate conversation — see Agents for details.

Your own services

If there’s no ready-made card for a service you need, the “Generic” category covers anything else, in three ways:

Your own service (REST API) — base address, sign-in method, a secret, and optionally an OpenAPI address. The agent calls the service itself; the secret never leaves your server.
Incoming events (webhook) — the connection gets its own address, like /api/hooks/<token>, optionally signed with HMAC-SHA256. Every incoming event becomes a message the agent reads and can act on, the same way it would a message in a messenger. Up to 120 events a minute per connection; nothing in an event body is ever executed as a command.
MCP server — Neo adds the server to the agent’s own toolset, without exposing secrets in the open. The agent sees new tools after a restart.

When a catalog entry is renamed or merged

Sometimes one catalog card replaces several older ones (Bitrix24, for example, offers a choice of connection method — webhook or login-and-password). Connections made under the old card move to the new one automatically, keeping their values; the fields for the method you didn’t choose are simply hidden, not required.

Scheduled Tasks

Scheduled tasks is what an agent does on its own, without you: on a cron schedule, every N minutes, or once.

How it works

Neo validates the schedule and hands it to the agent’s own server; from then on the server itself runs it — Neo doesn’t need to be reachable for a task to fire, and a brief Neo outage won’t stop any task. Failed runs are retried, and runs missed during downtime are caught up afterward.

Who can assign tasks

Any member of your workspace can manage tasks, not just the person who created the agent.

Which agents can take tasks

Only agents with their own persistent Claude session — agents that only run through Codex, or through a shared bot with no session of their own, don’t run scheduled tasks.

If the schedule doesn’t match

If Neo sees the server is running a different schedule than the one you set, it sends the right one again (at most once every five minutes) — there’s nothing for you to fix by hand.

Signing In, Signing Out, and Security

Signing in

You can sign in with email and password, or through a connected provider (Google, Yandex — what’s available depends on which domain you’re signing in through). Email registration requires confirming your address: a link is sent to your inbox, and you can’t sign in until you follow it.

Forgot your password

There’s a “Forgot password?” link on the sign-in page. Enter your email: if an account exists for it, you’ll get a link to set a new password. If no account exists for that address, the page answers exactly the same way — that’s deliberate, so the recovery form can’t be used to check whether a given address is registered.

Signing out

Settings → “Sign out” ends your current session. Sign out everywhere ends every one of your sessions at once, including the current one — you’ll need to sign in again. Useful if you’ve signed in from a device you no longer use.

Your workspace

Registering gives you your own, isolated workspace right away — your servers, agents, connections and projects aren’t visible to anyone except the people you’ve invited into it.

Server-connection safety

Servers Neo connects to on your behalf are checked after their name resolves to an address: connections to localhost, private and internal ranges (including cloud metadata addresses) are refused outright, and connection errors are always reported in a generic way, so they can’t be used to probe your internal network.

FAQ

Does Neo have a public API to connect it to our own systems?

No. Neo isn’t a platform with an API for third-party integrations — it’s an interface for managing and watching your own agents. If you need to get data from your own system to an agent, or the other way around, that’s done through Integrations, not by connecting to Neo from the outside: the agent calls your service itself, or your service sends events to the webhook address Neo gives you.

Keyboard shortcuts

DaxBax Neo — Documentation