# Webhooks, Agents, and the Future of Integration

**Podcast:** Chain of Thought | AI Agents, Infrastructure & Engineering
**Published:** 2026-10-15

## Transcript

JSON is an abomination.
So maybe webhooks are duct tape.
They're just good enough for the mirrors, and they work.
Maybe we don't need SDKs anymore.
I don't think you could have found two identical implementations of webhooks in the wild.
When the laptop is in your backpack and it's closed, that bridge also goes down.
When you open the laptop, you're going to start to get a storm of reach rise from 12 hours ago.
Even with Identic Flows, you can aspire to have simplicity.
Welcome to Chain of Thought.
I am your host, Conor Bronsden, and today we're talking about webhooks.
Webhooks are the underpinnings for so much of the agentic internet today, and Sphix delivers billions of webhooks for startups and the Fortune 500.
Their co-founder, Tom, co-created the standard webhooks spec that OpenAI, Anthropic, and Google Gemini all adopted.
Sphix's founders have argued for simplicity since well before this AI wave.
Years at Samsung on the graphics toolkits behind Tizen, then an encrypted sync side project where the webhook problem found Tom.
With me today is Tom Peck-Owen, founder and CEO of Sphix.
Tom, lovely to see you.
Thanks for joining me.
No, thank you for having me.
Looking forward to chatting.
Tom, why has the integration layer stayed this challenging for the last couple of decades?
And how are you trying to solve it?
now as it becomes so urgent for AI?
In a way, it's much, much easier than it used to be.
I don't know if you remember those days, but now we have like REST and JSON and HTTP, and back then it was like custom TCP protocols.
Everyone had their own custom thing.
So I think things have gotten much, much better.
But also there are just way more integrations.
I think it's like Jevon's paradox, right?
It's kind of like the easier something becomes, like it's just, you know.
Yes, the more it gets used.
Exactly.
It gets used way more.
It's just like with volume, you get like different challenges and more challenges.
And I think the main thing for that is that because people do things differently, right?
So like when you have like 10 integrations, you have people doing maybe 10 different things, maybe less.
But when you have a thousand of those, you're going to have a thousand different things.
And it's something actually we saw with standard webhooks as well.
You know, like when we created it, the understanding or the realization is that everyone was doing things differently.
Like literally, I don't think you could have found two identical implementations of webhooks in the wild.
And just by reducing that space, I think we made integrations easier again.
So to your question, I think they're much easier, but also like much harder.
And the harder part is just really because of volume.
And before we go too much farther, I do want to say a quick thank you to you and the Sphix team for sponsoring Season 4 of Chain of Thought in this episode.
You can find out much more about them at link.svix.com slash C-O-T.
And of course, we're going to be talking all about webhooks and how Sphix is approaching them today.
Webhooks are viewed as a very unglamorous piece of infrastructure.
And yet, I think anyone who tries to build their own version at scale starts to realize the complications that come with it.
You found this problem building an end-to-end encrypted sync problem, not by setting out to build webhook infrastructure in the first place.
What did you hit that made you stop and say, hey, I'm going to build a company and a standard around this?
Yeah.
So at my, it's called At-A-Sync, the previous company, and actually it's still running on the side if anyone wants to use it.
People kept on asking us for webhooks.
And we kind of analyzed it.
We didn't have a lot of resources.
And we realized that it's going to take us a lot of time.
And even if we did build it, it's going to take us a lot of effort to maintain.
And even if we did manage to find the time to do both of these, we built such a great product.
And the webhook system is going to be like a lame duck in comparison.
It's not going to be great.
Because we can't spend the 10x the amount of time to make a great webhook product.
And I wish I was smart enough to realize at that point that there was a product there.
But it was only like a few months after this that a friend of mine asked us silly questions about webhooks on like a Slack channel.
And I started like explaining to her, you should do this, you should do that, and you should do this.
And don't forget about that.
And I realized with like all of this complexity that I was explaining that she couldn't care less about any of this.
She just wanted to send webhooks and not have to think about it.
So I asked her like, hey, if I build you a product, will you pay me?
And she said, like, yeah.
And then someone else chimed in and said, yeah, we want webhooks as well.
And kind of, you know, like very low conviction at that point.
But I was just like, you know what?
I can build something for you.
I built it for them.
And then I realized that actually it adds a lot of value.
And there were more, and we launched it on Hacker News and we got the perfect mix of you're, you know, you're wasting your life.
This is such a silly idea.
No, but, you know, you need those as well, because that's why not, you know.
Not everyone built it already.
You need to have the haters.
And then obviously the other half, which is either we need webhooks now, let's chat, or this was a huge problem, where were you a year ago when I had to build it myself?
So it was like a great motivation boost, like the Hacker News launch.
So let me be one of those lovely Hacker News commenters.
Some people consider webhooks a bad primitive that should be gotten rid of, but folks can't figure out how to.
Yes.
What do you say to those people who are maybe the grumblers in the situation?
That I agree with you all.
You're 100% right.
But I think it's an example of worse is better.
You know, like JSON is an abomination.
Really, there's not a lot of good things to say about JSON.
Yet, it's so widely used.
And it's ubiquitous.
And it's just so easy for people to use.
It's like worse is better.
And you get to use, and you get to add value by using JSON that you wouldn't by using, I don't know, protobuf or whatever other thing that it may be better, maybe worse.
Or even message back, right?
Which never caught on.
So I think webhooks are like that.
Drive down any downtown in a major city, you'll see some mirrors attached with duct tape.
So maybe webhooks are duct tape.
They're just good enough for the mirrors, and they work.
All right, well, if we're going to hate on JSON, what other tools do you hate, Tom?
Oh, man.
I think I have a love-hate relationship with everything in the world.
Some things that I think maybe Rust.
Rust is the exception.
Other than compile time, I love Rust.
But I think we've built...
such amazing things.
But the problem with developer tools and libraries and protocols and all of those is that it's impossible to iterate on them.
Because I think JSON could have been much better if we were able to just scrap it and continue to iterate and iterate and iterate.
But we just can't, right?
Because it has to be compatible.
So I don't have a problem with JSON who ever created it as much as the frustration with the fact that we can't make it better.
And one of the challenges to improving these primitives today is the amount of signal we're getting as agents begin to 10x the internet and 10x the number of calls that are being made across every service as agents move to become the primary users of many apps what is specifically breaking when the thing receiving the event is now an agent on a laptop or maybe in the cloud rather than a service in a data center So events are kind of unique in the sense that they're controlled by the sender, not the receiver.
So like when you make an API call, you know, you can make an API call to API slash v1, API slash v2, you control, you know, like you can define the schema that you want.
You can define a lot of, you know, like if you think of GraphQL, for example.
And I think events have traditionally been way more strict in what they send.
So I think that's one of the challenges, is that they don't have the same flexibility that we have in other places that agents enjoy so much.
And the other thing, and I'm not even talking about local, and I'm going to talk about local consumption in a second.
The other thing as well is that the way events are created, because they're created asynchronously, they happen almost outside of the session.
So you don't know when you're going to get an event.
Are you going to get an event from a previous session?
So controlling those becomes a very complex problem.
And then the last part, which is what you just mentioned, is also if you're receiving it on a laptop or some very ephemeral environment, the way to consume events at the moment just doesn't support those use cases very well.
So let's talk about that scenario where An agent's running locally.
It's on a laptop and the laptop gets closed.
We've seen this meme quite a bit lately where folks are keeping their laptop open as they walk and we're seeing little 3D printed claws to keep your laptop open.
Obviously, you can spin up agents in the cloud.
This is more and more how agent fleets are built, but many things are running locally.
What happens if that machine does get turned off and Where are all these events going as things act, say, overnight?
Yeah.
So at the moment, the situation is not great.
And we can talk about it later.
We added some plugins for Hermes and OpenClaw to make it slightly better.
But at the moment, what people often do is they use a tool like Ngrok or Svixplay or any tool that forwards to Cloudflare tunnels, any tool that forwards to a local server.
The problem is that when the laptop is is in your backpack and it's closed um that that bridge also goes down and those events just if you you know you're from a normal provider like stripe or svix or any of the six customers they just retry and retry and retry and then they kind of fail and then like when you open the laptop you're gonna start like get a storm of retries from you know like 12 hours ago that's kind of like the current state of the art or the current state of things and we we actually created I think it was like three years ago, way before agents, we created what we call like polling endpoints, which was essentially a way to let people consume them, you know, by polling instead of by sending.
And the nice thing about that is that they can continue from where they stopped.
So when you open the laptop again, the agent could just go and continue from exactly where they last got, the last event that they got and like start polling and polling and polling and get all the events that they missed.
Yeah, so I think if you use one of those tools, it's a much better experience.
Let's talk about the Hermes and OpenClaw integrations right now, because I think it's really interesting that instead of pushing to the agent, the agent in these integrations are pulling a Sphix buffer over outbound HTTPS and essentially reversing the traditional approach here.
It's also a great example of building for the agent scale of, I think, the oncoming, or maybe we're already there, agent economy.
And we're seeing the success of these agents and their widespread with the personal agent competitors from GrokBot, from Muse, from Dots by OpenAI.
There might be another one out by the time you and I actually release this episode.
Ermi's just raised.
what, $90 million at a $1.5 billion valuation, it's clear that people, whether they're developers or whether they're individuals, are going to have more and more agents running on their behalf.
What does this mean for how the product surface around Webhugs changes and how are you enabling this onrushing agentic economy?
So first of all, I want to say that I'm a hardcore Linux user.
I love using local software.
But I do realize that the cloud has huge advantages.
So I think what you just described, we're going to see even more of it.
I don't think OpenCloir and Hermes are going to be self-hosted for the long run.
I think maybe they already do have a cloud offering, but if not, they'll have one very soon.
And they will essentially complete directly with Town and Muse and all of those kind of things.
Just because people don't want to run software locally, unfortunately.
In terms of how to help those tools, I think we can see two different ways of approaching it.
Either we're going to have very structured integrations.
So for example, Muse may have a direct integration with Stripe, and it's kind of like one integration set up the old-fashioned way.
It's kind of like a third party to a platform kind of thing.
And that will just work the way it has always worked.
I don't think it has anything to do with the agents.
But then you're going to have a lot of other ad hoc integrations.
So wherever the new Stripe is going to be in a few years, or even off platforms, some of our customers up and running, we have Resend and Agent Mail that provide emails to our customers.
And I think with those, you do have to have a very different way of doing it.
The agent needs to be able to subscribe and define what they want to subscribe to and define...
you know, the timeframe of the subscription and probably like even more things that we haven't even considered yet about like scoping the sessions of, you know, callbacks.
And there's just, I think, a lot more to be done.
And it's very hard to know before knowing like how things are going to be used.
So, you know, we talked about OpenClaw and Hermes.
What we did there was more a reactionary thing.
We just saw that people, you know, like you go to the OpenClaw docs and you see, you see like, very complicated, complicated docs about like how to set up web hooks.
And we figured we can make this much easier by just having this like shim layer to make it like a polling thing.
And does that answer your question?
I think it does.
And it leads me down a few different tracks here.
So we had Zriv Batra, one of the co-founders of Vue Tori on this show a few months ago, and he argued essentially that most of the web will never get APIs for agents, or at least next five, 10 years, because despite how cheap code is getting, organizations like, let's say, your local school, the principal's probably never going to have a developer, or at least it's going to take several years to do it, redo the website for the school district, and enable an API where your agents can now go schedule classes for your kid.
And if that happens, it has to happen at a broader layer.
There are so many compliance needs around this.
Government moves slowly.
This is the long tail of the Internet.
Yeah.
This implies that browser use is going to be very important for agents.
I think we're seeing that already with some of the tasks we're asking, you know, codecs and others to take on.
How does this long tail infrastructure build out impact?
the webhook layer and other primitives that you're thinking about around this new agent operating experience where agents are the layer by which we interact with the internet, but much of the internet is still built for the last era.
Yeah.
I don't, maybe it's a cop-out, but I think we're kind of like almost exempt from this discussion in the sense that the most tech forward businesses will have APIs and webhooks.
So even if the long tail is not there, I think most agentic traffic, most agentic integrations, and most economic value is going to be driven over APIs and webhooks.
So yeah, the government may not adopt AI, but actually America.gov came out a few weeks ago, which is like a chatbot for the all America thing.
I haven't tried it, but it just shows that even the government is adopting those tools.
Yeah.
And I do think there is an opportunity because of what coding agents enable to more rapidly adopt the infra for this technology than what we've ever seen before.
And I'm very curious to see how that goes because we may all be very off on our predictions as we have, I think, a hard takeoff that we're starting to experience, though there is a lot of cleanup to follow that.
And to your point.
the economic side of it is very much going to be tightly tied with agents.
I think that's becoming pretty clear.
And you just actually reminded me of something.
So I think it was like 15 years ago, something like that.
I used to go to this sports class and they had the most terrible web UI.
And I just wanted an app, you know, that would let me, you know, favorite teachers look at the schedule in a much more sane way.
And I just packed together like a...
you know a small proxy um that essentially like parsed the website and then like serve json instead um and then like built an app on top of that so i think there is a chance we're going to see a lot of kids you know hacking around or building proxies around their schools or even you know like tech forward principles like utilizing those tech kids um like to build something like that for them i am going to be fascinated to see how that all plays out because it is so clear we are entering an era of builders and exactly anyone who has an idea can go do it as long as they can explain it in plain language or even ramble about it over a microphone like we're doing right now so i do think it's a really exciting moment and webhooks is one of those layers that actually enables a lot of that and i think that's maybe undervalued by builders Yeah.
I mean, we're trying to fix that.
So hopefully by the next time we chat, it's going to be even better.
Season four of Chain of Thought is delivered by Sphix.
We spend a lot of time talking about what agents need in production.
And one of the least glamorous answers is events.
Your customers want agent workflows that react to things happening inside your system, which means your API needs webhooks that actually work.
Not just a post request and a prayer.
Retrys, ordering, idempotency.
Replay protection.
Sfix does that as a service, and they wrote standard webhooks.
The spec that Anthropic, OpenAI, and Google bailed against.
So if your API doesn't have reliable webhooks, that's turning into a lost deal.
Join Brex, Drada, Daytona, and many others on Sfix.
Get started at link.svix.com slash C-O-T, or go to the show notes to grab the link.
Qualified startups will get $12,000 in credits, $50,000 for YC companies, I can't recommend Sphix enough.
I'm a huge fan of their open source project.
I've actually contributed a bit myself and they're so easy to integrate with.
I think you'll really enjoy it.
Check out Sphix at link.svix.com slash C-O-T.
And one of the ways that I know you're trying to fix that has been helping set standards for the industry.
I mentioned it earlier, but standard webhooks has been adopted very broadly by AI already.
What was the value in setting that standard and how has that driven adoption from these major companies like OpenAI?
Yeah, so they're not the customer, not yet anyway.
But I think created it for like two reasons.
And one is selfish and one was not.
But even the selfish one wasn't about affecting revenue.
And so the main reason was that we just identified this huge gap and everyone was doing everything differently and it was just a huge pain.
And we have a webhook ingestion tool called Svixingest and we have so many integrations and we need to build new ones all the time because there are people that don't use standard webhooks.
And it's been a constant pain.
So we identified that pain and we just wanted to fix this.
It was something that annoyed us and we realized that we were well positioned to do that because, you know, a lot of our customers are going to adopt it um i mean actually all of them ended almost all of them ended up adopting it and so it was like a very strong position we also found while we're working on it we found like great partners that also identified this problem so like you know like kong is the api gateway and they they never had a webhook verification module because where do you even start you're gonna have to like build a thousand of these or a hundred thousand of these i don't even know how many different webhook centers are but now with standard webworks they were able to And same with Ngrok.
Ngrok now automatically does webhook verification.
They can do that because standard webhooks exist.
So I think the first part was just that, like identifying this gap and just solving for it.
The second part, and this is the selfish one, many sales calls, we had the team coming up with their own random signature schemes and their own random requirements.
like half of the sales process was explaining to them why there are like security issues in this implementation that they chose or like how to make it better.
And oh, if you change that, you know, it's going to be better in that way.
And it just like was a huge drag.
And we realized that it's not even that the ecosystem is going to benefit, even like us specifically are going to benefit from just having like a standard way of doing it that we can just refer to and just like, hey, listen, this is sanctioned by literally everyone at the moment.
Like everyone is using it.
you can either be part of that ecosystem and benefit from those tools that are being built.
We have libraries that we've built for 12 different languages that they can just use, like unbranded, just branded with standard webhooks.
And that was a huge unlock as well for us in that sense.
I don't remember if we thought about it ahead of time or if that was the spark of the idea, but it's definitely been a selfish win for us.
This will give away to our listeners when we recorded this, but I see that Google Gemini has actually just announced, finally, their own personal assistant to compete in this space as well just a few minutes ago.
So I think that speaks to your vision of the future where everyone has more and more agents acting on their behalf.
And it speaks to the value of these primitives we're talking about and the need to be excellent in these areas.
Yeah.
And I think, you know, like if you consider We talked earlier in this call, we talked about the number of integrations.
So now we have, what, like seven, eight major agent, I don't know what to call them, agents, I guess.
And they're going to be even more.
And those each has to integrate, I don't know, like a thousand different services.
So it's just another example of the explosion of different integrations that you all have to do.
Yeah.
So...
you know we've talked about some of those big names open ai anthropic mni they've all adopted standard webhooks it's fueling their agent layer i would assume that anthropic is going to come out with their own personal agent soon that's the rumors that's coming out before their ipo to really continue to add to their competition in the space though with the recent news that opus 5.5 can be and is currently being used to power GrokBot, I do wonder if they're going to take a partner play instead here.
Can you tell me a bit more about the actual steering establishment of the standard here and why standard webhooks is able to begin to shape where you see the industry going in the future?
Because I'm sure there are some folks listening who are either mildly skeptical, they don't know anything about the standard, or maybe interested, hey, I want to get involved, I want to try building on the standard.
What's the governance approach and how are you thinking about this spec as you move from a 1.0 version to 2.0?
Yeah.
So first of all, we have a committee.
That committee decides on what gets done.
And we speak in public.
Other than small notes to each other to celebrate small things, like...
When, I don't know, like one of the labs adopted standard webhooks, we kind of like we sent a message to each other, but like, but other than those, like everything is done in public.
I think like every spec, there is, you know, people that are more proactive and active, like in the community and some that are less, but like everyone has been weighing in on all the important stuff since the beginning.
And for people on, you know, they want to contribute.
It's all on GitHub.
So you can change the website.
You can, I think, like Mercury recently released an Elixir library that's compatible with standard webhooks.
So we have that link there as well.
Yeah, you can just do things, I guess.
Really just go to our GitHub and just contribute.
And we'll certainly link that GitHub in the show notes.
And I have made a couple of very small docs contributions myself and need to dig more in depth.
It is really cool to see how the industries come together here.
I know you have team members from Zapier, Twilio, Superbase, and a variety of other great companies on that steering committee with you.
How are you going to continue to evolve the roadmap here?
What's the plan that the committee currently has to ensure the standard becomes more and more valuable so that...
you can head off some of the criticism around retry guidance or anything else that is coming through.
Yeah.
So one approach that we've taken with standard webhooks that I think is different to how standards are usually made is that we try to follow real-world usage instead of lead it.
So I think a lot of standards, they sit in a lab, they try to define something, and then they write it out, and they adopt, you know.
either hope people adopt or maybe if it's something was written by google chrome just adopts it and kind of powers through um it just gets it you know in everyone's hands and and here we just we see the gaps that people identify what people need to do what people have already been doing and it's been working and we just we do that and that doesn't mean that we wait 10 years after we're not like um you know the c standard is famous for like adding things like 20 years after people have been needing them like we try to be a fast follower and like one example is MCP is adding webhook support, finally.
And we've been chatting with them about that, and they're going to use standard webhooks.
And one of the things that they wanted, they wanted what's called CRC.
But essentially what it means is it's a way for the sender to verify that the client actually knows the secret.
So verify that the client is actually trusted.
I don't think that's necessarily a requirement for most webcast implementations, but some people definitely have CRC.
And that's an example of something we identify that people need, and we're going to probably add to the spec in the very near future in order to support them.
So it's kind of like, again, the fast follower can be even pre-launch.
We can follow people as they're specking things out, but we still try to see what people need and use and kind of help them there.
So if we think about your APIs as the new reader for models, and models are now writing integration code for pretty much everything we do, at least I think any company coming out of Silicon Valley is true and any company is kind of on a bleeding edge.
And we're going to see that continue to be more and more true as the agentic economy and digit coding expand and eat other types of software engineering.
If models are now writing most integration code and will in the future write all of it, what changes about how we design and document our different surfaces?
Yeah.
So it's kind of tied to what we talked about earlier in this call.
One thing I'm excited about when it comes to agent integrations is that agents are way more adaptable.
So you can actually iterate on APIs fairly quickly.
And to call back on what I said, my biggest frustration with JSON was that you're not able to iterate, you're not able to make it better.
There's a company by a friend of mine, it's called Restless, and what they're trying to do is to reimagine REST in the world where it's just an agent consuming it and it can change all the time.
And I think that's a very interesting approach.
And we see it as well with the CLIs.
They don't need to have like a set or even with MCPs, MCPs don't have like a set defined API that will never change.
Tools can change on every invocation and the agent is going to be fine with that.
So I think that's like one very interesting thing.
The other thing that I think about every now and then is SDKs.
You know, SDKs were the most important thing for the longest while.
And I think a lot of people were saying how SDKs are going to be essential for agents.
And maybe that's true.
I don't know.
But I also feel like in a world where the agent can actually just hack together an SDK, maybe an SDK is not that necessary.
I mean, we still have some magic in our SDKs that we wish everyone would use, like automatic retries and a few other things that I don't think the agent will necessarily hack together when they do it, or at least not hack it in the way that's compatible with how we do it.
But other than that, I don't know, maybe we don't need SDKs anymore.
No idea.
For agents.
Let's go down this rabbit hole.
Okay, let's do it.
We don't need SDKs anymore.
What does that mean for builders?
How should they be adapting their perspective?
Yeah, so caveat for agents.
I think also like humans still benefit from SDKs.
And I think SDKs do have...
value.
I wish the agents used them, but I don't think they're a blocker anymore.
And how people should adopt?
I think people are adopting already.
They're building MCPs, which is essentially an SDK-less integration that is very dynamic.
At the beginning, it was also like, maybe it still doesn't have response schemas?
I don't even remember.
But it's very dynamic, and I think that's how people are adopting.
What are the other changes you're anticipating?
Skills is an obvious area where we suddenly have this new layer that we are leveraging with agents that was, I guess you would call it, you know, tracked business logic previously.
And it's a way of adding some semi-determinism to these non-deterministic workflows that agents are driving.
And Svix has...
shipped skills rather than more docs in many cases, because skills are almost an active form of documentation.
But there's obviously a ton of updates that come with this and documentation goes stale while types don't, as I think you mentioned back a couple of years ago.
Yeah.
How are you going to keep skills from rotting the way per framework recipes did in the kind of laying chain era?
I wish I could sit on a high horse and tell you that we have some solution, but actually I think they've already gone stale at some point, we had to fix it.
But definitely one area that we're slightly behind, I think a lot of people are doing very well, is evals.
And I think the nice thing about having agents as your customers is that you can actually ask them to work for you 24-7 and try things out and see if they work, if things are better, things are harder.
And so that's definitely one way of doing that, that more and more companies are doing.
And the other one is that we try, and it's kind of funny, you know, like a lot of the stuff about EGENTIC feels both profound, but also exactly the same thing we've been doing for like 30, 40, whatever, however long years.
And so one principle is keep it simple, silly, or dry, or don't repeat yourself.
The docs are slightly different or cover different ground than the API reference docs.
And then again, compared to the skills.
So the skills, they reference the other two.
And they actually have a lot of just original content that we don't have in the other places.
We use the skills more as almost like a solutions engineer.
It's just like, hey, if Connor is trying to integrate, ask them whether they want to go this route or this route or check their code and verify that this is the way that they do things, which I don't think you can do this like choose your own adventure in docs.
Or even if you try to do it, I don't think it's going to be very useful for humans, but I think for agents, it's very good.
So that's why the skills are very agent-oriented.
And then the docs are what they've always been, handwritten for humans.
Yeah.
One of the ways I've personally adapted to this is I ended up building a skill to keep my docs more up to date and turn it into a GitHub action that I run on my larger repos and have an agent periodically run in a loop.
It's just called SSOT check, single state of truth check, because I have been noticing that drift is so easy, especially when agents are just continually updating docs, adding comments, et cetera.
And so having it as a deterministic workflow that runs, as part of GitHub Actions and then is also run by an agent regularly as a double check has has helped with this.
But it's a fight against the continual iteration and the mass amount of code we are creating in this current era.
And I don't think it's a solved problem by any means.
And I think like previous years as well, we should aspire to have less code, even if the agent is creating it.
I mean, first of all, for like for reasons of our current limitations of context windows and all of that and but also just simplicity is you know the elegance that comes with simplicity just means that agents are less likely to make mistakes as well because i feel like a lot of the agentic development flow that we have nowadays it's kind of like okay we're gonna make a mess But don't worry, we have these tools to review BPRs that's going to catch some of the mistakes, and we're going to fix those.
And then we're going to find, you know, we have an agent that monitors Datadog, so we're going to catch those and quickly fix those.
And then we end up with, you know, this like huge amount of patches on the top of patches and just more complexity instead of just like taking a step back and simplifying it.
And I'm not advocating for, you know, everyone taking a step back and writing it themselves.
But I think even with Egentic flows, you can aspire to have simplicity.
And I think I really wish that doesn't get thrown out of the window with all the software factories or high utilization of agents.
I do think this is a challenge because often our best software engineers are the ones who spend the time to figure out how to simplify and remove code.
And yeah, we can do that with agents where you assign agents to think about them to work on this.
But there's so many other agents that are already building a ton more code that it just becomes a losing game, it feels like.
Yeah.
Yeah.
I mean, I think, so I spoke with a friend of mine the other day, and I think he said something that was interesting.
I don't know if he's right.
I don't think he's necessarily right, but it was still an interesting thought.
And he said that the way people are...
you know, approach, agentic development at the moment is very similar to how people approach offshoring, like, what, 10 years ago, 15 years ago?
Which is like, oh, oh my God, you know, like an engineer here cost 100 bucks, whatever, an hour, whatever the time unit there, it's only like 10 bucks.
So we actually, we can have like way more engineers, way more code generated.
And we're just going to throw more, you know, more intelligence as like humans versus here at the problem and just like generate more and more and more.
And he was arguing that this is going to reverse slightly because of that.
And I don't know if that's true, because I think here the scale is just like infinitely larger.
Like you can now throw a thousand or like a hundred thousand people at the same problem compared to like previously, which was like maybe 10x the amount of intelligence.
But it's still like an interesting thought that like maybe technical debt will remain a thing.
Maybe complexity will remain a thing.
Maybe those things actually will matter.
um and then we're gonna have to figure out what are the techniques to like rein some of it in um and make it sane um yeah it's a really interesting thought experiment because we we do have these tools now that can be always on helping solve our technical debt as it is created and yet If we're not careful, it's so easy for the continual development they are doing to just scale this problem.
And I think this is why everyone's talking about software factories, right?
Like, how do I have software best practices?
And maybe we'll get to a golden software factory.
Maybe someone else already has, and I'm just out of the loop on it.
But it is so hard to have it be continually solved, especially because despite us adding many deterministic workflows as part of these software forages, software factories, It's still non-determined models that are driving this.
And so it's easy for there to be outflows and changes.
And the space is changing so rapidly that as the intelligence of the models grows, I think we're rewriting everything regularly.
I know it's certainly true in my personal projects where I get a new level of intelligence, let's say, you know, Opus 5.5, big step up in capacity.
ability to just do long-running tasks.
And I said, hey, Opus, I need you to go review all my key repos and refactor.
And sure, it did that.
It cut some lines of code, add some others, had some great suggestions to simplify.
But it didn't lower the lines of code of the Oval repo that significantly.
Unless you're being very intentional about like, okay, I want to simplify this down to the very core primitive, especially because of how much documentation we're creating.
tracking of memory, tracking of context.
We're trying to get these agents more information.
And that does just create a challenge around how much to provide and adjust.
I think it just speaks to the fact that we've changed the abstraction layer that humans are operating on.
And it doesn't mean we've solved the layer underneath.
There, in fact, may be some of the same problems.
We're just changing how we're experiencing and interacting with that layer.
And the acceleration of code into all this plumbing that is already somewhat broken and maybe very broken in many organizations may actually exacerbate some of these problems if we're not careful.
Yeah.
And I think it's, yeah, exactly that.
Because like even the amount of logs that are being generated, right?
I mean, I'm sure a lot of it is just the fact that we have, you know, like a million agents running in parallel.
But part of it is just that we're just wasteful because it doesn't matter.
and we don't care about it, and we have solutions.
Even in our lifetime, I think my first computer probably had a five megabyte hard drive or something like that, or six megabyte, something of that order of magnitude.
And it changed so dramatically.
And I think we learned, we built new tools, we learned to adapt, we have new techniques.
And I wonder, we're just rerunning so quickly, I wonder if we will find, I'm sure we will find good ways to you know wrangle all of this data and like actually make sense of it without having to resort to like as you said just outsourcing it and reading the synthesis like maybe more deterministic ways yeah i mean we're seeing different approaches this doesn't necessarily speak to the deterministic piece but i know developers who have essentially an automatic architectural animation that runs in parallel to their ide where they and this is something that's being added to things like T3 code and other agentic IDs.
And you're seeing just a continual animation of what is the architecture of the systems being built?
What where is data going?
So you can go, oh, wait a second.
This isn't attached to anything anymore.
This is now vestigial.
And I think that kind of visualization layers is interesting.
I don't know that it's going to be the right layer of abstraction as we go forward, but.
We're seeing this all change very rapidly.
And, you know, obviously MCP, which you brought up earlier, that they are aligning with your work, which I think is fantastic.
But they have changed so much since the launch of the protocol.
They went stateless in July and moved tasks out of the core protocol into an official extension.
It's been crazy to see the development of some of these now widespread standards for the AI era.
let alone things for the human-led era that are still being pulled forward into the agentic era.
I would just love your take on how we should all be thinking about navigating this next layer.
I think, I can tell you, I don't know how everyone should be approaching it.
I can tell you how I've been approaching it.
It's been so hard to try to guess how things may look like.
So I think I found the best approach for me and for us has been to just keep our fingers on the pulse and continue to adapt as things adapt.
And I mean, try to see what people do at the periphery because some of what they do is going to become the next step.
But I think as long as you stay and you keep on track the frontier, you're going to be well ahead of the curve just because you see what's coming.
Because I think that's the best we can do.
I don't think...
Coding agents were not that good 10 months ago.
And agents, OpenClaw was not a thing 10 months ago.
Or whatever, maybe 12 months ago, something like that.
So MCP was not a thing a year and a half ago, I think.
I don't know, maybe two years at this point.
God, yeah, almost two years.
That was November 2024 or September?
I forget.
Yeah, I think something like that.
And anyway, we're now at MCP 2.0, right?
Essentially, the going stateless that you mentioned.
So if you try to guess where things are going to go, there's a zero chance to know.
But if you were lurking in the MCP discussion boards, you checked out their GitHub, you'd see that actually they work in the open and stateless was coming for almost a year or however long it took.
So I think as long as you just stay informed and just try to keep up, I think that's the best approach.
I don't think any of us can predict what's coming next.
Well, speaking of what's coming next, I know Sphix is making some big moves.
What's new for you and your team?
Yeah, so we just launched something new.
We call it Poke.
So it's like publish once, know everywhere.
Oh, know everywhere.
Kickoff everywhere?
I don't remember.
It's a new acronym.
But essentially, we're just trying to think of how webhooks and how events, and especially events between different services, should evolve in this new era.
And again, I say we're trying to think.
It wasn't like us sitting in a room somewhere.
It was just seeing how our customers actually use the product, seeing how agents use the product, seeing all the challenges that we face.
Again, I keep on using the word agent, but as I said, a lot of this stuff actually like...
predates agents.
Like a lot of the best practices that you should apply here have always been best practices.
That's a very long way of saying, though, that we're just trying to do event-driven for agents and event-driven to make it easier for agents to subscribe to events and different services and to also trigger asynchronous events.
Because all of this, it's kind of like the prowler that I made earlier to offshoring.
I think it also applies here in the sense that you ask someone to do it and they get back to you in like four hours.
instead of just like the normal API response time of like 100 milliseconds or 10 milliseconds or whatever it is for your service.
So I think some things have inherently changed.
And also the scale of our ambitions of what an API should do has also increased.
Yeah, now it's very normal to ask an API to generate a full feature, you know, maybe not a full feature, but like a Seinfeld episode or something like that.
That's like normal, right?
So we want to make sure that you know, we follow that worst is better of JSON that I mentioned earlier, or REST, or maybe just like the simplest better is maybe a better way of putting it.
And just make it easy for people to do the right thing from the get-go instead of someone having to come, you know, five, 10 years from now with like a standard web-esque solution and kind of like try to rein in the complexity.
I'm a big fan of simplicity, huge fan of simplicity, actually.
So trying to help keep things simple i guess that's maybe the right way of putting it perhaps the most valuable skill in the current era is figuring out how to create simplicity in certain areas so i love that you're taking that perspective tell us a bit more about poke and and what's happening with the poke launch who is using poke off the bat um where is it being valuable for teams oh man it's very very early like we don't even have the the product full fleshed out it was more just we wanted to release the you know release the spec um out in order to to get people to like give more feedback um early on so while it's still malleable and we do you know it does rely on the on the tools that we've already built for our customers so for example one of our customers is agent mail and they do agent identity and email and we built you know we built tools for their agents which is like a lot of open close and all of that to kind of like very easily subscribe to notifications about when an email is received and all of those kind of things.
And just make it very easy for them to react to that.
So it's kind of inspired by that work, inspired by the work we did with polling endpoints, and inspired by the work that we did with standard webhooks, and uses some of these things as well.
And it's really just, it gives us the opportunity as well to sit back and kind of drop the bad ideas and double down on the good ideas.
And obviously, if you want to learn more about everything that Specs is building, we have our own link for the podcast, link.svix.com slash C-O-T, so you can learn much more about POKE, how they're approaching standard webhooks, and there's more info on standard webhooks as well at standardwebhooks.com.
I would love to close us out here, Tom, by asking you, where are webhooks?
and the work you're doing at Svix providing the most value for customers today.
What are you hearing from teams you work with and what's your dream for what you want to provide them over the next year so that they are enabled in this new era?
I think, you know, being like a middleware, I guess, and I mean it in a nice way, I guess, about us, but like we, you know, we sit between our customers and their customers.
We add value both to our customers and I think, and their customers as well.
I always love hearing about how we add value to their customers, even though, you know, we're here to serve our customers mainly.
But the fact that people can build integrations that they can rely on and, you know, like can have just like a very easy and great experience and kind of like what the example I gave earlier about the agentic flows as well, just like everything just works, always makes me very happy because I think they just like normally underserved.
Like, you know, like if you ever use webhooks, you know how a terrible experience.
It can be with some providers.
And by helping our customers give their customers the best experience, I think their customers are getting a huge, huge difference.
For our customers as well, they stay up, they don't have to think about webhooks, they don't get paged, and they can be proud of what they've built.
But I think I'm really proud of what we help with their customers.
What teams are getting the most value out of Zvix today?
A lot of names that I can't say, unfortunately, but like names, household names that you all would know.
But there are like a lot of like some of the best growing startups out there.
So, you know, like Clerc, which I think if you've, if you ever built with an agent, you probably use Clerc and probably, you probably use them as well if you haven't built with an agent.
And, you know, we helped them.
I don't remember what the original estimate was, but like we helped them like shave months off their roadmap.
And They've just scaled and scaled and scaled and scaled.
They never had to think about webhooks ever again, literally.
It just scaled in the background, which is kind of a funny place for us.
I always enjoy and also maybe regret in some ways is that our customers forget that they're a customer because everything just works in the background.
I mean, they don't really forget.
They know if you ask them, but they don't even think about it.
It's not like a dashboard that you log in five times a day because everything just works.
Another two, if we're talking about fast-growing startups, like Resend, another one if you ever built with an agent.
Huge fan of Resend.
Yeah, they've been doing great.
And I think they've been leading the way in so many areas like DX before and now with agent experience and GEO and all of those things.
Yeah, so they've, again, been growing and growing and growing.
And I don't think they ever had to think about webhooks ever since they integrated it in the beginning.
Yeah, I think those, I mean, you know, we have like very large customers as well.
I just mentioned like fast growing startups that like large organizations like build time require even more time.
And they also often come with like enterprise requirements that they will just have to build themselves.
And it's just like a huge slog.
I think one of the really cool things, and I am a shill here, obviously, Swix is sponsoring the season, but I'm a huge fan of what the product is doing.
And.
One of the coolest things is that you're also making it easy for earlier stage startups to get started.
You're offering $12,000 in credits for qualified startups, $50,000 in credits for YC startups.
And it just takes so much of the headache off of the plate of many of these founders and founding engineers.
So if you are someone who's listening to this episode and are trying to level up your agent pronouns and your agentic engineering check out specs seriously link.svix.com slash c-o-t is a great product and you can get started for free and decide if you like it or not tom thank you so much for spending the time with us today it has been fantastic chatting with you i appreciate you getting down into the nitty-gritty of the decisions around the next primitives for the agentic era where can folks go to follow you and your work um i guess Twitter X is probably the best place.
So like at Tom McCohen.
Very simple.
Managed to get the handle.
Yeah.
Fantastic.
Well, Tom, it's been great chatting with you.
Really appreciate you taking the time.
And anyone who listened all the way to the end, make sure you like and subscribe.
Drop a comment if you enjoyed the conversation or let us know why we're idiots about something we said.
We would love to hear from it.
So thanks so much for listening, everyone.
And Tom, thanks again.
No, thank you.
See ya.