Architektura agentů
Které kroky model potřebují a které ne. Kde se paralelizuje, kde se vynucuje pořadí, kde se zastavit a zeptat. To obvykle odstraní víc nákladů i rizik než jakákoli změna promptu.
Služba 02
AI agenti pro firmy
Vícekrokové systémy, které skutečně pracují: přečtou CRM, zkontrolují smlouvu, připraví odpověď, založí ticket — uvnitř vašich stávajících nástrojů, s oprávněními a zastavovacími podmínkami, které reálná firma potřebuje.
Agent je model, který umí provádět akce místo toho, aby jen vracel text. V tom je celá myšlenka — a právě zde většina projektů s „agentic AI“ chybuje: agent s přístupem ke všemu a bez hranic dřív nebo později provede něco drahého, trapného nebo nevratného.
Agenty stavím nudnou cestou: úzký rozsah, explicitní nástroje, tvrdé rozpočty, deterministické kroky všude, kde jazykový model není potřeba, a člověk ve smyčce pro vše, co se dotýká peněz, právních závazků nebo zákazníků.
Výstupy
Návrh nástrojů a MCP
Nástroje s typovanými kontrakty, úzkým rozsahem a předvídatelnými chybami. Tam, kde to dává smysl, vystavené agentovi přes MCP, aby stejná schopnost sloužila produktu i interním agentům.
Orchestrace a stav
Odolné provádění: dlouho běžící úkoly přežijí restart, každý krok má checkpoint a nic se neopakuje naslepo. Fronty, limity souběžnosti a idempotence.
Člověk ve smyčce
Fronty ke kontrole, dify přímo v textu, akce schválit/odmítnout, autonomie podle rizika — agent na nízkorizikové práci pouze připravuje návrhy a samostatně jedná jen tam, kde mu to výslovně povolíte.
Guardrails a testování guardrails
Filtrování vstupů a výstupů, obrana proti prompt injection, zpracování PII a adversarial testovací sada, která se spouští při každé změně promptu nebo modelu.
Řízení a auditovatelnost
Úplná trace na každé spuštění: každý prompt, volání nástroje, argument a výsledek. Retence, kterou obhájíte před auditorem, a logy, které váš bezpečnostní tým skutečně může prohledávat.
Jak agenty zavádím
Vyberte jednu úzkou práci
Frontu s měřitelným objemem a jasnou definicí hotova. Pokud nikdo neumí říct, jak vypadá „hotovo“, není to ještě projekt na agenta.
Ověřte to v režimu stínu
Agent běží na reálných datech, ale práci dělá člověk. Číslo o přesnosti dostanete dřív, než to ovlivní zákazníka nebo kolegu.
Připravte návrh, nejednejte
Nasaďte verzi, která vyrábí návrh — odpověď, dif, aktualizaci ticketu — a nechte ho schválit člověkem. Právě tady se hodnota obvykle už ukáže.
Zautomatizujte bezpečné části
Zapněte nehlídané provádění po jednotlivých nástrojích, s limity, a schvalování ponechte u všeho nevratného.
Měřte a rozšiřujte
Sledujte vyřízený objem, kvalitu, náklady a míru eskalace. Rozsah rozšiřujte jen tam, kde jsou čísla nudně dobrá.
Výsledek
- Backlog, který se vyprazdňuje sám, s frontou výjimek místo fronty všeho.
- Každá akce agenta zalogovaná se svými vstupy, takže důvěra je otázkou reportu, ne víry.
- Eskalace k lidem tam, kde je opravdu potřeba úsudek — a nikde jinde.
- Kontrakty nástrojů znovupoužitelné z vašeho produktu, ne zamčené v jednom promptu.
- Jasná odpověď na otázku „můžeme agenta nechat, aby to udělal?“ — s politikou, ne podle pocitu.
Běžný stack
TypeScript · Python · MCP · Anthropic / OpenAI — práce s nástroji · Postgres · Redis fronty · Docker · OpenTelemetry · AWS
Časté dotazy
Čím se liší agent od chatbotu?
Chatbot odpovídá. Agent jedná. Rozdíl je ve vrstvě nástrojů a orchestraci: agent přečte vaše CRM, spustí dotaz, vytvoří záznam a zastaví se v definovaném bodě — s oprávněními, rozpočtem a auditní stopou pro každou akci.
Kolik autonomy je bezpečné?
Tolik, aby to bylo užitečné, a málo na to, aby se to dalo vzít zpět. Mým výchozím nastavením je: pouze návrh u všeho, co zákazník vidí nebo na čem závisí smlouva, nehlídané provádění jen u vratných interních akcí a tvrdé limity na výdaje a počet kroků na spuštění.
Používáte multi-agent systémy?
Jen když je k tomu skutečný důvod — oddělená oprávnění, oddělené rozpočty kontextu nebo skutečně paralelní práce. Většinu firemních problémů s agenty vyřeší lépe jeden dobře vybavený agent s odolnou smyčkou než roj specializovaných.
A co prompt injection?
Přistupuje se k němu jako k první třídní hrozbě, ne k okrajovému případu. Nedůvěryhodný obsah je oddělen od instrukcí, nástroje nesou vlastní rozsahy, výstup se filtruje a v CI běží adversarial testovací sada, která se snaží agenta rozbít dřív než vaši uživatelé.
Na jaké systémy se agenti mohou napojit?
Cokoli, co má API, databázi, webhook nebo MCP server — Salesforce, HubSpot, Dynamics, SAP, Zendesk, Jira, NetSuite, interní služby, S3, e-mail, kalendáře. Většina práce je v kontraktu a oprávněních, ne v připojení.