Unified team operating platform: planning, AI agents, execution control

Context

The team-management market is crowded with task trackers, but nearly all of them rest on one assumption: a person will create the card themselves, set the deadline, and keep the status current. In distributed teams, where work is discussed in messengers, on video calls, and over the phone, that assumption fails. The tracker lives apart from the actual work, goes stale within days, and turns from a management tool into an extra chore that everyone quietly sabotages.

The cost of that gap lands on the manager. It is the manager who spends working hours reconstructing the picture: who is doing what, what has stalled, what was decided on a call, and whether the decision reached the person responsible. Management oversight degrades into manually polling chats — an activity that does not scale with the team and leaves no trail for later analysis.

From an engineering standpoint the problem is non-trivial for three reasons. Context sources are heterogeneous and unreliable: group chats with threaded messages and noise, video-call recordings across different services, telephony webhooks with no guaranteed fields. Parsing large volumes of correspondence through reasoning models runs into latency — tens of seconds per batch. And finally, a product serving different teams has to be modular: one team needs CRM and telephony, another only tasks and meetings, and that variability must not spawn branching in the codebase.

The task

We framed the problem as the inverse of a classic tracker: the system must gather context where the team actually communicates and turn it into structure. A Telegram message, a call recording, a manager's live phone call — all of these are sources of tasks, decisions, and minutes. A person only confirms and corrects the parsed result instead of entering data by hand.

The second requirement was controlled modularity. The team owner assembles the interface for their own structure without touching code: enabling CRM and telephony, switching off what they do not need. The product core stays protected — certain modules (dashboard, tasks) cannot be disabled, so the platform never falls apart into inconsistent fragments.

The third requirement came from operations: the system runs on a live team, so any demos, audits, and experiments must be isolated from production data. Demos for external industry prospects, staging for immature modules, browser-based click audits — all of it has to exist alongside production without putting it at risk.

Approach

The bot and the API run in a single process — this simplifies deployment and lets both access a shared data layer without an internal network or inter-service contracts. Multiple Telegram chats bind to one team via the /link command with role-based routing; in a group the bot responds to a mention or a reply, weaving the current team roster and open tasks into its answer — so the dialogue with the system happens in the same chat where the work is.

The AI layer is designed so that heavy operations never block the conversation. Transcription of recordings and queue processing start on a button press or in the background cycle, not at webhook time. Parsing of long conversations is split into chunks of 8 messages and processed in parallel via asyncio.gather — without this, the reasoning model would take tens of seconds per batch and an interactive scenario would be impossible.

Operational discipline is built into the architecture rather than written into process documents. Deploys are automatic from the repository, but guarded against "phantom fixes": service versions are stamped with markers in the routers and verified through _ver endpoints, while diagnostics without log access run through _diag endpoints that immediately report the state of auth, the LLM layer, and a test INSERT. This shrinks the "fix — confirm in production" cycle to minutes and removes any argument about which code version is actually live.

Architecture

The core is FastAPI on top of Supabase (PostgreSQL) and python-telegram-bot. The frontend is deliberately vanilla, with no build step or frameworks: the personal dashboard, team pages, the employee workspace, and AI Team OS are assembled on the client from live data. This choice removes an entire class of build-pipeline problems and makes every screen independently diagnosable; each screen has a demo-mode escape hatch so the interface can be shown without access to the production database.

Modularity is implemented as a "module store" at the data level, not in code: a settings table stores which modules are enabled per team, and a sidebar section is visible only when it is enabled at both the project and the team level. The filter only hides sections; core modules are protected from being switched off. The owner gets a configuration builder without a single line of code on their side — and the engineering team is freed from custom builds for every customer.

External integrations sit behind defensive mappings. Telephony receives auto-dialer results and PBX recordings via webhooks whose fields are not guaranteed in advance, so the entire payload is written to raw jsonb and field mapping runs against a candidate list with deduplication by external id: an event cannot be lost even if the provider changes its format. Transcription of call and video-meeting recordings goes through the Gemini File API, with file size capped by an environment setting.

Data environments are separated honestly, with no conditional logic. Demo teams are created purely as data keyed by team_id — there is not a single "if demo" branch in the code. Staging runs on a separate database — a full replica of the production schema captured by introspection (106 tables) — where the budget module and immature sections are hardened without touching production. This separation made it possible to assemble a complete industry demo for a composite-rebar manufacturer without any code changes.

The AI layer

The daily stand-up closes the morning and evening management loop. In the morning the bot sends inline presence buttons and asks for the day's plan as free text right in Telegram — the AI breaks the text into tasks with priorities and deadlines (in one run, a plan turned into 6 structured tasks). In the evening the system chases anyone who has not reported and compiles a summary for the owner. The manager gets a morning and evening picture of the day without a single manual action.

The suite of control agents runs on scheduled playbooks (manual/hourly/daily/weekly) in a background cycle every 30 minutes. It includes a project-momentum agent, a weekly founders' report, follow-through control that verifies meeting action items became tasks, and an onboarding interview: the bot asks a new employee 4 role-specific questions, and an AI summary checks the answers against the project charter, marking alignment as aligned, partial, or off. Misunderstandings about goals surface in week one, not a quarter later.

The automatic activity tracker removes the friction of work logging: an employee simply messages the bot about what they did, and a parser maps the message onto their role's quota counters — progress shows up on the workspace board without creating tasks. Smart moderation-queue processing, in turn, merges related chat messages into coherent records, cleans duplicates and noise, and pre-assigns owners before the owner confirms — the human is left with the decision, not the routine sorting.

Outcome

The key modules are deployed and verified live: tasks, meetings, telephony, the daily stand-up, control agents, and a control center in the team interface — a summary of presence, active, overdue, and closed tasks, "below quota" alerts, alignment points, and per-member tracker bars. The manager sees the team's operational state on one screen, assembled from data the system gathered on its own.

The quality of the interface layer is confirmed by a formal audit, not self-assessment. AI Team OS (Founder Cockpit) went through a live browser audit via Chrome MCP on demo data: 1225 buttons clicked with zero console errors. For mutations against the real team we adopted a deliberate ban on click tests — only a crawler with mocked writes, or mutation-free rendering — so an audit can never corrupt production data. This is a matter of operating principle: verifiability must not be paid for with production risk.

Environment isolation is proven in practice. The demo for the composite-rebar manufacturer was assembled entirely from data: 16 members, 29 tasks, 16 deals, and 2 CRM pipelines — without a single code change. The Providers module went from 9 to 64 price-covered model groups out of 72 by moving from LLM-driven scraping to a deterministic pipeline over the public JSON API — a telling example of replacing a fragile AI link with an engineered solution where precision matters.

What shipped, in structural terms: a single FastAPI process serving both the Telegram bot and the HTTP API over a 106-table Supabase schema, a module store gating seven product modules, a meetings pipeline from recording import to minutes, telephony intake with defensive field mapping, and a control-agent suite on a 30-minute background cycle. Every layer of that stack runs against a live team — which is the strongest claim a team-operations platform can make about itself.

What we built

• Team layer in Telegram

  Many chats → one team via /link with role-based routing; in a group the bot responds to mentions or replies, weaving in the roster and open tasks.

• Module store

  The owner switches sidebar sections on and off per team. Core modules cannot be disabled; the gate is two-layered — project level and team level.

• Meetings and minutes

  Auto-import of video-call recordings (Telemost via Yandex Disk OAuth, Zoom) → transcription via Gemini → minutes with a summary, decisions, and tasks.

• Telephony

  Auto-dialing with webhook result intake and live-call recording via a PBX; recording transcription, dedup by external id, defensive field mapping.

• Daily stand-up

  Morning presence buttons and a free-text plan → the AI breaks it into tasks with priorities and deadlines; in the evening — chasing stragglers and a summary for the owner.

• Control agents

  Scheduled playbooks and a background cycle every 30 minutes: project momentum, weekly founders' report, follow-through on meeting action items, onboarding interviews.

• AI Team OS (Founder Cockpit)

  Decision Feed, AI Map — a graph linking tasks, deals, and people, an editable permissions matrix, the stand-up, Roadmap, and Launch Board on live data.

Engineering challenges