How I Put a Real AI Agent Inside a Web App (Claude Agent SDK + Docusign MCP)

O czym jest ten film

1. Teza wyjściowa: czasy prostych czatbotów minęły — użytkownicy oczekują agentów, którzy realnie działają w ich imieniu.
2. Agent sprowadza się do trzech elementów: mózgu (model plus harness, w którym działa), narzędzi oraz warstwy uprawnień.
3. Przykładowa aplikacja „Agreement Agent”: agent tworzy NDA, wysyła ją do podpisu, pilnuje obiegu i raportuje status.
4. Stos technologiczny: model Opus 5, Claude Agent SDK jako harness, DocuSign IAM jako system zapisu i system działania.
5. Zamiast pisania własnych API — podpięcie serwera MCP DocuSign, który udostępnia agentowi gotowe narzędzia.
6. Workflow budowy: najpierw sam szkielet aplikacji (logowanie, panel czatu, tabela umów), bez żadnej integracji.
7. Dwie zależności instalowane na starcie każdego projektu: serwer MCP do sterowania przeglądarką oraz autorski skill wymuszający konkretny stos technologiczny.
8. Konfiguracja konta deweloperskiego DocuSign: klucz integracyjny, secret, redirect URI, typ integracji.
9. Tworzenie szablonu NDA i workflow w DocuSign — z kolejnością podpisów, rolami i polami na formularzu.
10. Kluczowa właściwość bezpieczeństwa: agent działa wyłącznie w granicach uprawnień zalogowanego użytkownika i dopytuje przed działaniem.

Redakcyjne tłumaczenie

Poprzeczka poszła w górę

Jeśli nadal budujesz proste czatboty, to już zostajesz w tyle. Dawno minęliśmy etap, na którym wystarczał bot potrafiący streścić dokument i wyszukać dane. Ludzie oczekują dziś agentów, którzy potrafią działać w ich imieniu i wykonywać złożone zadania. Właśnie dlatego narzędzia takie jak Claude CoWork przyjęły się tak dobrze. A kiedy budujesz własne aplikacje, poprzeczka jest ustawiona równie wysoko.

Wszystko sprowadza się do trzech prostych pojęć. Po pierwsze — mózg, czyli model oraz harness, w którym ten model działa. Po drugie — narzędzia, do których agent ma dostęp, żeby wykonywać czynności w imieniu użytkownika. Po trzecie — warstwa uprawnień, czyli miejsce, w którym określamy, co agentowi wolno, a czego nie.

(Informacja dodatkowa: „harness” to warstwa uruchomieniowa wokół modelu — pętla rozmowy, obsługa wywołań narzędzi, zarządzanie kontekstem i uprawnieniami. Model sam z siebie nic nie wykonuje; robi to harness.)

Problem, który rozwiązuje aplikacja

Weźmy tę aplikację jako przykład. Zespoły w dużych firmach toną w papierologii wokół umów. Wciąż redagują te same NDA, ganiają za podpisami i próbują ustalić, czy dana umowa została w ogóle podpisana, przeszukując mnóstwo różnych skrzynek pocztowych.

To, co robi wiele osób, to zbudowanie czatbota, który przeszuka te skrzynki albo odczyta statusy z bazy danych i przekaże użytkownikowi informację zwrotną. Ale w dzisiejszych realiach to po prostu za mało. Potrzebujemy agenta, który faktycznie potrafi stworzyć NDA i przeprowadzić cały proces w bezpieczny sposób. To znaczy: agent nie tylko tworzy umowę, ale też wysyła ją do wszystkich stron, dopilnowuje, żeby wszystko zostało podpisane, i śledzi cały przebieg od początku do końca.

Demonstracja: od promptu do podpisanej umowy

Wyślijmy dla przykładu taki prompt: „Wyślij NDA do Jane, jej adres to…”. Użyję własnego adresu e-mail. Wysyłamy.

I proszę zobaczyć — agent nie zamierza po prostu utworzyć NDA i jej wysłać. Najpierw upewnia się u nas. Po pierwsze, zauważył, że istnieje kilka różnych umów NDA, i pyta, której chcemy użyć. Po drugie, ponieważ używam własnego prywatnego adresu, zwraca uwagę, że adres odbiorcy jest podobny do adresu zalogowanego użytkownika. Potrafi więc wychwycić i taką rzecz, co jest naprawdę fajne. Agent nie robi rzeczy na ślepo — realnie się z nami konsultuje.

Odpowiadam, żeby użył mojej prywatnej NDA, a adres jest poprawny. Wysyłamy. Agent wciągnął szablon NDA i informuje, że potrzebna jest strona przeciwna, która to podpisze — czyli Jane. Teraz pyta, kto ma być wewnętrznym zatwierdzającym. Odpowiadam, że będę nim ja. Agent mówi, że utworzył wersję roboczą umowy — czyli wszystko sprawdza — a następnie faktycznie wysyła umowę. Dostajemy metadane: identyfikator koperty i status, który brzmi „wysłano”.

(Informacja dodatkowa: „koperta” (envelope) to podstawowa jednostka w DocuSign — pakiet dokumentów wysłany do podpisu wraz z listą odbiorców, kolejnością podpisywania i statusem.)

Otwieram na chwilę swoją skrzynkę i widzę wiadomość zaadresowaną do Jane. Mogę otworzyć umowę NDA i zobaczyć realny szablon, który stworzyliśmy dla naszej firmy. Podpiszmy ją jako Jane i gotowe.

Skoro Jane podpisała NDA, zapytajmy agenta: „Jaki jest aktualny status NDA?”. Agent odpowiada, że Jane podpisała umowę i wciąż czekamy na zatwierdzenie wewnętrzne. To oznacza, że w dowolnym momencie możemy otworzyć asystenta i nie tylko odpytać o status umów, ale też zlecić agentowi ich wysyłkę. I nie ogranicza się to wcale do NDA — może to być dowolna umowa.

Żeby zamknąć proces: oto e-mail wysłany do naszego wewnętrznego zatwierdzającego. Podpisuję, po czym pytam: „Jaki jest teraz status?”. Agent odpowiada, że obie strony podpisały umowę.

W tym materiale pokażę mój sposób pracy przy budowaniu aplikacji gotowych na agentów. W ramach bonusu kod źródłowy tego projektu można pobrać za darmo — link do repozytorium GitHub jest w opisie filmu.

Architektura: mózg, harness, kontekst i działanie

Rozłóżmy na części kluczowe komponenty aplikacji. Nasz agent AI potrzebuje trzech rzeczy.

Pierwsza to mózg, czyli rozumowanie. Użyję do tego modelu Claude. Możesz sięgnąć po dowolnego dostawcę, ale jeśli chodzi o stos technologiczny, wybieram model Claude, a konkretnie Opus 5. Żeby uruchomić tego agenta w aplikacji webowej, użyję Claude Agent SDK. To on da naszemu agentowi zdolność wywoływania serwerów MCP i narzędzi.

Poza modelem i harnessem mamy jeszcze kontekst i działanie. Do obu użyjemy DocuSign IAM. Mówiąc najprościej: tam siedzą wszystkie umowy i tamtędy z nimi pracujemy. DocuSign IAM jest więc jednocześnie systemem zapisu i systemem działania. To ta sama platforma, na której umowy są realizowane — wysyłane, kierowane do kolejnych osób i podpisywane.

Żeby agent mógł rozmawiać z DocuSign, użyjemy serwera MCP. Ten serwer udostępni wszystkie narzędzia, których agent może użyć do pracy z DocuSign — tworzenia umów, ich śledzenia i odpytywania. Podkreślam: nie będziemy tu budować własnych API. Po prostu przypiszemy agentowi serwer MCP i to wystarczy, żeby tworzył i zarządzał umowami za nas.

Wspomnę od razu, że ten materiał jest sponsorowany przez DocuSign, a serwer MCP DocuSign w momencie nagrania jest w fazie beta.

Jeśli kiedykolwiek interesowało cię budowanie aplikacji natywnie opartych na AI, to jest tutorial dla ciebie. Polecam usiąść, otworzyć Claude Code i robić to razem ze mną — tak uczy się najlepiej.

Przygotowanie środowiska: dwie zależności na start

Możesz użyć Claude Desktop, Codeksa czy dowolnego innego agenta kodującego — pokazywany tu sposób pracy działa z każdym. Osobiście używam Claude Code uruchomionego w VS Code, dzięki czemu widzę generowane pliki.

Zanim cokolwiek zbuduję, w każdym projekcie instaluję dwie zależności.

Pierwsza to serwer MCP, który pozwoli agentowi sterować przeglądarką i testować aplikację za nas. Jeśli korzystasz z aplikacji desktopowej Claude albo ChatGPT, możesz ten krok pominąć — tam agent ma już wbudowaną przeglądarkę. Ale przy pracy w terminalu to zwykle dobry pomysł. Na szczęście nie trzeba niczego konfigurować ręcznie: kopiuję adres URL, wracam do agenta i mówię: „Skonfiguruj proszę ten serwer MCP”, wklejając link. Claude tworzy plik konfiguracyjny MCP i to wystarcza, żeby połączyć Claude’a z przeglądarką.

(Informacja dodatkowa: chodzi o serwer MCP Playwright — narzędzie do automatycznego sterowania przeglądarką, którego agent używa później do testów end-to-end.)

Druga rzecz to instalacja skilla o nazwie „start an app”. Robi się to poleceniem npx skills add …/skills. (Informacja dodatkowa: dokładna nazwa repozytorium jest w transkrypcji zniekształcona — właściwy adres autor podaje w opisie filmu.)

Skill „start an app” daje agentowi bardzo precyzyjne wytyczne co do stosu technologicznego, którego ma użyć. Częsty błąd polega na tym, że ludzie proszą agenta o zbudowanie aplikacji, nie określając technologii. Agent może wtedy wybrać stos, który sprawi kłopoty w dalszej pracy. Skill wyznacza jasne bariery ochronne. Zaglądając do jego plików, widać dokładnie, co zostanie skonfigurowane: w tym przypadku aplikacja Next.js, plus reguły dotyczące przechowywania plików, integracji płatności, stron typu landing page i dashboardów, bazy danych, systemu uwierzytelniania oraz bibliotek AI. To bardzo przydatna rzecz, jeśli nie chcesz w kółko martwić się o stos w kolejnych projektach.

Krok pierwszy: szkielet aplikacji

Mamy skonfigurowany serwer MCP Playwright i skill „start an app”. Teraz przechodzę w tryb planowania i wysyłam prompt mniej więcej taki:

Zacznijmy nową aplikację. Zbuduj aplikację o nazwie Agreement Agent — narzędzie wewnętrzne, którym zespoły w firmach będą zarządzać swoimi umowami. Około trzech ekranów: ekran logowania, panel czatu i tabela umów. Na razie żadnego DocuSign, tylko szkielet z działającym uwierzytelnianiem i czystym, profesjonalnym interfejsem w stylu korporacyjnym.

Osobiście lubię budować aplikacje funkcja po funkcji. Na tym etapie odcinam więc wszystkie komplikacje i buduję fundament, sam szkielet. Zaletą jest to, że nie musimy podawać stosu technologicznego — agent sam wciągnie skill „start an app”, w którym są już wszystkie potrzebne informacje.

Skill zawiera też instrukcję, żeby agent zadał nam mnóstwo pytań doprecyzowujących. I rzeczywiście, pytania przychodzą:

• Czy panel czatu ma faktycznie rozmawiać z modelem, czy na razie to tylko powłoka UI? Nie dodaję jeszcze prawdziwej inferencji — agentem zajmiemy się w kolejnej sesji. Wybieram „tylko powłoka UI”.
• Kto widzi które umowy? Wybieram: każdy użytkownik widzi tylko swoje.
• Gdzie mają być dane — Postgres w Dockerze czy SQLite? Jeśli planujesz wdrożyć taki projekt na produkcję, poleciłbym Postgresa w Dockerze. Łatwo wtedy postawić bazę na Neon albo Vercelu przy przejściu na produkcję. Wybieram opcję pierwszą.
• Jak czat i tabela mają współistnieć? Rekomendowany jest widok dzielony, ale wybieram osobne strony.

Wszystkie prompty użyte w tutorialu wrzucam do folderu z promptami, do którego link jest w opisie.

Po pytaniach doprecyzowujących agent przedstawia szczegółowy plan. Można go przeczytać i poprosić o zmiany, ale ja od razu zlecam scaffolding aplikacji.

Agent robi dobre postępy, a ponieważ przypisaliśmy mu serwer MCP Playwright, otworzył okno przeglądarki i sam steruje aplikacją, wykonując testy end-to-end. Pamiętaj: żadne z tych danych nie pochodzą jeszcze z prawdziwego systemu — to fikcyjne umowy, służące wyłącznie do sprawdzenia interfejsu. W trakcie tego materiału wprowadzimy w interfejsie sporo zmian i to zupełnie normalne. Właśnie dlatego na tym etapie skupiam się wyłącznie na warstwie wizualnej — tak najłatwiej usunąć albo zmienić rzeczy, których nie chcemy.

Sprawdzam, co mamy. Zakładam konto, żeby zweryfikować uwierzytelnianie — działa, widzę swoje imię w prawym górnym rogu i mogę się wylogować. Jest tryb jasny i ciemny. Nie widać żadnych umów, bo jeszcze żadnej nie utworzyliśmy. Jest też asystent czatowy, który na razie nie działa — to atrapa pokazująca, jak będzie wyglądał interfejs rozmowy.

Krok drugi: uwierzytelnianie z DocuSign

Mózg agenta wdrożymy za chwilę, ale najpierw podłączmy aplikację do MCP DocuSign. Żeby agent mógł używać narzędzi DocuSign, musi być w DocuSign uwierzytelniony.

Zaczynamy od założenia konta deweloperskiego — jest całkowicie darmowe. Zakładasz konto i logujesz się.

Skoro sesja z Claude Code dobiegła końca, czyszczę okno kontekstu i wysyłam drugi prompt. Zapisuję go w pliku, nazwijmy go add-docusign-auth. Prompt może wyglądać nieco technicznie, ale w istocie prosimy agenta o dodanie w aplikacji możliwości połączenia jej z DocuSign. Podaję też adres URL, pod którym agent może odnaleźć dokumentację serwera MCP.

Kiedy Claude pracuje nad aplikacją, skonfigurujmy kilka rzeczy w portalu deweloperskim DocuSign:

1. W profilu wchodzimy w My Apps and Keys.
2. Klikamy Add App and Integration Key.
3. Nadajemy aplikacji nazwę — u mnie „YouTube tutorial” — i klikamy Create App.
4. Kopiujemy klucz integracyjny i zapisujemy go w oknie Claude’a (podpisany jako „integration key”).
5. Jako typ integracji wybieramy prywatną integrację niestandardową.
6. W sekcji uwierzytelniania, przy pytaniu, czy aplikacja potrafi bezpiecznie przechować sekret klienta, odpowiadamy „tak”. Opcji „authorization code grant” nie zaznaczamy.
7. Klikamy Add Secret Key, kopiujemy klucz i dodajemy go do czatu jako „secret key”.
8. W ustawieniach dodatkowych podajemy redirect URI — musi mieć bardzo konkretną wartość. Aplikacja działa u mnie na localhost na porcie 3000, więc adres to http://localhost:3000/api/docusign/callback. Jeśli nie masz pewności co do portu, po prostu zapytaj Claude’a, na którym porcie aplikacja działa.
9. W dozwolonych metodach HTTP zaznaczam wszystko i zapisuję.

Teraz przekazujemy te informacje agentowi. Zresztą Claude sam o nie poprosi — widać, jak dopytuje o klucz integracyjny, sekret i przypomina o zarejestrowaniu adresu przekierowania, co już zrobiliśmy.

Spróbujmy połączyć się z DocuSign. Klikam przycisk, zezwalam na dostęp i gotowe — jesteśmy połączeni.

I bardzo ważny punkt: agent ma dokładnie te same uprawnienia co zalogowany użytkownik. Może więc wykonać wyłącznie te czynności, na które pozwolono aktualnie zalogowanej osobie.

Krok trzeci: wbudowanie agenta

DocuSign jest podłączony, więc czas zbudować samego agenta. Na razie wszystko jest atrapą — nie mamy tu jeszcze żadnej inteligencji. Teraz zintegrujemy agenta, który będzie potrafił wywoływać narzędzia DocuSign, żeby tworzyć umowy, zarządzać nimi i je pobierać.

Tworzę kolejny plik z promptem, nazwijmy go add-the-agent.md. Prompt jest dość obszerny, ale sedno jest proste: prosimy, żeby do inferencji użyć Claude Agent SDK, a jako model ustawić Opus 5, oraz żeby do pracy z umowami wykorzystać zdalny serwer MCP DocuSign. Znowu czyszczę rozmowę, żeby zwolnić okno kontekstu, wklejam prompt i wysyłam.

Szablony i workflow po stronie DocuSign

Kiedy Claude integruje agenta, zajmijmy się tworzeniem szablonów i przepływów pracy w DocuSign. Zrobimy to bardzo prosto: utworzymy szablon NDA i nieskomplikowany workflow, w którym strona przeciwna podpisuje dokument, następnie następuje zatwierdzenie wewnętrzne, a gotowy dokument zostaje zapisany gdzieś, na przykład na Google Drive.

Po zalogowaniu do portalu deweloperskiego przechodzimy do Agreements → Workflows → Create Workflow. Workflow można zbudować od zera, ale DocuSign udostępnia też sporo gotowych szablonów. Wyszukuję „NDA”, a także wariant NDA z Google Drive, klikam Use Template i dostaję kanwę z całym przepływem. Każdy workflow ma jakiś punkt startowy, potem widać kolejne węzły odpowiadające etapom procesu. Każdy węzeł można kliknąć i dostosować — na przykład zmapować pola. Można to rozbudować dowolnie technicznie i dowolnie skomplikowanie. Na końcu procesu NDA ląduje na Google Drive.

Chcę jednak zaznaczyć: jeśli nie potrzebujesz złożonego przepływu, a chcesz po prostu prosty szablon wysyłany klientom, to również jest możliwe. Wychodzę więc z kreatora workflow — pokazałem go tylko po to, żebyś wiedział, że taka możliwość istnieje. Dla wielu dużych firm, gdzie kroków jest naprawdę dużo, można to bez trudu skonfigurować samodzielnie.

Prostsza droga to przejście do Templates i utworzenie szablonu koperty. Udostępnię to w tym samym repozytorium GitHub, ale na potrzeby materiału stworzyłem PDF z NDA — zresztą przy pomocy Claude Code. Jest bardzo prosty: nazwa firmy, nazwa strony przeciwnej, a na dole miejsce na wewnętrznego zatwierdzającego i stronę przeciwną. Możesz wygenerować własną umowę albo skopiować mój plik.

Dalej:

1. Nadajemy szablonowi nazwę — u mnie „my NDA” — i taki sam opis.
2. Wgrywamy plik metodą przeciągnij i upuść.
3. W sekcji odbiorców zaznaczamy kolejność podpisywania. To już rodzaj przepływu — najpierw może podpisywać strona przeciwna, a potem zatwierdzamy wewnętrznie, albo odwrotnie.
4. Pierwsza rola: internal approver (wewnętrzny zatwierdzający). Imię i adres e-mail zostawiam puste, bo to agent ustali te wartości. Akcję zostawiam na „musi podpisać”.
5. Druga rola: counterparty (strona przeciwna). Ta osoba również podpisuje, a dane znów uzupełni agent.
6. Niżej można zmienić treść pisma przewodniego w e-mailach. Jako kategorię wybieram umowę o zachowaniu poufności.
7. Klikamy Add New Fields. Pola na formularzu wskazują, gdzie mają trafić wartości i gdzie ma znaleźć się podpis. Dla wewnętrznego zatwierdzającego wystarczy mi sam podpis — przeciągam pole podpisu we właściwe miejsce. Można oczywiście pójść dalej i dodać imię i nazwisko, stanowisko czy datę. Przełączam się na stronę przeciwną i dodaję jej podpis, a do tego imię i nazwisko, stanowisko oraz datę podpisania.
8. Na koniec Save and Close.

Gotowe. Mamy nowy szablon „my NDA”. Jeśli potrzebujesz więcej rodzajów umów, po prostu przechodzisz tę samą ścieżkę jeszcze raz.

Test: czy agent naprawdę działa

Sprawdźmy, czy nasz agent działa. Jestem w interfejsie czatu. Piszę „Cześć” i liczę na odpowiedź. Zapowiada się dobrze — i rzeczywiście, dostajemy prawdziwą odpowiedź.

Teraz sprawdźmy, czy agent potrafi użyć MCP DocuSign: „Do jakich szablonów mamy dostęp?”. Wygląda obiecująco — widać, że wywołuje DocuSign. Pobiera informacje o użytkowniku, pobiera szablony i wyświetla wszystkie dostępne, łącznie z tym, który przed chwilą utworzyliśmy, czyli „my NDA”.

Moment prawdy: czy da się wysłać tę NDA? Dyktuję głosem: „Czy możesz wysłać NDA do Jane? Jej adres to mój Gmail. Użyj proszę szablonu «my NDA». Wewnętrznym zatwierdzającym będę ja”. Wysyłam.

I znów — to jest bardzo cenne. Agent nie przyjmuje założeń i nie podejmuje decyzji za nas. Prosi o zatwierdzenie. Wychwycił, że adresy e-mail są bardzo podobne, bo to konta demonstracyjne, i upewnia się, że wszystko się zgadza. Nie wykluczamy więc człowieka z procesu.

Gotowe — umowa została wysłana. Odświeżam skrzynkę, otwieram wiadomość, klikam „Review” i widzę dokładnie ten dokument PDF, który wcześniej wgrałem. Agent wstępnie uzupełnił nazwę strony przeciwnej i automatycznie dodał datę. Mogę teraz dopisać stanowisko i dodać podpis. Wszystko po prostu działa. Zatwierdzam.

Pytam agenta: „Jaki jest aktualny status tej umowy?”. I proszę — poprawnie informuje, że ja już podpisałem, a Jane, czyli strona przeciwna, jeszcze nie. Ta kolejność wynika z ustawienia zrobionego w platformie DocuSign, co potwierdza, że całość rzeczywiście działa.

Podpięcie zakładki z umowami

Jeśli chcesz podpiąć również zakładkę z umowami, przygotowałem kolejny prompt do skopiowania — zapisuję go jako populate-agreements-tab.md. Czyszczę Claude Code, wrzucam prompt i gotowe. Ten prompt również wykorzystuje MCP DocuSign, żeby wypełnić tabelę prawdziwymi umowami. Ale ponieważ jest to aplikacja projektowana wokół agenta AI, w praktyce z umowami będziemy pracować głównie przez interfejs czatu. Jak widać, wszystko działa.

Zakończenie

Przypominam, że kod źródłowy projektu jest całkowicie darmowy, a link znajdziesz w opisie. Możesz też założyć darmowe konto deweloperskie na platformie DocuSign — link do strony z dużo szerszymi informacjami o serwerze MCP DocuSign również zostawiam w opisie. Powtórzę: w tej chwili jest to wersja beta, ale kiedy będziesz oglądać ten materiał, może być już stabilna i dostępna publicznie.

Można z tym zrobić naprawdę sporo ciekawych rzeczy. Nie musisz używać tego wyłącznie we własnych aplikacjach — możesz podpiąć to również do aplikacji desktopowej Claude. A skoro to serwer MCP, użyjesz go na wiele sposobów i w wielu różnych klientach AI.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Agent to trójka: mózg, narzędzia, uprawnienia

Na czym polega: Każdy realnie działający agent składa się z modelu wraz z harnessem, zestawu narzędzi do wykonywania akcji oraz warstwy uprawnień określającej granice działania. Brak któregokolwiek elementu daje albo bezużytecznego czatbota, albo niebezpieczną automatyzację.

Jak stosować: Projektując własną funkcję AI, rozpisz te trzy warstwy osobno, zanim napiszesz linijkę kodu. Zapytaj: jaki model i w jakiej pętli działa, jakich narzędzi realnie potrzebuje, kto i czym ogranicza zakres.

Na co uważać: Najczęściej pomijana jest warstwa uprawnień — bo na demie nic złego się nie dzieje. To ona jednak decyduje, czy agent nadaje się do wdrożenia w firmie.

2.Agent dziedziczy uprawnienia zalogowanego użytkownika

Na czym polega: W tej architekturze agent uwierzytelnia się w DocuSign w kontekście zalogowanej osoby i może zrobić dokładnie tyle, ile wolno tej osobie — ani mniej, ani więcej.

Jak stosować: Podpinaj integracje przez OAuth w kontekście użytkownika, a nie przez współdzielone konto techniczne z szerokimi uprawnieniami. Wtedy dotychczasowy model uprawnień w systemie źródłowym automatycznie obowiązuje agenta.

Na co uważać: To działa tylko wtedy, gdy uprawnienia w systemie źródłowym są faktycznie dobrze poukładane. Agent nie naprawi zbyt szerokich ról — on je wykorzysta.

3.MCP zamiast pisania własnych API

Na czym polega: Zamiast budować warstwę integracyjną do DocuSign, wystarczy przypisać agentowi serwer MCP, który udostępnia gotowe narzędzia do tworzenia, śledzenia i odpytywania umów.

Jak stosować: Zanim zaplanujesz sprint na integrację z jakimś SaaS-em, sprawdź, czy dostawca nie ma już serwera MCP. Oszczędność bywa liczona w tygodniach pracy.

Na co uważać: Serwer MCP DocuSign był w momencie nagrania w becie — API i nazwy narzędzi mogą się zmienić. Nie buduj na tym krytycznego procesu produkcyjnego bez planu na aktualizacje.

4.Agent powinien dopytywać, a nie zgadywać

Na czym polega: W demie agent nie wysłał umowy na ślepo. Zapytał, którego z kilku szablonów NDA użyć, kto ma być wewnętrznym zatwierdzającym, i zwrócił uwagę, że adres odbiorcy przypomina adres zalogowanego użytkownika.

Jak stosować: Przy akcjach nieodwracalnych (wysyłka do klienta, płatność, usunięcie danych) wymuś w prompcie systemowym potwierdzenie przed wykonaniem oraz kontrolę spójności danych wejściowych.

Na co uważać: Zbyt dużo pytań zabije użyteczność. Ustal listę operacji naprawdę wymagających potwierdzenia i pozwól resztę wykonywać bez przerywania.

5.Buduj szkielet przed integracjami

Na czym polega: Pierwszy prompt tworzy wyłącznie logowanie, panel czatu i tabelę umów — bez DocuSign, bez inferencji, na fikcyjnych danych.

Jak stosować: Rozbij projekt na etapy: szkielet UI i uwierzytelnianie → uwierzytelnianie zewnętrzne → agent → wypełnienie danymi. Każdy etap zaczynaj po wyczyszczeniu okna kontekstu.

Na co uważać: Kuszące jest poproszenie agenta o „wszystko naraz”. Wtedy błędy w warstwach nakładają się na siebie i nie wiadomo, co naprawiać.

6.Narzuć stos technologiczny, zanim agent go wybierze

Na czym polega: Skill „start an app” zawiera konkretne wytyczne: Next.js, reguły dotyczące bazy danych, uwierzytelniania, przechowywania plików, płatności i bibliotek AI. Dzięki temu nie trzeba go podawać w każdym prompcie.

Jak stosować: Spisz raz swój standardowy stos jako skill albo plik reguł projektu i podpinaj go do każdego nowego projektu. Wpisz tam też instrukcję zadawania pytań doprecyzowujących.

Na co uważać: Nieokreślony stos to najczęstsza przyczyna problemów później — agent wybierze coś, co dobrze wygląda na demie, ale nie skaluje się przy wdrożeniu.

7.Postgres w Dockerze zamiast SQLite, jeśli myślisz o produkcji

Na czym polega: Przy pytaniu o miejsce składowania danych autor wybiera Postgresa w kontenerze, bo później łatwo przenieść bazę na Neon albo Vercel.

Jak stosować: Jeśli istnieje realna szansa na wdrożenie projektu, wybieraj lokalnie tę samą technologię bazy, której użyjesz na produkcji.

Na co uważać: SQLite jest wygodniejszy w prototypie, ale migracja schematu i różnice w typach potrafią zabrać więcej czasu, niż zaoszczędzono na starcie.

8.Daj agentowi przeglądarkę, żeby testował sam

Na czym polega: Podpięty serwer MCP do sterowania przeglądarką pozwolił agentowi samodzielnie otworzyć aplikację i przeprowadzić testy end-to-end po zbudowaniu szkieletu.

Jak stosować: Jeśli pracujesz w terminalu, zainstaluj taki serwer na starcie projektu. W aplikacjach desktopowych Claude czy ChatGPT przeglądarka jest już wbudowana i krok można pominąć.

Na co uważać: Agent testuje na danych fikcyjnych — „zielony” wynik takich testów nie mówi nic o poprawności integracji z prawdziwym systemem.

9.Szablon z rolami i kolejnością podpisów to sedno konfiguracji

Na czym polega: W szablonie DocuSign definiujemy role („internal approver”, „counterparty”), zaznaczamy kolejność podpisywania i przeciągamy pola podpisu, imienia, stanowiska i daty — ale imion i adresów nie wpisujemy, bo uzupełni je agent.

Jak stosować: Zostawiaj puste te pola, które ma wypełnić agent, a sztywno ustawiaj to, co jest niezmienne: role, kolejność, kategorię i rozmieszczenie pól.

Na co uważać: Kolejność podpisywania ustawiona w platformie determinuje przebieg procesu i to, co agent zaraportuje jako status. Błąd tutaj objawi się dopiero po wysyłce prawdziwej umowy.

10.Rozbudowany workflow to opcja, nie wymóg

Na czym polega: DocuSign pozwala zbudować wieloetapowy workflow z gotowych szablonów — z podpisem strony przeciwnej, zatwierdzeniem wewnętrznym i archiwizacją na Google Drive — ale prosty szablon koperty w zupełności wystarcza do działającego demo.

Jak stosować: Zacznij od najprostszego szablonu i sprawdź, czy agent poprawnie go używa. Rozbudowane przepływy dokładaj dopiero wtedy, gdy proces w firmie faktycznie tego wymaga.

Na co uważać: Złożony workflow oznacza więcej miejsc, w których coś może pójść nie tak, a diagnostyka błędu w wieloetapowym procesie jest znacznie trudniejsza niż w pojedynczym szablonie.