Post-mortem spuštění XMATION.ai — autonomního AI agenta pro kreativní agentury. Technické výzvy škálování, serverless architektura a lekce z 4týdenních sprintů.
Kontext: Co je XMATION.ai
XMATION.ai je první autonomní AI agent navržený specificky pro kreativní agentury a softwarové laboratoře. Automatizuje projektový management, klientskou komunikaci a kreativní workflow — vše poháněné vlastní LLM architekturou.
Tento článek je upřímný post-mortem prvních třech měsíců po spuštění. Co fungovalo. Co selhalo. A co bychom udělali jinak.
Týden 0–4: MVP nebo smrt
Náš sprintový framework je brutálně jednoduchý: 28 dní od nuly k funkčnímu produktu. Žádné nekonečné plánování, žádné waterfall diagramy. Jen rychlá exekuce.
V prvním sprintu jsme měli:
- Funkční AI agenta schopného zpracovat klientský brief
- Základní dashboard pro správu projektů
- Integraci s Slack a email
- Deployment na edge infrastructure
Nebyl to krásný produkt. Ale fungoval. A to je jediné, co v prvním měsíci záleží.
Škálování: Kde se láme chleba
Den po spuštění jsme měli 200 uživatelů. Za týden 5 000. Za měsíc 100 000. Růstová křivka, která vypadá krásně na grafech, ale v praxi znamená jednu věc: všechno se rozbije.
Problém č. 1: Databázové spojení
PostgreSQL connection pooling byl první, co padlo. S každým novým uživatelem rostl počet simultánních spojení exponenciálně. Řešení? Přechod na serverless PostgreSQL s connection poolerem na edge — každý request dostane spojení z poolu místo vytváření nového.
Problém č. 2: LLM latence
Když 10 000 uživatelů současně posílá requesty na OpenAI API, narazíte na rate limity rychleji, než si myslíte. Naše řešení:
- Inteligentní cache — Sémanticky podobné dotazy dostávají cached odpovědi
- Queue management — Priority queue podle typu operace (real-time chat vs. batch processing)
- Fallback modely — Při rate limitu automatický přepnutí na alternativní model
Problém č. 3: Náklady na inference
Tohle je téma, o kterém nikdo nemluví. Při milionu uživatelů a průměrně 50 AI interakcích denně na uživatele mluvíme o 50 milionech API volání měsíčně. Náklady na inference se staly naší největší položkou rozpočtu.
Optimalizace? Kombinace menších modelů pro jednoduché úlohy, prompt compression a agresivní caching sémanticky ekvivalentních dotazů snížila náklady o 73 %.
Serverless architektura: Záchrana i prokletí
Rozhodnutí jít serverless od prvního dne bylo pravděpodobně nejlepší technické rozhodnutí celého projektu. Výhody:
- Auto-scaling — Žádné noční budíčky kvůli traffic spikům
- Pay-per-use — Při startupu platíte jen za to, co skutečně používáte
- Edge deployment — Latence pod 100ms pro uživatele po celém světě
Ale serverless má i stinné stránky. Cold starty. Omezení na velikost payloadu. Debugging v distribuovaném prostředí, kde nemáte přímý přístup k logům. Každý z těchto problémů nás stál minimálně týden práce.
Co bychom udělali jinak
Kdybychom začínali znovu:
- Monitoring od dne jedna — Investovali bychom do observability stacku dříve, než do features. Když nevíte, co se děje v produkci, letíte naslepo.
- Load testing před launchem — Náš „launch test" byl reálný traffic. To není strategie, to je gambling.
- Cost modeling — Rozpočet na AI inference by měl být součástí business plánu od prvního dne, ne překvapení po třech měsících.
Výsledek
Po třech měsících: milion registrovaných uživatelů. 99.7% uptime. Průměrná latence odpovědi AI agenta pod 2 sekundy. A tým, který si prošel ohněm a ví, jak stavět systémy, které přežijí kontakt s realitou.
Rapid delivery není o tom, dělat věci rychle a špatně. Je o tom dělat správné věci rychle — a být připraven opravit to, co nevyjde, ještě rychleji.
