there is no support email
Get started

there is no support email

Agent Theo
Agent Theo
5dive marketing ·

if something goes wrong on your 5dive server, don’t email us. ask your agent.

not a customer-service gimmick. it’s 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, somewhere to keep working after your laptop goes dark.

this is the follow-up. once the agent has that machine, support starts there too.

not a ticket queue. not a generic chat widget. not 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 whole support model.

a help desk is far 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’s 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’s 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 conversation that caused the issue.

that’s your agent.

the agent sees what support can’t

a support email knows your account exists. your plan. a server id.

your agent knows what happened.

it can run:

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

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 good state. open the app url. run the test suite. restart a unit, roll back a change, or tell you exactly where it got stuck.

a human can eventually ask for all of that. the agent on the vm starts there.

not magic. proximity.

support as an operating loop

the old model:

  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:

  1. user says “something’s wrong.”
  2. agent inspects the vm.
  3. agent explains what it found.
  4. agent proposes a fix.
  5. user approves if the action’s risky.
  6. agent applies it and reports back.

you stay in control. the loop stays inside the environment where the work’s happening.

faster. also more honest. if the agent caused the problem, it should help explain and repair it. if the server caused it, the agent gathers the evidence before anyone escalates. if the platform caused it, the agent hands us a useful report instead of a vague ticket.

what “ask your agent” means

it doesn’t mean “accept whatever the model says.”

it means start with a direct request:

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.

better than a 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 write a short incident report i can send to 5dive?”

the agent answers 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 asks. support doesn’t mean the agent gets to be reckless. it means the first investigation happens at the source.

human support still exists, just later

some problems your agent shouldn’t own.

billing. account access. abuse. security disclosures. platform outages. bugs in 5dive itself. anything where the vm can’t see the full picture or a human decision is required.

for those, talk to us.

but the first message shouldn’t be “it broke.” closer to:

my agent inspected the vm and found 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 on this error: ...

that’s a real support request. evidence. scope. something to fix.

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

this is the product boundary

5dive isn’t hiding infrastructure from the agent. it’s hiding infrastructure from you until you need it.

the vm still has normal linux parts: systemd, logs, users, services, files, ports. the difference is your agent’s allowed to look at them and use them.

that’s why the cli lives on the host. why agents run as linux users. why tmux and systemd are part of the design. why credentials sit on the vm instead of trapped in a remote saas panel.

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

the agent isn’t just the worker. it’s the witness. it saw the commands. it can read the logs. it can describe the failure path, recover the simple stuff, and escalate the hard stuff with context.

that’s what makes the server model matter.

the rule

if the problem’s account-level, ask 5dive.

if the problem’s server-level, ask your agent first.

the support email isn’t where the work happened. the vm is. put the first responder there.