Get started

There Is No Support Email

If something goes wrong on your 5dive server, do not email us. Ask your agent.

That is not a customer-service gimmick. It is the point of the product.

In Your Agent Should Have Its Own Server, the argument was that serious agents need a real machine: files, logs, processes, credentials, backups, and a place to keep working after your laptop goes dark.

This is the follow-up: once the agent has that machine, support should start there too.

Not in a ticket queue. Not in a generic chat widget. Not with a stranger asking you to paste logs the agent can already read.

On 5dive, the agent lives on the VM. It can inspect the thing that broke. That changes the support model.

A help desk is far away from the failure

Most software support starts in the worst possible place: outside the system.

Something fails. You leave the product. You open an inbox. You write a summary from memory. Somebody asks for screenshots. Then logs. Then the exact command. Then whether you changed anything. Then they try to reconstruct the failure from the outside.

That loop is slow because everyone is working from copies:

  • copied error messages,
  • copied screenshots,
  • copied shell output,
  • copied context,
  • copied guesses.

The actual machine is sitting there the whole time.

If the problem is on your server, the best first responder is the process that already has a shell, the project files, the logs, the service names, the deploy history, and the recent conversation that caused the issue.

That is your agent.

The agent can see what support cannot

A support email can know your account exists. It can know your plan. It can know a server ID.

Your agent can know what happened.

It can run:

sudo systemctl status 5dive-agent@main
sudo journalctl -u 5dive-agent@main -n 200
sudo 5dive agent stats main --json
sudo 5dive agent logs main --tmux --lines=120

It can check disk, memory, ports, failed services, bad credentials, broken deploys, missing packages, stuck tmux sessions, and whether the last command was just wrong.

It can compare the current repo to the last known working state. It can open the app URL. It can run the test suite. It can restart a unit, roll back a change, or tell you exactly where it got stuck.

A human support agent can eventually ask for all of that. The agent on the VM can start there.

That is not magic. It is proximity.

Support should be an operating loop

The old model is:

  1. User sees problem.
  2. User reports problem.
  3. Support asks for context.
  4. User gathers context.
  5. Support guesses.
  6. User tries the fix.
  7. Repeat.

The 5dive model should be:

  1. User says: “Something is wrong.”
  2. Agent inspects the VM.
  3. Agent explains what it found.
  4. Agent proposes a fix.
  5. User approves if the action is risky.
  6. Agent applies it and reports back.

The human stays in control. The support loop stays inside the environment where the work is happening.

That is faster. It is also more honest. If the agent caused the problem, it should help explain and repair the problem. If the server caused the problem, the agent should gather the evidence before anyone escalates. If the platform caused the problem, the agent should hand us a useful report instead of a vague ticket.

What “ask your agent” means

It does not mean “accept whatever the model says.”

It means start with a direct request like:

Something is wrong with this 5dive server. Inspect the agent status, recent logs,
disk usage, running services, and the last deploy. Explain the likely cause before
changing anything. Ask before restarting services or rolling back.

That prompt is better than a support ticket because it gives the agent a job, a boundary, and a safety rule.

Good first questions are plain:

  • “Why did my agent stop responding?”
  • “Why is my deployed app down?”
  • “Why did pairing with Telegram fail?”
  • “Why is this command asking for auth again?”
  • “What changed on this server today?”
  • “Can you produce a short incident report I can send to 5dive?”

The agent should answer with what it checked, what it found, what it thinks happened, and what it wants to do next.

If it needs to restart a service, rotate a token, delete files, change DNS, or roll back a deploy, it should ask. Support does not mean the agent gets to be reckless. It means the first investigation happens at the source.

Human support still exists, but later

There are problems your agent should not own.

Billing. Account access. Abuse. Security disclosures. Platform outages. Bugs in 5dive itself. Anything where the VM cannot see the full picture or where a human decision is required.

For those, talk to us.

But the first message should not be “it broke.” The first message should be closer to:

My agent inspected the VM and found that 5dive-agent@main has failed three times
since 14:06 UTC after the latest update. Disk is fine, auth is present, and the
tmux scrollback ends after this error: ...

That is a real support request. It has evidence. It has scope. It gives us something to fix.

The agent turns “help” from a blank inbox into a diagnosis.

This is the product boundary

5dive is not trying to hide infrastructure from the agent. We are trying to hide infrastructure from you until you need it.

The VM still has normal Linux parts: systemd, logs, users, services, files, ports, backups. The difference is that your agent is allowed to look at them and use them.

That is why the CLI lives on the host. That is why agents run as Linux users. That is why tmux and systemd are part of the design. That is why credentials are on the VM instead of being trapped in a remote SaaS panel.

If support has to happen, it should happen where the state is.

The agent is not just the worker. It is the witness. It saw the commands. It can read the logs. It can describe the failure path. It can recover simple issues and escalate hard ones with context.

That is what makes the server model matter.

The rule

If the problem is account-level, ask 5dive.

If the problem is server-level, ask your agent first.

The support email is not where the work happened. The VM is. Put the first responder there.