NOTATKANOTE · 09.05.2026

Agent w firmie: jak nie zbudować bardzo drogiej zabawkiAn agent at work: how not to build a very expensive toy

Najdroższy agent, jakiego można zbudować, to taki, którego nikt nie używa po trzecim tygodniu. Nie dlatego, że model był zły — dlatego, że nikt nie zaprojektował drogi od demo do codziennej pracy. Oto trzy błędy, które widzimy najczęściej.The most expensive agent you can build is the one nobody uses after week three. Not because the model was bad — because nobody designed the path from demo to daily work. Here are the three mistakes we see most often.

Błąd pierwszy: budowa pod demo, nie pod pracęMistake one: built for the demo, not the workflow

Agent, który robi wrażenie na zarządzie, i agent, z którego zespół korzysta codziennie, to często dwa różne produkty. Jeśli trzeba otworzyć nową aplikację, zapamiętać nowy skrót albo zrobić pięć kliknięć więcej niż wcześniej — ludzie wrócą do starego sposobu, nawet jeśli nowy jest technicznie lepszy.An agent that impresses the board and an agent the team actually uses daily are often two different products. If it means opening a new app, memorizing a new shortcut, or five extra clicks compared to before — people go back to the old way, even if the new one is technically better.

Dlatego wdrożenia, które działają, zaczynają się od pytania „gdzie ludzie już pracują”, nie „jaką aplikację zbudujemy”. Komunikator, CRM, intranet — nie nowe okno do pilnowania.That's why implementations that work start with "where do people already work", not "what app should we build". Chat tool, CRM, intranet — not a new window to babysit.

Błąd drugi: brak właściciela i zasadMistake two: no owner, no rules

Agent, za którego nikt formalnie nie odpowiada po dniu startu, zaczyna się psuć po cichu. Nikt nie poprawia jego błędów, nikt nie aktualizuje zasad, nikt nie decyduje, czego mu wolno, a czego nie. Zaufanie zespołu pęka przy pierwszej widocznej pomyłce — i już nie wraca samo.An agent nobody is formally responsible for after launch day starts breaking down quietly. Nobody fixes its mistakes, nobody updates its rules, nobody decides what it's allowed to do. Team trust breaks at the first visible error — and it doesn't come back on its own.

Błąd trzeci: mierzenie niewłaściwej rzeczyMistake three: measuring the wrong thing

Zespoły często mierzą „czy zbudowaliśmy” (uruchomienie się odbyło) zamiast „czy jest używany” (aktywni użytkownicy tygodniowo, odsetek ukończonych zadań, zaoszczędzony czas). W efekcie porażka jest niewidoczna aż do przeglądu budżetu — a wtedy jest już za późno, żeby coś naprawić tanio.Teams often measure "did we build it" (launch happened) instead of "is it used" (weekly active users, task completion rate, time saved). As a result, failure stays invisible until the budget review — and by then it's too late to fix cheaply.

Co działa w praktyceWhat actually works

Adopcja jako ograniczenie projektowe od dnia pierwszego, nie dodatek na koniec. Jeden formalny właściciel agenta. Pomiar tygodniowy, nie kwartalny. Szkolenia zamiast zakładania, że ludzie sami się domyślą. To dokładnie ta sama warstwa, o której mówimy przy piątym elemencie naszego stosu — bez niej żadna inna warstwa nie pracuje.Adoption as a design constraint from day one, not an afterthought. One formally accountable agent owner. Weekly measurement, not quarterly. Training instead of assuming people will figure it out. This is exactly the layer we talk about as the fifth piece of our stack — without it, none of the other layers do any work.