Vollständiges Transkript anzeigen (601 Wörter)
What is "if" and why does it matter if you are building agents? The fastest way to answer that is to picture building the same agent twice. Once without it, and once with it. Say you want to support agents. It answers: customers, looks up accounts, issues refunds, when they are warranted, and sends you a summary every morning.
Now, try to actually build it. Before it answers a single customer, you need a Slack app with tokens and webhooks, auth for your billing providers, somewhere safe to run code, a cron job for the summary, a plan for when it crashes mid-conversation, and a human in the loop before any money moves.
That’s a lot of climbing, and none of it is the agent you are trying to build. It’s the scaffolding every agent needs before it can do anything. And today, you build it from scratch every time for every agent across every team. With "if," the scaffolding is already there. All that's left is the agent itself, and that’s just a directory. One instructions.md file at the root, and five folders: Channels, connections, schedules, skills, and tools.
Here’s what each of those five folders does in this "Nimbus support agent" demo. Channels are where people actually reach it. The Slack app, in this case, is one file, backed by Vercel connect. So there is no bot token, no signing secret, no webhook code. And if you want to use Discord, Teams, Telegram, or even SMS, it’s one file each.
The auth for your billing provider becomes a connection. MTP or open API, and the model never sees a credential. The code for looking up an account is a TS file in tools, executed in a Vercel sandbox. The morning summary is a schedule, and that one can literally be another markdown file with a cron expression on top. And once you deploy, that’s a live Vercel project.
Where that’s a refund or a credit, comes from a skill, another markdown file. But "if" only loads it into context when the conversation actually needs it, instead of carrying out every policy on every turn.
That connection, stripe TS, comes with that approval gate baked in. So if someone asks for a refund in Slack, and it goes the refund tool is gated by name, the agent doesn't just do it, it parts right there in the thread with an actual approve or deny button. Another, underneath every turn is a Vercel workflow, checkpointed step by step. So if the conversation crashes midway, it picks up where it left off, no matter how long the approval takes.
So if I click approve, the refund actually goes through, right there in Stripe. And of course, you have observability. You will find agent runs in the same dashboard where you already watch the rest of your Vercel projects. Every run lands there, the trigger, the turns, tokens in and out, and what it cost. That’s the same agent twice. Without a framework, the plumbing is software you own forever. With "if," it’s a directory, and then the plumbing is "if" jobs. With a team, they get to keep it secure, fast, and reliable.
Every part of that: channels, connection, schedule, skills, tools, used to be its own project. Now, it’s one line in a file. We, at Vercel, run hundreds of "if" agents in production today for all kinds of use cases. For example, support, data questions in Slack, sales, or content review. "If" is open-source. You can self-host it, and your first agent is one command away. Start today at eve.dev.