← Back to Blog

ForChi: A Telegram Agent With Three Jobs

Published: October 2026 | Category: AI Engineering

ForChi Telegram automation agent: three workflows

Most "AI agent" demos are a single task wrapped in a chat window. ForChi is the opposite: one Telegram bot that runs three independent production workflows in parallel, unattended, on free infrastructure. It publishes to two social networks, produces and uploads YouTube videos, and hunts for jobs — all from the same process.

Recorded build session — extending the job-application engine and its Lever/Ashby submission path.

The three workflows

Workflow	What it does	Cadence
Social	Writes and publishes posts to Facebook and LinkedIn	5× per day
Video	Scripts, voices and assembles YouTube uploads	up to 2 per day
Jobs	Scans boards, scores each role against my profile, applies through Lever and Ashby	every 30 minutes

Together those three loops used to eat most of a working day. Running them as one agent cut the manual time I spent on them by roughly 99.9%.

The hard part: deciding when not to act

The failure mode of an always-on agent is not that it is dumb — it is that it is eager. If a casual "hey, how's the job hunt going?" can trigger an application run, the agent is dangerous, and you will spend more time supervising it than doing the work yourself.

So ForChi has a deterministic trigger layer in front of the model:

Regex gate. The message must match an explicit command shape. Ordinary conversation never gets past this point, no matter how it is phrased or how convincing it sounds.
Schema extraction. Once past the gate, a Zod schema validates the extracted parameters — target role, location, posting age, board — before anything executes. A missing or malformed field fails closed.

The rule I apply everywhere now: deterministic code owns the whether, and the model owns the what.

# The shape of the rule, not the actual implementation
if not COMMAND_PATTERN.match(text):     # regex gate
    return reply("I only act on explicit commands.")

params = JobRequest.safe_parse(extract(text))   # Zod-equivalent validation
if not params.success:
    return reply(f"Invalid request: {params.error}")

run_job_workflow(params.data)            # only now does the LLM get involved

The model stack

Judgement calls — matching a posting to my actual experience, writing copy in my voice, picking a video angle — run on Gemini. Gemini's free tier is generous but not guaranteed, so the stack degrades instead of dying: a Qwen2.5-7B model I host on Hugging Face takes over as fallback.

That split matters operationally. The workflows are not allowed to depend on a single provider being up, and the fallback is a model I control, not another company's quota.

Hugging Face carries more than the fallback model. ForChi also uses an image Space for post visuals and two voice Spaces (F5-TTS and Higgs TTS 3) to generate the narration for the video pipeline, so the whole content stack can be rebuilt from components I control.

Running on free tiers without babysitting

ForChi runs on Render and Hugging Face free tiers, which means it has to survive cold starts, sleeping dynos and credential expiry without me noticing. Two decisions carried most of that weight:

Long polling instead of webhooks. No public callback to keep registered, no tunnel to maintain, and the bot recovers on its own after a restart.
A real health endpoint. / returns a cheap status document and /status reports workflow state, so an external keep-alive ping is enough to know the process is alive and to wake it when it is not.

GET https://forchi.onrender.com/
{"status": "healthy", "bot": "ForChi", "mode": "long-polling"}

Scheduling three workflows in one process

Each workflow has its own interval and its own failure blast radius. A YouTube render that takes forty minutes must not block the job scan that runs every thirty, and a failed social post must not take down the scheduler.

Every workflow writes its result, success or failure, so a silent stop is visible.
Retries are bounded and idempotent: an application is never submitted twice for the same role, even if the board returns the listing again.
Configuration lives in the environment, not in code, so a schedule change is a config change.

What I would tell anyone building this

Guardrails before intelligence. Build the gate first. A precise agent that refuses ambiguous input is worth more than a clever one that guesses.
Log the decision, not just the action. When a workflow does not fire, the reason is the most valuable line in the log.
Free tiers are a design constraint, not a hack. If the system has to survive cold starts and quotas, it ends up simpler and cheaper to run than the version that assumes a warm server.

Author: Agu Chiedozie | Cloud & AI Systems Engineer