BranchBot Studio

Inspiration

Most conversational bots are easy to prototype and surprisingly hard to maintain. A small copy change, a new branch, or a second language often means editing code and redeploying. I wanted a non-developer to control the conversation itself.

The included “Cheap Psychologist” is intentionally absurd: it is a memorable demo of a serious tool. The product is BranchBot Studio, a visual builder for versioned AI-assisted conversations across Telegram and the web.

What it does

BranchBot Studio lets an administrator build a conversation as a graph of ordinary blocks:

• bot messages with rich formatting and multiple independently connected buttons;
• text or voice input stored as named variables;
• deterministic conditions;
• a constrained GPT-5.6 AI Router with administrator-defined routes;
• configurable end states and system actions;
• Russian/English content with translation status tracking;
• preview, validation, immutable publishing, version history, and execution logs.

The same graph runs through one channel-independent conversation engine in both Telegram and a public web chat. The model never writes the conversation or chooses arbitrary nodes. It returns only one route key from a strict schema, while every user-facing reply remains under the administrator’s control.

How I built it

I used OpenAI Codex as an engineering collaborator throughout the build: turning the specification into architecture, implementing the Laravel and React application, diagnosing production behavior from logs, adding tests, improving deployment safety, and iterating on the editor from real Telegram tests.

The backend uses Laravel 13, PHP 8.3, PostgreSQL, queues, immutable flow snapshots, and direct integrations with the Telegram Bot API and OpenAI Responses API. The editor is built with React 19, TypeScript, Inertia.js, React Flow, Tailwind CSS, and Vite.

GPT-5.6 powers a narrowly scoped AI Router. The request uses Structured Outputs with an enum generated from the outgoing graph routes. Invalid output, refusals, timeouts, network failures, or a missing API key follow a visible fallback edge instead of breaking the conversation. Voice notes are transcribed before entering the same graph.

Challenges

The hardest part was keeping the visual editor, published snapshots, two delivery channels, localization, and long-running Telegram sessions consistent. A published edit must not alter a conversation already in progress. Every session is therefore pinned to an immutable flow version.

Telegram also introduced practical edge cases around stale inline keyboards, rich messages, callback idempotency, and users sending text while a button is expected. Solving these cases shaped a cleaner separation between graph logic and channel adapters.

Deployment under an existing site subdirectory added another challenge: asset paths, cookies, webhook routing, Apache rewriting, queue workers, and atomic environment updates all had to remain portable. The deployment address and server folder can now be changed without modifying conversation code.

What I learned

The most useful pattern was to keep AI bounded and make the graph observable. AI is valuable for semantic routing, but administrators need deterministic branches, explicit fallbacks, validation, logs, and version history around it. This makes the bot easier to understand, test, and safely change.

What’s next

• reusable flow templates and subflows;
• more trigger and integration blocks;
• collaborative editing and flow diffs;
• analytics for drop-off and route performance;
• additional languages and automated translation review;
• managed deployment for multiple bots from one studio.

Built With

• laravel