Smithers

My name is Fucory. I'm building Smithers. I'm excited to tell you about it.

So when I first started building Smithers, I really didn't expect anyone to get it. It felt like I was solving problems that weren't going to be a problem for anybody for six to twelve months minimum.

What kind of shocked me at the beginning was normally when you build projects, anyone who builds stuff knows this, people kind of just churn quietly. They don't really complain about anything. What I saw with Smithers was people immediately opening issues, people immediately building third-party integrations, people writing three-paragraph open letters to me begging me to fix all the bugs. And a lot of really strong signals that made me keep going on it a lot further than I was planning on going.

And workflows are hard. When you build workflows for the real world, things go wrong. And if you don't plan ahead expecting things to go wrong, what's gonna happen is you're gonna create a mess. The worst thing that can happen is things go halfway right, and if things go halfway right, you often need a human to go in there and fix everything for you.

So Smithers tries to solve this by basically doing the hard engineering work for you. When you use Smithers, everything's reliable by default. You don't have to actually engineer that. And you can build workflows extremely, extremely fast. So in Smithers, we have over six thousand evals that are only testing that an agent who's reading the Smithers docs is capable of one-shotting either any monitoring ask you have of it, of what is my Smithers workflow doing right now, and also being able to one-shot a Smithers workflow.

You basically just use whatever harness you want. It supports every harness, every model. You just type what you want, and if the workflow you type doesn't work the first time, we consider that a bug, and we encourage everyone to open an issue immediately. We'll add it to our eval set.

So after you type the prompt, it'll write some code. It looks something like this.

It will also create a custom UI for your workflow.

And then when something goes wrong, here I'm getting rate limited again. Smithers will actually park itself and wait until my rate limit's over and then restart itself. This is just one of many ways that Smithers is durable by default.

The architecture of Smithers is really interesting. I'd love to talk to anyone technically inclined about it, but the impact of it is basically just trust.

In Smithers, you can see every single frame, frame by frame, that the workflow's is doing, and you can even rewind and time travel back to a previous frame at any time.

And this is why people went from just using Smithers to write code to starting to think about building real products. This is a very recent thing that started happening, is people started realizing the, reliability of Smithers is actually a great way to build products in the future.

And, one of the biggest, biggest, philosophies of Smithers is that the agentic world is a changing meta. It's a moving target. So Smithers is built not in some opinionated way by me. It's actually built so that whatever your opinions, you can inject them into Smithers. And if they change tomorrow, you can inject that into Smithers. And that's not only your own workflows, but that's Smithers itself. So we follow eval-driven development in Smithers. And basically, if the evals tell us that some, some prior conclusion we came to is no longer true based on the latest models or the latest meta, Smithers is going to change with it.

And workflow automation, as models get better, is going to become absolutely huge. So we want this to change. We want models to get better, Because when models get better, they get capable of building bigger and bigger Smithers workflows that can run for hours, days, weeks. And what I'm really excited about is to see the first Smithers workflow that just runs forever indefinitely.

And people will keep building on Smithers because Smithers is really fast and really durable.

And we're open source. We're gonna to be open source forever. We believe anyone who's not open source is a coward. We don't believe there's a moat there. We believe the moat is doing the last mile for enterprise. We have a really good team. Very, very good community who really knows what they're doing.

Just curious, like if you've, done like A/B testing, in comparison to just like Fable for, like Fable workflows versus like your workflows, and also like coding evals and that kind of stuff.

I love this question. I've definitely done evals. So when I first built Smithers, I knew I was building like a lot of inevitable stuff. I said the moment I built it, "This is going to be in every harness." Six months later when, Anthropic adds workflows to their harness, that's actually where a lot of people who were kind of on the fence about Smithers started to really like be like, "Oh, Will was on to something." It, really helped me get a lot of people over the line. I think what they shipped so far is like the Smithers MVP.

My favorite question that I love for people to ask is like, "What is your moat given like Anthropic is like inevitably gonna build this?" And I just don't believe there is such thing as a software moat. I just think it's very important that you like are very fluid and you keep moving, you keep pushing the boundary. I do think like within six months, Anthropic's gonna have feature parity. So I don't like to talk about the piles of features which I could rattle off. Like Anthropic does not support running workflows across many machines. Anthropic does not support, running workflows like with different agents.

In terms of evals, it's very interesting. What we're seeing is that, because Anthropic, and I'm just guessing here, because they RL'd their agents on building workflows, when Opus 4.8 came out, and then even more so when Fable came out, it was like pretty shocking how good those were at building workflows. I think like it was very much like a zero to one moment for everyone using Smithers. Before that happened, you had to really like kind of prompt the agent. Like you had to be like good at using Smithers. You had to really like, like spell it out for the agent. Like, "Hey, I want you to do this review loop.

I want you to do this like back pressure. I want you to like parallelize. Yeah, I want you to..." You had to really like kind of like micromanage. Whereas, kind of like my vision of just you talk to the agent and the agent figures out the best way and Smithers is just a tool for your agent, you don't actually have to learn Smithers. Like all these things I was saying but weren't actually true became true when Fable came out, and that was really exciting.

And then you don't see the same with the ChatGPT models. So Sol's a great model, but like the way I'm using Smithers today is I usually have Fable write all my workflows. I have Sol kind of as the workhorse, and then I have Fable like review stuff at the end. And then in terms of just benchmarks versus like cloud workflows, like it depends on the benchmark. It's the simplest benchmarks, kind of the smaller tasks is where I really need to catch up.

It doesn't underperform in terms of quality, but it does underperform in terms of speed, like how fast do I get a result. And that's something we're working on actively now. I actually started changing my benchmarks to actually measure speed. When you go longer workflows, Smithers does perform a lot better because we have higher level, abstractions. I'll actually be publishing benchmarks publicly soon.

Do you have a, like a favorite customer story, like who's improved the most because they use Smithers? Or just pick a favorite guy to boost from your community.

Yeah, that's a good question. Honestly, my favorite customer story was this. I don't know who they were. They wouldn't tell me who they were. They said they worked at a very large public company, but they're like, "Oh, I, I'm too chaotic on Twitter. I can't tell you what company. Sorry." But they messaged me and told me, "Hey, I used Smithers. It worked great, but I hate TypeScript. So the first thing I did with Smithers is use Smithers to rewrite Smithers in Python, and it's amazing. Thank you." I thought that was the funniest thing I've ever heard in my life.

And then, Fucory, someone told me that you one-shotted an EVM client in Zig and were, somewhere high up on the Anthropic leaderboard. Is this true? And also, if so, does that make you the only person who's written an EVM client in two different languages with TEVM as well?

About a year ago, I had a goal of just like getting really good at using agents, and what I did is I'm like, "What are agents really bad at?" Like building software where if you have a single bug, you lose all your money. That's definitely it. And building high quality. So like what I tried to do is I made the goal of defeating, my mortal enemy, Georgios, and building something better than Revan. But the short spiel of it is I learned that a lot of agentic engineering is what I call hill climbing, where you just kind of burn more tokens to get a better result.

And the way I hill climbed with the EVM is, using the back pressure of the fact that there's existing EVM implementations, existing tests that I can run, to guarantee correctness, combined with the fact that like sometimes the best way to plan is to just do the thing and then reflect on why did my plan suck. So a lot of the building the EVM was actually building EVM, asking the agent to reflect on what went wrong, throwing away its code, yelling at it to do it again, and just repeating that over and over and over and over again until basically I had like an EVM building factory, combined with like using agents to like up up-level myself in how to build performance engineering stuff.

And eventually I did like hit my goal of building like the fastest EVM ever in terms of benchmarks, and then I immediately abandoned the project.