Operational control platform for a distributed team — B2B SaaS
The team runs inside a defined corridor of metrics; deviations are raised by the system, not by a manager.
Context
Distributed teams in the up-to-fifty-people range sit in a gap between two classes of tools. Enterprise performance-management systems assume a dedicated HR-ops function and months of rollout. Lightweight task trackers, by contrast, deploy in a day but record only the fact that a task exists — they know nothing about company goals, per-role output norms, or acceptable deviations. As a result, operational control in growing teams lives in the messengers: the daily plan is a chat message, assignments are given by voice on a call, and control is the founder's memory.
This model breaks at the first dozen employees. Assignments from calls never become tasks, tasks are never checked against norms, and the founder learns about a slippage only once it has already become a missed deadline. The problem isn't people's discipline — it's the absence of a circuit that continuously compares actual work against a defined corridor and initiates a response to deviation on its own.
The hard part is that automated control easily turns into a source of noise. An AI agent that indiscriminately spawns tasks from every call clutters the backlog with duplicates and erodes the team's trust in the system faster than it delivers value. The engineering problem is framed more strictly than "wire a model into a tracker": you need a governed agent layer with approval gates, deterministic routing, and a single source of truth about goals.
The task
The client — a B2B team-management platform — arrived with two problems at once. First: build an internal operating circuit where daily plans, call assignments, per-role norms, and founder reporting are unified into one system, and the response to deviations does not depend on a manager's attentiveness. Second: scale a consumer AI product that already makes money — from a Telegram bot to a web platform — and package it to a state an investor can read.
Classic task trackers solve the first problem only halfway. They store tasks but don't set a goal, don't know per-role norms, and can't react to deviations on their own. What was needed was a circuit that doesn't just record work but keeps the team inside a defined corridor: it sets the metrics, tracks the discipline of the day, raises alerts, and rolls the picture up to the founders without manual report assembly.
On the product side the task was applied: remove the payment barrier for the local user, give one-window access to world-class generation models, and build a monetization ladder from a free entry point to subscriptions. A separate requirement was investment packaging — not a static deck but a live financial model in which the investor changes the assumptions and sees the recalculation.
Approach
We built the internal circuit on top of our own Planify platform — a stack of FastAPI, Supabase, and a Telegram bot deployed on Railway. That gave us a ready, production-proven data model for tasks, chats, and calls, onto which the new management logic was layered: not a single entity was created from scratch where a working primitive already existed.
At the foundation we placed an orchestrator core — a single source of truth about where the company is heading. It sets the goal, a set of 8 business metrics, stages, norms, alerts, and the report format. Everything else — the employee workspace, the discipline of the day, the activity tracker, the agent layer — checks against this core rather than living on its own. This order of decision-making rules out the classic disease of automation, where every module grows its own notion of "normal" and the modules start contradicting each other.
The agent layer was designed on the principle of governed autonomy: agents run the routine of the day without manual conducting, but every action that touches the team passes through an explicit human-approval gate. The product circuit was built separately but on the same engineering principles: a thin bot in production as the top of the funnel, a modular architecture for adding new verticals, and a web platform as the primary point of monetization. The song-generation module was built as a drop-in component with clear integration points, not as a separate product.
Architecture
The first layer is the employee workspace /my v2: task descriptions, safe closing, statistics, quick tasks, comments, and a completion report. On top of it runs the discipline of the day: a morning presence check by buttons, a daily plan that automatically becomes tasks, a follow-up on what wasn't done, and an evening report to the founders. New-employee onboarding is framed as an in-bot interview with an AI summary and an alignment check against the orchestrator core — a person enters the system already aligned with company goals rather than discovering them along the way.
The second layer is a suite of AI agents that runs the operational day: request, follow-up, and review of the daily plan; call follow-through; a team control report; and a capstone report to the founders. The layer's key element is the approval gate: the follow-through agent parses call assignments into draft tasks and sends the approver "Assign / Skip" buttons with title-based deduplication. A task reaches the assignee only after human confirmation — the agent prepares the decision but does not make it. This boundary is exactly what separates a governed agent circuit from a noise generator.
The third layer is measurement and observability. The activity auto-tracker (team_activity) counts work by role profiles — dev, infra, designer, trendmaker, smm — with boards and progress bars; input comes both from the bot and from the board, so accounting doesn't demand a separate "report to the system" discipline from the team. Everything rolls up into the founder dashboard /board: team and task statistics, overdue items, "below norm" alerts, drafts awaiting approval, alignment points, plan discipline, and a tracker against norm. The founder sees deviations from the defined corridor, not a feed of events.
The product circuit is a Telegram bot for generating video, images, music, voiceover, speech synthesis, chat, and trends, with local card payments. The "Custom song" module runs on the Suno engine via the kie.ai aggregator: a catalog of 1,104 ready songs, assembled as a matrix of 23 audiences × 16 lyric skeletons × 12 musical spins, plus a Telegram Mini App with order parameters — 16 occasions, 12 genres, 6 moods, 5 vocal types, 3 tempos, 4 languages, and 3 packages of 30 / 60 / 110 credits. Lyric generation runs through OpenRouter with a Gemini fallback, which removes the funnel's dependence on the availability of a single provider.
Result
The internal circuit runs on real traction, not demo data: 174 tasks in development (29 done, 16 in progress), 1,332 messages in the work chat, 16 recorded calls, 147 AI-agent runs, and 127 provider-price snapshots. Call assignments no longer dissolve into the chat — they go through a "draft — approval — assignee" cycle with deduplication, and every assigned task has a human-confirmed origin.
The founders got one screen instead of manually assembling the picture from chats: the /board dashboard shows the team's state against norms, overdue items, and alerts at the moment they arise rather than after the fact. The evening report is generated by the system; the agent's capstone report closes the day without a manager. Operational control stopped scaling linearly with headcount — which was the intended property of the architecture.
The product bot is in production: the user gets world-class generation models in one window and pays with a local card. The subscription ladder is tiered at 500 / 900 / 2,500 / 3,800 / 10,500 ₽ per month, with a credit worth roughly 1 ₽. The song module passed a live generation demo; the mini-app video tutorials were shot in 1080p with ElevenLabs voiceover and Playwright capture composited into a phone frame — material ready for user onboarding.
For investors, a package is prepared: an interactive 8-sheet financial model with live recalculation on Chart.js, a deck, and an audit of 11 competitor bots. The unit-economics reference points — ARPPU, margin, break-even — are parameterized as editable assumptions wired to the same 8 core metrics as the internal circuit: as live data accumulates, the model fills with fact without a rebuild.
Security
During the work we reviewed the platform's database and found a critical problem: Row Level Security was disabled on 103 tables. That meant the anon key could read and write everything — tasks, chats, users, financial data. For a B2B product that stores the operational picture of other people's teams, such a perimeter is unacceptable.
We prepared the remediation: enabling RLS and a set of access policies. We deliberately did not auto-apply it — changes of this class on a live database are rolled out by the owner under supervision, so as not to cut off legitimate application requests. The finding, its impact assessment, and ready-to-run SQL were handed to the client as a priority item in the work plan.
What we built
Orchestrator core
Sets the goal, 8 business metrics, stages, norms, alerts, and report format. The single source of truth the entire internal circuit checks against.
Workspace /my v2 and the discipline of the day
Task descriptions, safe closing, statistics, comments, completion report. Plus a morning presence check, plan-into-tasks, follow-up, and an evening report to founders.
Suite of AI agents
Request, follow-up, and review of the daily plan; call follow-through; a team control report; and a capstone report to founders — 147 runs in production.
Task approval gate
The follow-through agent creates draft tasks from call assignments and sends the approver "Assign / Skip" buttons with title-based deduplication.
Founder dashboard /board
Team and task statistics, overdue items, "below norm" alerts, drafts awaiting approval, alignment points, plan discipline, and a tracker against norm.
Consumer AI bot in production
Video, image, music, voiceover, speech-synthesis, chat, and trends generation with local card payments; freemium moving into packages and subscriptions.
"Custom song" module on Suno
A Telegram Mini App and a catalog of 1,104 songs; ordering by 16 occasions, 12 genres, and three packages via the kie.ai aggregator, lyrics through OpenRouter with a Gemini fallback.
Investment package
An interactive 8-sheet financial model with live recalculation on Chart.js, a deck, and an audit of 11 competitor bots; unit-economics slots wired to the core metrics.
Engineering challenges
Message routing in the bot's DMs
Dialog state was held in global flags without an FSM, and menu-button labels or questions leaked into the daily-plan parser. In versions teamos-1.1 and teamos-1.2 we introduced a menu-label guard, an honest response at zero tasks, a deterministic plan splitter, and a single priority router for incoming messages where a button always wins and an active flow is never interrupted by a new one.
Approving AI tasks without noise
Agents generate tasks from calls, but direct assignment clutters the team and breeds duplicates. We solved it with a gate: the draft goes to the approver with buttons, deduplication is by title, and the assignee gets the task only after confirmation.
A shared financial model with no manual recalculation
An investor needs a live tool, not a static report. We built an interactive 8-sheet financial model recalculated on Chart.js; mixed bar/line datasets required an explicit type on every set, otherwise controller registration failed.
Environment sovereignty of the Suno module
The module requires Python 3.10+ because of type syntax, and the kie Suno API requires a callBackUrl field even in polling mode. The client always sends callBackUrl, retrieves the result by polling record-info, and is resilient to response-field variations; the module itself ships with three clear integration points into the main bot.