The problem
Telegram community owners often manage access, welcome messages, bot settings, broadcasts, schedules, and Premium membership through separate menus and operational steps. The hard part is not adding a chatbot. It is making plain-English control safe enough for real community operations without weakening permissions, confirmations, payment rules, or the buttons people already use.
What existed before Build Week
Accept User was already a live Telegram automation platform. It handled join requests, welcome and captcha flows, managed bots, broadcasts, scheduling, Premium memberships, exact USDT payment verification, Celery jobs, MongoDB, Redis, and Docker-based production deployment. Those deterministic button and worker paths remained the product's source of truth.
What I added during July 13–21
During Build Week I added Luna, a GPT-5.6 action layer that starts the same approved operations from plain English.
Commit 21fdc1a introduced the shared ActionCatalog and ActionCoordinator, strict action schemas, three authorised Luna surfaces, atomic usage quotas, confirmation previews, and focused evaluation coverage. Commit 52a12b9 added native Telegram typing, initial provider-free discovery, safer payment exception review, duplicate-grant prevention, retryable join approval, and stronger deployment process checks.
Commit 2bcc06d completed the next production layer: bounded privacy-safe Redis rollups, functional worker heartbeats, read-only 24-hour and 7-day analytics inside the allowlisted Broadcast Bot, catalog-validated entitlement-aware discovery, and a temporary Thinking. / Thinking.. / Thinking... animation while Luna works.
How Codex accelerated the work
I used Codex as a hands-on engineering partner. We started by auditing every bot surface and tracing where each existing button ended up. Codex helped me extract one shared catalog and coordinator instead of copying business logic into AI handlers, build policy and quota tests, and investigate payment, join, Telegram, and deployment edge cases.
I kept the product decisions: which actions Luna may expose, which writes need confirmation, what data must never reach the model, where the numeric admin allowlist stays authoritative, and which legacy behavior had to be corrected before AI access was safe.
How GPT-5.6 Luna works at runtime
An eligible private Telegram message is projected into a minimal action catalog for that user, bot, role, and entitlement. Luna sends one GPT-5.6 Responses API request with low reasoning, strict structured output, no tools, and store: false.
The application validates the proposal locally against the catalog, actor, target, quota, entitlement, and current state. Read actions can return immediately. Writes produce deterministic previews and reuse the existing confirmation and execution path. Native Telegram typing and the temporary thinking animation run while the turn is processed. Opening Luna discovery makes no provider call and consumes no quota.
Safety and deterministic controls
Luna never receives bot tokens, payment credentials, raw database records, Telegram file IDs, internal IDs, member data, or the operator analytics counts. Buttons still work without OpenAI. The ActionCoordinator remains the execution boundary, Premium is rechecked at execution, destructive and send actions require confirmation, pending actions expire, and replay is blocked. The internal Broadcast Bot stays behind the existing numeric admin allowlist and private-chat check.
The new analytics use fixed aggregate categories and bounded Redis retention. They store no customer, chat, message, transaction, wallet, prompt, or reply identifiers. Counts are rendered locally and never sent back to the model.
Payments remain deterministic. Only exact, confirmed, on-time USDT payments on the configured contract activate automatically. Extra, partial, late, wrong-symbol, or wrong-contract payments go to manual admin review. An admin can grant appropriate non-refundable Premium access through the existing activation path, and duplicate grants are prevented. I did not add refunds or automatic conversion.
Challenges and key decisions
The biggest challenge was preserving one product truth. I did not build a second AI-only business-logic path. Existing buttons and Luna use the same shared actions. Ambiguous requests ask for clarification instead of guessing. Join approval is safely retryable, while deployment now checks both the six important bot and Celery processes and fresh functional heartbeats from the current rollout.
Another important choice was keeping analytics operational rather than invasive. The 24-hour and 7-day views help an allowlisted operator see aggregate Luna, payment, join, delivery, backlog, and heartbeat health without creating customer drill-down or sending private counts to the provider.
Testing and live evaluation
The current full containerised Python suite passed 381 tests, and the focused pre-production key-test list passed 142 tests. Pipeline #2691457908 passed verification and production deployment for commit 2bcc06d. Production health and readiness reported MongoDB, Redis, and required collections ready; all six important processes and the rollout-fresh watcher, sweeper, and Celery heartbeats passed.
The representative Luna evaluator passed 27 of 27 cases across the Main Owner, Managed Owner, and allowlisted Broadcast Bot surfaces, including 23 of 23 exact supported-action selections with zero retries. It classified proposals only and executed no Telegram action or database write.
I also tested the deployed Telegram experience: provider-free discovery, provider-backed owner requests, the temporary thinking animation, and the allowlisted 24-hour and 7-day operator summaries.
Judges can open https://t.me/AcceptUserRequest_bot, send /start, try Show Premium plans, and try Show my AI usage. Internal broadcast actions are intentionally allowlisted and are demonstrated in the video.
What's next
I would let the new rollups build complete seven-day coverage, compare their totals with existing operational evidence, and add cooldown-protected alerts only after real production baselines justify thresholds. I would keep discovery small and catalog-backed, and collect more evidence for rare payment, join, and Telegram failures. The direction stays the same: natural-language convenience on top of deterministic, reviewable operations.
Log in or sign up for Devpost to join the conversation.