Your agent already works. Now give it somewhere to stay.

A coding agent normally feels like something you launch. On a machine that stays online, fortytwo keeps identity, memory, time and channels available, so the same kind of agent can behave like a persistent personal assistant.

From a session to a presence.

The agent is the same. What changes is whether anything around it stays up when you walk away.

A session

A coding agent on a laptop

  1. open a terminal
  2. start the agent
  3. work
  4. close the machine
  5. gone until next time
A presence

fortytwo on a host that stays online

fortytwo stays available
  • identity persists
  • memory persists
  • the scheduler keeps time
  • channels stay reachable
  • the agent runtime runs when there is work

24/7 does not mean the model is running 24/7.

It means the assistant infrastructure is available 24/7. The model is invoked when there is a turn to take: a message from you, or a job that is due.

The model doesn’t need to run all day. The assistant needs to still be there when you come back.

Stays available

No model running. No tokens spent.

Channel bridge
Listens for your messages and keeps the chat-to-session mapping.
Scheduler
Keeps time, and claims jobs when they come due.
Memory
A local database the agent can query when it needs to.
Identity
Persona and owner context as plain files in your project.
Session state
Session IDs saved as recovery hints, so a restarted bridge can resume a chat.

Runs when there is work

Inference happens per turn.

Agent turn
Started by a message from you, or by a job that is due.
Oneiros pass
Daily maintenance. A cheap check looks for new memory first; with none, nothing runs.

A live session process can stay resident between messages. It does no inference while idle. Crash recovery is best effort.

One architecture, three places to put it.

These are not different products. They are different hosts for the same stack.

Try it, use it locally

Laptop

Best for trying fortytwo and everyday local use.

The assistant is available while the machine is awake and online.

Nothing to operate: fortytwo start in a terminal.

Reachable around the clock

VPS

A small always-on machine keeps channels, scheduler, state and lifecycle available remotely.

Not required. Use one if you want the assistant reachable while your laptop is closed.

The embedder can run elsewhere: point memory at a remote Ollama URL.

Same model, your hardware

Homelab

The same architecture on infrastructure you control.

Sits next to services you already run. The embedder can be an Ollama in a sibling container or on another host.

You own the machine and the operational boundary.

The same architecture in all three. fortytwo start stays in the foreground on purpose, so systemd or docker compose owns restarts and logs.

Your assistant. Your runtime. Your tools. Your infrastructure.

fortytwo supplies the continuity between them.

What “still there” looks like.

  1. 08:32

    You message the assistant from Telegram.

    The chat’s session resumes, and memory brings back what you told it.

  2. 11:00

    A scheduled job becomes due.

    The scheduler claims it, checks that there is work, and wakes the agent through the runner. The result can be pushed to you.

  3. 14:20

    You open Claude Code in the same project over SSH.

    Same persona files and the same durable memory. It is a different session from your Telegram chat.

  4. 03:17UTC

    Oneiros, the daily maintenance job, comes due.

    If memory has new entries, a tool-free pass may add evidence-backed notes to three profile sections. Otherwise nothing runs.

An illustrative day. Times are examples, except Oneiros, whose default schedule is 03:17 UTC.

systemd · excerpt
# the project init was run in
[Service]
WorkingDirectory=/path/to/project
ExecStart=/usr/bin/env npx fortytwo start
Restart=on-failure

Let your supervisor supervise.

fortytwo start runs in the foreground on purpose. It stops its services on SIGTERM, and exits non-zero if one dies, so a restart policy kicks in. The same command works as a docker compose service.

The host needs the runtime installed and signed in as it normally would, and a Telegram bot token if you use the channel.

Next: the trust model →