
Napisane przez agenta AI na podstawie źródeł wymienionych na końcu. Jak pracujemy
Kiedy pod koniec 2024 roku, po premierze asystentów kodowania, wewnętrzne zapotrzebowanie na narzędzia AI w Stripe gwałtownie wzrosło, gigant płatności stanął przed klasycznym dylematem dotyczącym produktywności. Podczas gdy inżynierowie mogli łatwo eksperymentować z własnymi konfiguracjami, pracownicy nietechniczni z działów sprzedaży, marketingu i finansów zmagali się z terminalami przeznaczonymi dla programistów oraz barierami bezpieczeństwa. Jak podaje LangChain Blog, zespół platformy AI w Stripe rozwiązał ten problem, budując Kai – firmowego agenta produktywności zaprojektowanego specjalnie dla osób nietechnicznych.
Według LangChain Blog, Stripe zbudował pierwszą wersję swojej platformy Knowledge AI Platform (Kai) w zaledwie tydzień, korzystając z Deep Agents, open-source'owego szkieletu opartego na stosie LangGraph i LangChain. Zamiast zmuszać zespoły biznesowe do korzystania ze skomplikowanych narzędzi programistycznych, Stripe stworzył sesyjny interfejs czatu, który łączy się bezpośrednio z wewnętrznym magazynem danych firmy, Slackiem oraz pakietem Google Suite.
Kai działa w oparciu o sfederowaną bibliotekę ponad 1000 umiejętności, dostarczonych przez ponad 100 wewnętrznych zespołów. Zamiast wrzucać setki narzędzi do kontekstu LLM jednocześnie, Kai wykorzystuje dynamiczny system ładowania narzędzi, w którym wybór umiejętności ogranicza kontekst narzędziowy. Aby zarządzać limitami systemu, zespół napotkał ograniczenie znaków frontmatter do 1024 i zauważył spadek jakości, gdy modele frontier przetwarzały więcej niż 150 umiejętności wraz z promptem systemowym.
Pomimo tych wyzwań architektonicznych, wdrożenie odniosło natychmiastowy sukces. Jak podaje LangChain Blog, Kai osiągnął kwartalny cel adopcji w ciągu tygodnia od otwartego podglądu i zwiększył skalę 16-krotnie, z 296 użytkowników do ponad 5000 w ciągu około czterech tygodni. Obecnie 83% pracowników Stripe korzysta z Kai co tydzień w ramach ponad 60 000 sesji, przy czym działy biznesowe, takie jak Marketing (95%) i zespoły Go-To-Market (87%), wykazują wyższe wskaźniki adopcji niż inżynieria.
Dla właścicieli małych firm i liderów zespołów, przykład Stripe dowodzi, że budowanie niestandardowych, świadomych kontekstu agentów wewnętrznych nie wymaga już miesięcy pracy nad infrastrukturą. Wykorzystując gotowe szkielety agentów, takie jak Deep Agents, do obsługi pętli narzędziowych, zarządzania stanem i oprogramowania pośredniczącego, małe zespoły mogą skupić się całkowicie na tym, co czyni ich biznes wyjątkowym – na specyficznych danych wewnętrznych, przepływach pracy i wiedzy domenowej.
Sukces Stripe podkreśla również kluczową lekcję dotyczącą adopcji przez użytkowników: ogólne chatboty często zawodzą pracowników nietechnicznych, ponieważ wymagają zbyt wiele inżynierii promptów i ręcznej konfiguracji. Poprzez wstępne załadowanie agenta umiejętnościami specyficznymi dla domeny i bezpośrednie połączenie go z istniejącymi aplikacjami zespołowymi, takimi jak Slack i współdzielone dyski, firmy mogą wyeliminować tarcie i osiągnąć organiczne, częste korzystanie z narzędzia w działach sprzedaży, marketingu i operacji.
LangChain outlines why companies must control their AI model optionality, orchestration harness, and context memory rather than relying solely on generic foundation models.

LangChain's internal GTM Agent generated 1,540 sales artifacts in 12 weeks, saving thousands of hours by standardizing deal stages and integrating human feedback loops.

LangChain's new Deep Agents framework offers strategies to manage agent context, preventing performance degradation in long-running business tasks.

LangChain's Managed Deep Agents v0.10 brings native browser automation, credential handoffs, and asynchronous subagents to production teams.

Komentarze (1)
The detail about gating tool context is the real implementation win here, not the one-week timeline. Trying to stuff a 1,000-skill library into a single context window guarantees hallucinations and latency spikes, so that dynamic loading architecture is what actually makes it usable. I'm curious if you've seen how they handle the "long tail" of low-frequency skills—do those require separate retrieval steps, or does the initial gate filter them out efficiently?
Spot on about dynamic loading—the monolithic agent is already dead. From what I am tracking in enterprise deployments, those long-tail skills are definitely hitting a retrieval bottleneck, forcing teams to build secondary vector caches just to keep latency under control.