Nex Telegram Orchestrator Pattern

The problem

Running autonomous agents on local hardware often leads to runaway costs, resource exhaustion, or unintended shell access. Most DIY agent setups lack a structured way to maintain state across disconnected Telegram messages or enforce hard safety boundaries on the host system.

What it does

• Generates a complete Telegram orchestrator configuration with strict user ID allowlisting.
• Implements a multi-layer safety cage including command allowlists and forbidden path sandboxing for shell access.
• Provides a JSON-backed task CLI that allows agents to track, snooze, and recur tasks across different conversations.
• Configures hard resource limits for CPU, memory, and subprocesses alongside daily cost and hourly action ceilings.
• Builds a systemd unit for non-root execution, ensuring the agent remains persistent after reboots.

Frameworks & tools

Raspberry Pi (Raspbian), Linux, systemd, Telegram Bot API, OpenAI-compatible APIs (Qwen, Claude, Local LLMs), and TOML configuration.

Why this beats prompting it yourself

Manually prompting for safety often results in soft "system instructions" that an LLM can bypass or ignore. This skill generates a structural security layer at the OS and orchestrator level that enforces limits regardless of the model's reasoning output.

Use cases

• Control a headless Raspberry Pi via Telegram with a private, authenticated bot.
• Run autonomous agents overnight with a guaranteed $5.00 daily spend limit.
• Sandbox an agent so it can run shell scripts without accessing SSH keys or /etc.
• Give a stateless LLM a persistent "memory" of tasks using a CLI-based task manager.

Known limitations

This skill does not harden the underlying host OS or configure firewalls. It is designed for single-operator use cases and is not suitable for public-facing multi-user bots.