Stripe is the company I usually hold up as the exemplar of polished internal tools. Hopefully this is taken the right way and I don't want to be negative towards the teams working on this, but I see a distinct lack of polish in these tools and presentations. Some examples:
- Unnecessary AI copy throughout the interfaces like "Browse, discover, and manage skils for your agents", "No favorites yet — hover a card and click the star to pin it here", "One execution environment, shared across agents". These instantly read as AI copy and decrease my enthusiasm.
- Inconsistent, AI-sloppy look-and-feel with different typefaces spattered across the interface.
- The session metrics slide looks busy and AI-generated. It repeats 360,014 sessions in one of the cells at the top, but also has a "360K sessions" in the heading.
I don't know if I'm the only one that notices this stuff, or whether others see it too.
I think there’s been somewhat of a mask-off moment post-AI in which we’ve realized that a lot of the careful and considered output we’ve come to expect of some companies wasn’t out of a respect for the craft or desire to produce “good work”.
Pre-AI the attitude was: if we are going to do something, it is going to use up our precious resources, so we should do it well, because our staff are capable and the marginal cost of doing it well vs. doing it at all is negligible.
Post-AI: we can churn out things quickly, we don’t have to worry about resource allocation, churn churn churn!
Ultimately, it is pragmatic for businesses to behave this way, but it is a shame for those who love the craft. I think we took for granted the beautiful ornate hand carved furniture era of software engineering. We are now in the ikea era.
>> Ultimately, it is pragmatic for businesses to behave this way,
This is how I realized we truly are in an AI arms race. Literally every app or website or tool I use now forcibly pushes their "AI features" or "AI assistant" on you instead of just letting you use their products the way it makes sense for you. Stripe just confirmed what OP was saying. Poorly built, poorly thought out software is now the norm not the exception any more.
> Ultimately, it is pragmatic for businesses to behave this way, but it is a shame for those who love the craft. I think we took for granted the beautiful ornate hand carved furniture era of software engineering. We are now in the ikea era.
I feel this so much. I thought AI would make it easier to get lots of hand-carved ornate furniture; but right now what we are getting looks like the typical Ikea product line -- a bunch of mismatched pieces by a host of different designers with no common underlying design theme or continuity (I'm talking specifically about the looks and design, not the materials).
If Ikea furniture were lopsided, ugly, not-quite-properly functional and traded their minimalist design for a Frankenstein hodgepodge of redundant parts.
I don't think the beautiful ornate hand carved furniture era of software engineering has existed for many decades now.
What's happening right now is more like, we're moving from a hyper-optimized era of just-in-time manufacturing (in software, this is called "Agile", "scrum", "sprints", etc.) to getting our manufacturing outsourced to another country. In software, the "other country" is AI.
Consistently, at scale, and in a durable way: I doubt it. However, I have seen many localized cases of extreme excellence in the places where the company knows it really matters.
I am really interested in this topic, but man I had to give up reading the document because there were too many paragraphs that contained lots of words but no additional detail that I could actually use. It could be AI-generated or human-generated with too many buzzwords. Doesn't really matter, still gave up.
It's not just you. Let's take a small paragraph and break it down.
> Surface-agnostic APIs: Kai ships with an opinionated web application and a Slack integration, but the main primitive is the underlying API that powers them both. The agent is a service, not an application, and surfaces are simply customized views into it.
I...kinda get that they built an API that the agent polls. And then Slack or the webapp both invoke the agent? If so, the above paragraph is obscuring the point. Also, why isn't there a diagram showing it? There is a diagram below showing "Execution Environment" below, but that one doesn't show the API. And Kai and "Stripe Product Agents" are parallel paths on it. Does it not call out to this API anywhere?
I doubt if most people these days actually try to understand any of this, or just go "Agents? Cool! Here's some product that's vaguely similar that I like or have worked on!".
It sure feels like companies have lost their way now. It's no longer about high polish and quality, and all about volume of features. I don't think users want to be overwhelmed with features, they want things that work nicely, and consistently.
Working in b2b SaaS, there’s a real gravity toward checkbox-driven development. Any time we lose a deal because a competitor had feature A, the immediate response is “we need to build feature A.”
And from a sales perspective, that’s probably not wrong.
I think a new (or newly critical) engineering challenge is how to build in a way that keeps a codebase that’s churning out features from crumbling under the weight.
> from a sales perspective, that’s probably not wrong.
Possibly not wrong. One scenario that happens over and over again is that we lose a deal because we didn't have feature A. So we build feature A, and we still don't win deals with it. One way this happens is when the competitor has a focus on one part of the market, and we have a focus on another.
Example: We go after SMB, the competitor owns "The Enterprise." Just building A will never break us into the Enterprise part of the market. We have to build an entire strategy around seizing part of the Enterprise market from our competitor. That strategy may or may not include A, but it is definitely more involved than "Build A and customers will come."
if we aren't going to build an entire strategy around "The Enterprise," not only can building A fail to win the business, it may cost us some of our existing SMB business. Every feature our core market doesn't want or need is additional complexity and feature surface area for our customers to absorb. They stop thinking of our product as "tailored for their needs" as it begins to bloat with features they don't need.
And worst of all, the investment in feature A means some other feature—B—that our existing customers have asked for gets punted down-calendar because we're suddenly tearing up our road map and building A because the VP Sales threw a temper tantrum about being unable to close deals without A. This is another way that chasing feature A means sacrificing value for our existing customers who are asking for feature B.
>> I don't think users want to be overwhelmed with features, they want things that work nicely, and consistently.
In the case of Stripe, users want one thing, which is to receive correct answers to their questions nearly instantly. And from the sounds of it, that is indeed the case.
That's funny, because I recall in 2015 hitting their endpoint for a large-ish customer, and if you added a boolean to get the total result count, it would 500 every time, presumably because it was doing some kind of "SELECT count(1)" over a postgres table. IIRC, Stripe was ruby internally for a long time, no?
Also their documentation was frequently just straight up incorrect (as in the described json schema for a response was violated. keys missing, different field names, etc.).
But it's been over 10 years, has it improved since then? I'm still in my impression of their stack from back then, although they were decently mature by then as well.
I recently had to implement a stripe payment system for a client (having never used it before) and found their documentation to be accurate and excellent (at least for the Java SDK and relatively basic use case).
No love for Stripe but IMO their documentation feels like a first-class product.
I think the specific cases where it failed was when the customer was one of their earlier ones. My guess is that some data schema migration happened, and older data was being served which didn't quite match. So perhaps recency wouldn't potentially even surface those problems either.
Stripe has already existed for a while, and has gone through ups and downs. There was a period where customer experience was first, and the systems inside were built fast and in rather cavalier ways (See Greg Brockman famously telling everyone in a MongoDB convention about using Mongo's oplog as a queue). There were times where internal tools teams could spend all the time they needed to get about as much shine internally as the external facing websites were. Huge investments in everything. But there's just so much churn, as some staff burns out, and others realize that they have so much vested stock that continuing in such a high intensity environment is pointless, that whatever Stripe might have been during your tenure might be very different from other people's, and you can both be right.
I worked at stripe too. Sail design system at time was exemplary. A ton of effort got invested in little details. They spent an insane effort in making ruby fast with their own jit, formatter and type checker they built.
They have published a bunch of stuff about their internal tools in the past. Look up https://stripe.com/blog/stripe-home and compare it to this, as an example.
It's always possible that in reality they were always a bit less polished behind the scenes though.
Maybe they have jobs to do so they offloaded a lot of the presentation work to AI, assuming reasonable people would not judge based on surface level copy style.
The issue is not that that the presentation work has been offloaded to AI. It's that the result is sloppy.
People are always going to judge based on what seems "surface-level". Stuff like legibility also matters just for data comprehension, the AI tic of constantly repeating key numbers all over a presentation or webpage actively hurts legibility.
Very cool demonstration of managed agents built for the needs of their own business.
I think this is where a lot of companies are going to go: on-prem platforms that give various teams access to agents that are as powerful as coding agents, but much more managed and governed.
The readme was very clearly AI-written (or at least heavily AI-assisted)... not saying that's a bad thing, and I agree it's fairly well written... but it is very obviously AI
k, I just looked through it for where the latest is. First of all, the earliest version were fully written by me, and then lightly edited with AI. The current state are as follows: intro sentences written by me, "why lightspeed" section too. Quickstart AI written, Features mostly written by me, but AI keeps interfering there. Design was also written by me several times, it also used to be much longer, but I just noticed AI put one a few paragraph of slop in there, I think that's the most egregious--shame on me for not caching it. So, if I look at the readme right now, I would say it's about 60% me. It can be better, I'll make the effort because it really bothers me if readmes are not (mostly) written by humans.
I really don't have a problem with you using AI, as long as you review and validate/test what it writes, and seems like you did that. Great project btw!
> Building a standalone agent product wouldn't work. Instead, it would force users out of their natural workflows and into a new app.
I am finding the opposite to be true with one of my clients. They explicitly want a new channel. The chat-style UI/UX is vastly preferred over their poorly maintained internal tooling.
I suppose if you are Stripe actual, most things would be well designed and more difficult to abandon. Most places aren't like Stripe.
The hard part is bringing everything that matters to the new channel, but it's certainly feasible to do this. I am doing it right now. We will soon be able to delete hundreds of wildly inconsistent cshtml views and related controllers in favor of a single agent tool that applies json patches. This will easily cover 99.9% of use cases. A manual json editor is retained for the rare case where we need some multi-megabyte merge operation.
I read a buzz word "Knowledge AI Platform" but I did not see any specific feature helpful for knowledge management like verification or transparency. It is more like any generic Agent builder. Maybe it meant to justify building something internally.
I think that’s because none of them go past “I’ve set up agents to be orchestrated this way” and that’s about as impressive as “look at my cloudformation template”.
Ahhh I built an internal set of agents to run our company (finances, all info in the karpathy-style LLMWiki and a database of clients, contracts, billing, time tracking, all managed by MCPs, etc) and it's also called Kai (company name is Kaizen)
Wonderful name. You may know this, but Kai means food in Maori. Many words and many, many place names also embed it, e.g Moana == sea, so Kaimoana is seafood.
I want to read this, but the ever-changing linear gradient of the background is too visually distracting. I tried to get around it by highlighting text I want to read, but since the background is changing underneath it, so is the highlight. My eyes hurt.
Cool to see, but wondering what the upside of this is vs what notion is building with their own agents. I can imagine notion agents can do something very similar to this (and with the same amount of control / security) and at what point would it make sense for a company to build their own vs buying into one..
TIL people still fall for eh I mean use Langchain. Sorry, low value comment; I don’t know how to do that differently; it is such bad garbage since day one and strangely it did not improve. Sorry anyway for the comment, at least it was not LLM generated?
my biggest code smell is debugging. Trying to step through the code is slow because of how much the debugger has to keep track off and it's a lot of step into / jumps until you get to the piece you actually care about. Then you also see stuff like "if langchain_v2: <branch> elif langchain_v3: <branch> else ...." ... breaking changes are ok! I feel like at this point they're hopelessly spaghettied and need a more opinionated approach to clean up a lot of the mess.
Since others are asking: My current goto is pydantic ai and it's been doing pretty well for my use cases.
It (and most other systems) abstract the wrong concepts when you want to create an agent. They promote what was likely never a great strategy but even parsimoniously what are strategies that were good ideas months or a year back.
For example how langchain or whatever else handles subagents and deep research is laughable even today.
So whats the recommendation? Just use pydantic and code everything up yourself. Maybe strands I dont know.
Which specific strategies do you think are outdated, and what would you recommend instead? This sounds more like a criticism of older versions of LangChain than its current APIs. The post also uses deepagents, a separate package in the same ecosystem. Is there something in the current implementation of either that you’re referring to?
The fact that Stripe are touting a production product that (at face value) benefits their business seems to suggest that maybe crap is subjective and as ever, being overly opinionated in an emerging space might actually be a blocking mindset rather than a positive one.
It's a lot of sugar and high level abstractions on top of existing things, I find using the existing things not that complicated or difficult and I struggle to see the value on using the framework as it doesn't sit well with my way of abstracting the stack.
It's very close to the direction we're taking for windmill.dev, we call it "operator builders" rather than focus on "knowledge graph" which the article is very light on details of.
What I'm mostly reading is a developer platform and runtime where users can build agents that can run tools and for that you need a secure code runtime, ACL/permissions, easy way to build apps or what cloudflare OS call gadgets. We're betting on this too at https://github.com/windmill-labs/windmill, very curious to see if that's the future for most enterprise and if a model where everyone vibe-code/fork cloudflare OS to their enterprise need is the future, or a more exhaustive/enterprise platform like ours does.
By choice. I currently work at Stripe (opinions my own, I'm just some guy) and was here when it released. It's a genuinely useful tool, which explains the widespread adoption.
Size and scale, I would think. An out of the box solution probably doesn't quite have the same capabilities as something they can (and now have to) manage in it's entirety.
Stripe probably WANTS to be opinionated about how their company works with the tools.
Somewhat interesting how the design of Stripe's developer-focused landing pages used to be the "cream of the crop," so to speak, but now they just look like Claude run amok. I wonder if the web design "skills" for Claude, and other LLMs, were overly trained on Stripe.
"Sharing the substrate forces discipline and creates a flywheel: improvements to the execution environment benefit both internal and product agents simultaneously."
1. The whole interface feels way too vibe coded with tons of unneeded stuff. Why does it have a console and snake game built in? Why does it have annoying sounds? Why is it full of AI slop writing? The latter is especially confusing because the first person listed under authors is a "Technical Writer". I guess the interface is the general stripe.dev page not exactly related to Kai but the post definitely is pure AI slop writing.
2. It seems to claim things that might not be substantiated like the following: "When Account Executives use Kai, they produce 2x the sales activity, create 17% more opportunities, generate 26% more revenue opportunities, and close 39% more deals when compared to the same sellers in weeks they don't use it." Correlation is not causation. If sales people have less activity (vacations or sick days etc) then they also wont use this tool much, it doesn't mean all the increase in sales is because of the tool.
3. the post talks a lot about how great this tool is but it describes nearly nothing of value to the outsider who can't access it. What were the valuable lessons learned? What's neat about it? There is not much meat imho.
It doesn't live up to my usual expectations from Stripe.
Stripe is the company I usually hold up as the exemplar of polished internal tools. Hopefully this is taken the right way and I don't want to be negative towards the teams working on this, but I see a distinct lack of polish in these tools and presentations. Some examples:
- Unnecessary AI copy throughout the interfaces like "Browse, discover, and manage skils for your agents", "No favorites yet — hover a card and click the star to pin it here", "One execution environment, shared across agents". These instantly read as AI copy and decrease my enthusiasm.
- Inconsistent, AI-sloppy look-and-feel with different typefaces spattered across the interface.
- The session metrics slide looks busy and AI-generated. It repeats 360,014 sessions in one of the cells at the top, but also has a "360K sessions" in the heading.
I don't know if I'm the only one that notices this stuff, or whether others see it too.
I think there’s been somewhat of a mask-off moment post-AI in which we’ve realized that a lot of the careful and considered output we’ve come to expect of some companies wasn’t out of a respect for the craft or desire to produce “good work”.
Pre-AI the attitude was: if we are going to do something, it is going to use up our precious resources, so we should do it well, because our staff are capable and the marginal cost of doing it well vs. doing it at all is negligible.
Post-AI: we can churn out things quickly, we don’t have to worry about resource allocation, churn churn churn!
Ultimately, it is pragmatic for businesses to behave this way, but it is a shame for those who love the craft. I think we took for granted the beautiful ornate hand carved furniture era of software engineering. We are now in the ikea era.
>> Ultimately, it is pragmatic for businesses to behave this way,
This is how I realized we truly are in an AI arms race. Literally every app or website or tool I use now forcibly pushes their "AI features" or "AI assistant" on you instead of just letting you use their products the way it makes sense for you. Stripe just confirmed what OP was saying. Poorly built, poorly thought out software is now the norm not the exception any more.
> Ultimately, it is pragmatic for businesses to behave this way, but it is a shame for those who love the craft. I think we took for granted the beautiful ornate hand carved furniture era of software engineering. We are now in the ikea era.
I feel this so much. I thought AI would make it easier to get lots of hand-carved ornate furniture; but right now what we are getting looks like the typical Ikea product line -- a bunch of mismatched pieces by a host of different designers with no common underlying design theme or continuity (I'm talking specifically about the looks and design, not the materials).
If your output is based on best next result, it will tend toward the mode, not even the median.
I have to assume the most common [insert thing] is going to be bad, because more people are amateurs at [insert thing] than are experts. Right?
I have never expected excellence from chatbot generated anything. I have always expected just good enough.
We are now in the ikea era
If Ikea furniture were lopsided, ugly, not-quite-properly functional and traded their minimalist design for a Frankenstein hodgepodge of redundant parts.
I don't think the beautiful ornate hand carved furniture era of software engineering has existed for many decades now.
What's happening right now is more like, we're moving from a hyper-optimized era of just-in-time manufacturing (in software, this is called "Agile", "scrum", "sprints", etc.) to getting our manufacturing outsourced to another country. In software, the "other country" is AI.
love this idea. the question then is: who has made the Toyota 22R-E of software?
My Toyota is a pre office 365 Microsoft Excel
Have any companies mastered high craft at scale (like 1000s of engineers)?
In the classic "the mythical man month", Brooks describes 5000 man years effort in delivering OS/360.
I think by any measure that OS/360 would be "high craft".
Consistently, at scale, and in a durable way: I doubt it. However, I have seen many localized cases of extreme excellence in the places where the company knows it really matters.
Yeah. Small groups within it can definitely maintain it
Apple’s hardware side seems pretty great at it. Software maybe less so.
I am really interested in this topic, but man I had to give up reading the document because there were too many paragraphs that contained lots of words but no additional detail that I could actually use. It could be AI-generated or human-generated with too many buzzwords. Doesn't really matter, still gave up.
It's not just you. Let's take a small paragraph and break it down.
> Surface-agnostic APIs: Kai ships with an opinionated web application and a Slack integration, but the main primitive is the underlying API that powers them both. The agent is a service, not an application, and surfaces are simply customized views into it.
I...kinda get that they built an API that the agent polls. And then Slack or the webapp both invoke the agent? If so, the above paragraph is obscuring the point. Also, why isn't there a diagram showing it? There is a diagram below showing "Execution Environment" below, but that one doesn't show the API. And Kai and "Stripe Product Agents" are parallel paths on it. Does it not call out to this API anywhere?
I doubt if most people these days actually try to understand any of this, or just go "Agents? Cool! Here's some product that's vaguely similar that I like or have worked on!".
It sure feels like companies have lost their way now. It's no longer about high polish and quality, and all about volume of features. I don't think users want to be overwhelmed with features, they want things that work nicely, and consistently.
Working in b2b SaaS, there’s a real gravity toward checkbox-driven development. Any time we lose a deal because a competitor had feature A, the immediate response is “we need to build feature A.”
And from a sales perspective, that’s probably not wrong.
I think a new (or newly critical) engineering challenge is how to build in a way that keeps a codebase that’s churning out features from crumbling under the weight.
> from a sales perspective, that’s probably not wrong.
Possibly not wrong. One scenario that happens over and over again is that we lose a deal because we didn't have feature A. So we build feature A, and we still don't win deals with it. One way this happens is when the competitor has a focus on one part of the market, and we have a focus on another.
Example: We go after SMB, the competitor owns "The Enterprise." Just building A will never break us into the Enterprise part of the market. We have to build an entire strategy around seizing part of the Enterprise market from our competitor. That strategy may or may not include A, but it is definitely more involved than "Build A and customers will come."
if we aren't going to build an entire strategy around "The Enterprise," not only can building A fail to win the business, it may cost us some of our existing SMB business. Every feature our core market doesn't want or need is additional complexity and feature surface area for our customers to absorb. They stop thinking of our product as "tailored for their needs" as it begins to bloat with features they don't need.
And worst of all, the investment in feature A means some other feature—B—that our existing customers have asked for gets punted down-calendar because we're suddenly tearing up our road map and building A because the VP Sales threw a temper tantrum about being unable to close deals without A. This is another way that chasing feature A means sacrificing value for our existing customers who are asking for feature B.
>> I don't think users want to be overwhelmed with features, they want things that work nicely, and consistently.
In the case of Stripe, users want one thing, which is to receive correct answers to their questions nearly instantly. And from the sounds of it, that is indeed the case.
That's funny, because I recall in 2015 hitting their endpoint for a large-ish customer, and if you added a boolean to get the total result count, it would 500 every time, presumably because it was doing some kind of "SELECT count(1)" over a postgres table. IIRC, Stripe was ruby internally for a long time, no?
Also their documentation was frequently just straight up incorrect (as in the described json schema for a response was violated. keys missing, different field names, etc.).
But it's been over 10 years, has it improved since then? I'm still in my impression of their stack from back then, although they were decently mature by then as well.
I recently had to implement a stripe payment system for a client (having never used it before) and found their documentation to be accurate and excellent (at least for the Java SDK and relatively basic use case).
No love for Stripe but IMO their documentation feels like a first-class product.
I think the specific cases where it failed was when the customer was one of their earlier ones. My guess is that some data schema migration happened, and older data was being served which didn't quite match. So perhaps recency wouldn't potentially even surface those problems either.
> Stripe is the company I usually hold up as the exemplar of polished internal tools.
unless you work there how would you know this?
I worked there. All the internal tools are amazingly polished. I’ve never seen anything like it.
As someone who has worked there as well, this is just funny to me.
Stripe has already existed for a while, and has gone through ups and downs. There was a period where customer experience was first, and the systems inside were built fast and in rather cavalier ways (See Greg Brockman famously telling everyone in a MongoDB convention about using Mongo's oplog as a queue). There were times where internal tools teams could spend all the time they needed to get about as much shine internally as the external facing websites were. Huge investments in everything. But there's just so much churn, as some staff burns out, and others realize that they have so much vested stock that continuing in such a high intensity environment is pointless, that whatever Stripe might have been during your tenure might be very different from other people's, and you can both be right.
I worked at stripe too. Sail design system at time was exemplary. A ton of effort got invested in little details. They spent an insane effort in making ruby fast with their own jit, formatter and type checker they built.
Post AI, I think the bar hasn’t been the same.
They have published a bunch of stuff about their internal tools in the past. Look up https://stripe.com/blog/stripe-home and compare it to this, as an example.
It's always possible that in reality they were always a bit less polished behind the scenes though.
It's possibly a cost benefit thing. Moving quickly with AI leaves blood splatter, but if you get enough in return you decide it's worth it anyway.
Its always more likely the company pushing the PR is less polished than they present themselves.
Maybe they have jobs to do so they offloaded a lot of the presentation work to AI, assuming reasonable people would not judge based on surface level copy style.
The issue is not that that the presentation work has been offloaded to AI. It's that the result is sloppy.
People are always going to judge based on what seems "surface-level". Stuff like legibility also matters just for data comprehension, the AI tic of constantly repeating key numbers all over a presentation or webpage actively hurts legibility.
A company that handles money should absolutely not be cavalier about the details, especially in the parts of the business that are public facing.
Very cool demonstration of managed agents built for the needs of their own business.
I think this is where a lot of companies are going to go: on-prem platforms that give various teams access to agents that are as powerful as coding agents, but much more managed and governed.
I'm betting on this with my open source project, Lightspeed: https://github.com/smartcomputer-ai/lightspeed
You wrote your readme yourself. It shows. So refreshing and i was able to finish it too.
The readme was very clearly AI-written (or at least heavily AI-assisted)... not saying that's a bad thing, and I agree it's fairly well written... but it is very obviously AI
k, I just looked through it for where the latest is. First of all, the earliest version were fully written by me, and then lightly edited with AI. The current state are as follows: intro sentences written by me, "why lightspeed" section too. Quickstart AI written, Features mostly written by me, but AI keeps interfering there. Design was also written by me several times, it also used to be much longer, but I just noticed AI put one a few paragraph of slop in there, I think that's the most egregious--shame on me for not caching it. So, if I look at the readme right now, I would say it's about 60% me. It can be better, I'll make the effort because it really bothers me if readmes are not (mostly) written by humans.
I really don't have a problem with you using AI, as long as you review and validate/test what it writes, and seems like you did that. Great project btw!
:-) https://github.com/smartcomputer-ai/lightspeed/pull/100
how so? which model? because it’s def not claudish.
the author commented otherwise.
The author literally said:
> There might be some AI-isms in there, because agents just can’t help themselves to dump their arcanae in there.
Thank you. Yes, I did. There might be some AI-isms in there, because agents just can’t help themselves to dump their arcanae in there.
Your project seems way better than the stuff they built, nice work.
I like it, very smart for agents at scale.
Wow, where do you work? Can we talk? Looking for smart people!
> Building a standalone agent product wouldn't work. Instead, it would force users out of their natural workflows and into a new app.
I am finding the opposite to be true with one of my clients. They explicitly want a new channel. The chat-style UI/UX is vastly preferred over their poorly maintained internal tooling.
I suppose if you are Stripe actual, most things would be well designed and more difficult to abandon. Most places aren't like Stripe.
The hard part is bringing everything that matters to the new channel, but it's certainly feasible to do this. I am doing it right now. We will soon be able to delete hundreds of wildly inconsistent cshtml views and related controllers in favor of a single agent tool that applies json patches. This will easily cover 99.9% of use cases. A manual json editor is retained for the rare case where we need some multi-megabyte merge operation.
I read a buzz word "Knowledge AI Platform" but I did not see any specific feature helpful for knowledge management like verification or transparency. It is more like any generic Agent builder. Maybe it meant to justify building something internally.
None of these have been especially impressive.
I think that’s because none of them go past “I’ve set up agents to be orchestrated this way” and that’s about as impressive as “look at my cloudformation template”.
Ahhh I built an internal set of agents to run our company (finances, all info in the karpathy-style LLMWiki and a database of clients, contracts, billing, time tracking, all managed by MCPs, etc) and it's also called Kai (company name is Kaizen)
Happy to be in such good company!
All hand written or did you have any underlying libraries that you used?
Mostly custom. Full data model and full web and mobile app to help run day to day operations.
The agent has switched a few times, initially NanoClaw, then Hermes, and now Vercel's Eve (maximum customizability).
NextJS/Shadcn web app, postgres db, eve agent layer, MCP tools (over 100 so every single thing can be done by an agent), SwiftUI mobile app, etc.
Integrations with gmail, gcal, gdrive, quickbooks, using mdx for the wiki displays (so we have rich diagrams, 3d models, etc).
We write about it here: https://kznconsulting.com/work/how-we-run-kaizen
Dang it, I just named my newborn son Kai. At least I didn’t go with Alexa..
Wonderful name. You may know this, but Kai means food in Maori. Many words and many, many place names also embed it, e.g Moana == sea, so Kaimoana is seafood.
Don't worry, thanks to nominative determinism, you've secured your kids employment years in advance
It’s a cool name! Don’t let Stripe make you doubt that haha
I want to read this, but the ever-changing linear gradient of the background is too visually distracting. I tried to get around it by highlighting text I want to read, but since the background is changing underneath it, so is the highlight. My eyes hurt.
Does your browser have a reader mode? Looks quite decent in Safari and Brave
I feel like every time I launch a new feature in GPTree one of these big players follows up with the same functionality within a few weeks :-(
https://gp-tree.com/enterprise
Our developer docs for GPTree knowledge engine here https://gp-tree.com/docs/knowledge-api
Cool to see, but wondering what the upside of this is vs what notion is building with their own agents. I can imagine notion agents can do something very similar to this (and with the same amount of control / security) and at what point would it make sense for a company to build their own vs buying into one..
TIL people still fall for eh I mean use Langchain. Sorry, low value comment; I don’t know how to do that differently; it is such bad garbage since day one and strangely it did not improve. Sorry anyway for the comment, at least it was not LLM generated?
To make your comment more high value, could you explain why you think langchain is bad?
my biggest code smell is debugging. Trying to step through the code is slow because of how much the debugger has to keep track off and it's a lot of step into / jumps until you get to the piece you actually care about. Then you also see stuff like "if langchain_v2: <branch> elif langchain_v3: <branch> else ...." ... breaking changes are ok! I feel like at this point they're hopelessly spaghettied and need a more opinionated approach to clean up a lot of the mess.
Since others are asking: My current goto is pydantic ai and it's been doing pretty well for my use cases.
It (and most other systems) abstract the wrong concepts when you want to create an agent. They promote what was likely never a great strategy but even parsimoniously what are strategies that were good ideas months or a year back.
For example how langchain or whatever else handles subagents and deep research is laughable even today.
So whats the recommendation? Just use pydantic and code everything up yourself. Maybe strands I dont know.
Which specific strategies do you think are outdated, and what would you recommend instead? This sounds more like a criticism of older versions of LangChain than its current APIs. The post also uses deepagents, a separate package in the same ecosystem. Is there something in the current implementation of either that you’re referring to?
I have a hard time keeping up with the space. Is langchain old news? Is there a page that kind of shows what the status quo for tooling is?
+1 would love to know as well. I have generally found the open source space to be lacking in this area and hoping it catches up!
There's like 1000 langchain alternatives and none are good, they're all vibe-coded unstable projects.
I use Apache Burr but it's not as good as LangChain. I just don't want to use software whose website has a pricing page if it's not a SAAS.
Yes, I also thought it's crap the moment I saw they need langchain to develop a harness.
The fact that Stripe are touting a production product that (at face value) benefits their business seems to suggest that maybe crap is subjective and as ever, being overly opinionated in an emerging space might actually be a blocking mindset rather than a positive one.
It might also suggest they went with the first LLM recommendation, like Anthropic choosing React for Claude Code.
Instead of spending half the comment reflecting on your post why not point out what you don’t like about it or some better alternatives?
Totally, I find LangChain is the Vercel of ML
For what reasons?
It's a lot of sugar and high level abstractions on top of existing things, I find using the existing things not that complicated or difficult and I struggle to see the value on using the framework as it doesn't sit well with my way of abstracting the stack.
Somebody probably mentioned this already or maybe its just me but: The "endless scroll" this page does is neat, to say the least.-
There's quite a bit of cool stuff in the console too! The one in the top right corner
I just hear Steve Ballmer yelling
Oldies let's gather here.
[Bad mental image ... can't unsee ...] :)
Can anyone recommend something self-hosted that does this?
It's very close to the direction we're taking for windmill.dev, we call it "operator builders" rather than focus on "knowledge graph" which the article is very light on details of.
What I'm mostly reading is a developer platform and runtime where users can build agents that can run tools and for that you need a secure code runtime, ACL/permissions, easy way to build apps or what cloudflare OS call gadgets. We're betting on this too at https://github.com/windmill-labs/windmill, very curious to see if that's the future for most enterprise and if a model where everyone vibe-code/fork cloudflare OS to their enterprise need is the future, or a more exhaustive/enterprise platform like ours does.
so is it like CloudflareOS ? https://github.com/cloudflare/cloudflare-os
seems every company that has spare engineering resource all builds such thing internally
Almost as if distributed safe compute for autonomous workloads suddenly came into focus for many orgs!
reminds me of Cloudflare OS: https://blog.cloudflare.com/cloudflare-os/
I love the design, I'm sure there will be more knowledge framework coming in the near future.
> Within two weeks of our April launch, most of Stripe was using Stripe's Knowledge AI Platform, also known as Kai.
By force or by choice?
By choice. I currently work at Stripe (opinions my own, I'm just some guy) and was here when it released. It's a genuinely useful tool, which explains the widespread adoption.
This is the same as AWS's new quickSuite platform?
This site could use a bit more line height, more paragraphs, or less text overall.
They don't really say why they built their own rather than using one of the open source solutions like https://github.com/bionic-gpt/bionic-gpt
Size and scale, I would think. An out of the box solution probably doesn't quite have the same capabilities as something they can (and now have to) manage in it's entirety.
Stripe probably WANTS to be opinionated about how their company works with the tools.
In the first paragraph:
> No existing tool could handle the data security requirements and specific workflows Stripe needed
Somewhat interesting how the design of Stripe's developer-focused landing pages used to be the "cream of the crop," so to speak, but now they just look like Claude run amok. I wonder if the web design "skills" for Claude, and other LLMs, were overly trained on Stripe.
The article reads like slop, to be honest.
Dammit, I just named my newborn son Kai.
But no darkmode support? … :D
haha stripe's example prompt is "Create an event"
Has tl;dr been replaced by ai;dr?
The whole piece is mostly AI slop.
"Sharing the substrate forces discipline and creates a flywheel: improvements to the execution environment benefit both internal and product agents simultaneously."
No human would write that.
Hope this comes over as constructive criticism:
It doesn't live up to my usual expectations from Stripe.