Don't hand a bazooka to an agent making a sandwich (Jeremiah Lowin)
The creator of FastMCP on why a skill file is a polite note, why enterprises pick MCP over CLIs, and why nobody is ready for a context layer yet.
Jeremiah Lowin is the founder and CEO of Prefect, and the creator of FastMCP. Jeremiah published earlier this year, A new dawn for Prefect, about a mission that has expanded from data pipelines to distributed systems to autonomous agents. Tristan asks a reasonable follow-up: What the hell is going on?
The answer starts with an accident. Jeremiah wrote FastMCP as a side project a few days after Anthropic introduced the Model Context Protocol. He posted it to Hacker News and Reddit, with roughly the pitch: This thing from Anthropic is cool in concept, it’s impossibly hard to use, maybe try this. It got a little popular. Then David Soria Parra at Anthropic asked to bring it into the official SDK, Jeremiah archived his own repo, and figured that was the last he would ever see of it. Months later, after OpenAI and Google both announced MCP support, he woke up to find his archived, do-not-use-this, go-somewhere-else repo sitting at number one trending on GitHub. So he did something unusual for a CEO with real customers and real revenue: he changed his own job for 60 days and went back to being a maintainer.
Jeremiah’s case is that MCP’s real product market fit is the enterprise, not the individual developer. He thinks a skill file is a polite note the agent is free to ignore, which is fine until you use one as a fifteen-step workflow. He’s also noticed a shift in how people talk. Pipelines get described in implementations, agents entirely in outcomes. As he says, agentic workflows are DAGs of outcomes, traditional workflows are DAGs of implementations. Underneath all of it is the question he asks everyone he meets and almost nobody can answer: did the agent actually do the thing?
They close inside the enterprise, where Jeremiah says he doesn’t even get to talk about interesting agentic applications because everyone is still stuck on security and plumbing. He walks the four-step journey he watches data teams take, from pointing an agent at the warehouse and taking the warehouse down, to a dbt-modeled curated view, to custom business logic, to shipping a UI over MCP Apps so a hundred thousand rows never enter the context window. And he explains why his own team told him to stop pitching the context layer in customer meetings.
Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.
The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Three ideas from the episode
1. A skill file is a polite note, so a fifteen-step workflow hands the agent a dangerous tool at step one. Jeremiah draws a clean line: MCP gives an agent new capabilities, a skill steers its behavior. The problem is that we’ve started using skills as workflow engines, because listing steps in a text file is the easiest thing we can do, not the best thing. Jeremiah’s objection is structural rather than aesthetic. If the workflow is a self-contained text file, the agent needs all of its capabilities at all steps at all times.
Say you’re a bank with a fifteen-step process where steps one through fourteen check that everything is correct and step fifteen moves the money. Put that in a skill and you have to hand over the money-moving tool at step one, and nothing stops the agent from reaching for it early. His team’s version, half joking and half dead serious: it’s like asking someone to make you a sandwich and handing them a bazooka in case they run into any zombies.
2. Agentic workflows are DAGs of outcomes. Traditional workflows are DAGs of implementations. Ask someone how their data pipeline works and they answer imperatively: I take this data, transform it this way, load it over there. Ask about their agents and they answer only in outcomes: this will be done, then that will be done.
Jeremiah's point is that every workflow tool we have, Prefect included, was built to express the first kind, which is why they all feel slightly unnatural in an agentic setting. That gap is where the hard question lives: how do you know when the agent is done? He asks it of everyone he meets. Most people guess. They check a file, skim the logs, or watch some weird proxy.
3. You can’t archive your way to a context layer, so the thing worth building is the context access layer. Tristan's objection: if context is every structured and unstructured artifact a company has plus everything in every employee's head, no product can hold it. Jeremiah's answer is continuous context. For his finance customers, the price of a stock at a given moment can be an input to an agent, and any attempt to archive that stream breaks the premise. Getting today's stock price is a much easier problem than curating a data lake, as long as there's a governed handshake to call through. The layer with real gravity is the one that exposes and governs access to the context, rather than the one that stores it.
There's a commercial wrinkle underneath. Jeremiah writes publicly about the context layer, and his own team asked him to stop bringing it into customer meetings, because the CISOs calling Prefect are calling about security, not vision.
Key takeaways
Lightly edited for clarity.
Prefect ships a workflow platform, a library for building MCP servers, and enterprise MCP infrastructure. From the outside that looks like an unrelated buffet. What’s the through line?
Jeremiah Lowin: I found that I even had to struggle to articulate that to my own team. Why are these things the same to me when they are very different, they sell to different people, they look different? But I see all of these technologies converging in a place where automated work can happen. It can happen away from human or even agent oversight, and we have a way to have confidence that it actually happened, that it was governed, that it was observed, that whatever we care about was achieved.
This idea of having confidence in automated work is the common thread for not just what I’ve done at Prefect, but my whole career, even once upon a time doing risk management in finance. It’s all about: do we have confidence in the behavior of something?
How did FastMCP actually happen?
Jeremiah Lowin: FastMCP comes along as an accident. It’s a side project of mine that I introduced a couple of days after David Soria Parra introduces the Model Context Protocol. Right place, right time, right developer experience. Honestly, I saw it as an opportunity for Prefect. For years I’ve been asking what it means that we’re considered a data, workflow, ETL-style automation company, when we’re just an automation company. What does it mean to update that business for what is obviously going to be an agent-dominated world?
For the first time in my career, everyone’s obsessed with automation. Automation used to be something I would beg people to care about. It’s a cost center, it’s a necessary evil, it’s an optimization. Now all of a sudden everyone can’t wait to automate everything. So MCP comes along and my interest was: is this the interop technology between the agentic world I want to be part of and the programmatic world I know how to work with? Is this the handshake?
And from a sponsor like Anthropic, who has the gravitas and the position to actually ram a standard through among a hundred other competing ones. I went to use it, and candidly, it was very hard to use. Impossibly hard to use. That’s where I went down a rabbit hole. I said I’ll make it easy to use, and I wrote FastMCP as this tongue-in-cheek thing.
How did it get attention?
Jeremiah Lowin: I think it was Hacker News and Reddit. The way I was treating it is: hey world, there’s this thing, it’s from Anthropic, I think it’s really cool in concept, it’s really hard to use, maybe try this. By the way, I’ve done that ten times with ten different things. It’s what we do if we’re building — put things in the world that maybe people will use. It got medium popular. A little popular.
What changed is that David, the creator of MCP at Anthropic, saw it, he liked it, and then he asked if we could contribute it into the official SDK. I introduced it at the end of November, and this would be the middle of December. At this time nobody cares about MCP except me, because I think maybe it’s relevant to Prefect, and David, who obviously has a vested interest in it. He’s like, I really like this developer experience, can this be the official SDK? And I was like, honestly, this is the coolest thing that’s ever happened to me. So we put it in the official SDK, and honestly, I thought that was the last time I might ever see it.
Then what happened?
Jeremiah Lowin: It would have been April or May, so about a year ago as we record this, OpenAI and Google both announced that they were going to support MCP. That’s when all hell broke loose and everyone started hearing about this technology and oh my God, it’s USB for the internet, and blah blah blah. I remember writing a blog post then where I screenshotted both Sam’s tweet and Sundar’s tweet. And I was like, oh my God, this is a moment.
The way I knew it was a moment is I woke up one day and overnight my repo was the number one trending repo on GitHub. My archived, don’t use this, go to the official SDK repo was the number one trending repo on GitHub. And that’s when I was like, hang on, hang on, there’s something here. I went and I dug in and I was like, but why are people coming to this repo that very clearly says go to the Anthropic repo instead?
What I determined is that there was this demand. It was a technology moving so quickly that there was demand for a high-level application ecosystem around it — auth and composability and interop with vendors, the kind of stuff you don’t typically find in an SDK.
You’d already contributed the code. Wasn’t developing it separately a bad look?
Jeremiah Lowin: It’s a weird thing. If I’m going to contribute the code into the SDK, then I don’t really want to also be developing it over here on the side. That’s weird, frankly. It’s a bad-faith kind of thing. What we determined is that there was enough demand for a high-level ecosystem, and that the SDK, in my conversations with David and others, wasn’t going to meet it. Not because they didn’t think it was a good idea, but because they wanted to be the best damn low-level SDK for working with the Model Context Protocol. They didn’t want it to be an opinionated framework. I was seeing demand in my archived repo for an opinionated framework like a FastAPI — it’s not an accident that they share a name in fast.
And so I changed my job very literally at Prefect. This is very fun for me, in an odd way. I said I’m going to go be an engineer again, I’m going to be a maintainer, and my job over the next 60 days is to sufficiently diverge these two projects so that at the end of 60 days, anyone looking at the standalone FastMCP and the FastMCP we licensed into the SDK could not say we’re acting in bad faith. So that’s what I did. At the end of it we’d gained another 10,000 GitHub stars. If I hadn’t dedicated that time, it would have incrementally diverged from the SDK, and it would have split the ecosystem instead of supporting it.
So there are now two FastMCPs. Is that confusing?
Jeremiah Lowin: It is a little bit confusing. What we did is we froze the version given to the SDK as version 1.0 so that it was canonical. Then we continued to develop FastMCP as version 2.0, and now it’s on version 3.0 as a matter of fact. We did our best to broadcast where that change had happened, so in truth we can say version 1.0 of FastMCP can also be accessed within the official MCP SDK. It does get confusing, though. There are two places where you can see FastMCP, they have very small API differences, and that’s enough to confuse people.
As a matter of fact, next month, maybe by the time this podcast is released, the FastMCP in the SDK is going to be renamed in alignment with the other SDKs that have evolved a similar object. It will be called MCP Server, which is a little boring, but I think will stop the confusion. It has been great that the concept of FastMCP is extremely well known as a consequence of that distribution. But I want that outcome, because I think we’ve created a really interesting high-level thing and it should be built over a clear low-level thing that doesn’t intersect. The MCP SDK is downloaded something like 10 million times a day. I don’t think it needs the crutch of my contributed code being identified as such, and we could benefit from the independence.
For anyone who’s only heard of MCP at a high level: what is it for?
Jeremiah Lowin: MCP at a high level is a protocol. It’s just a standard way for an agent to discover and use a remote API. The simplest way to think of it, and frankly the way it is most commonly used, is that it’s a remote tool registry for an LLM. The LLM connects to it, shakes hands with it, learns about all the tools it can call, learns how to call those tools, and ideally gets some instructions. Now it can send a tool request over the wire and get back a result in an expected format. That’s 95% of the use case.
What about the MCP-versus-CLI debate?
Jeremiah Lowin: I think the debate has a lot of merit, maybe surprisingly. As an individual running an LLM on my laptop, do I really need to stand up an MCP server and re-expose a lot of functionality when I’ve got a bunch of CLIs sitting right here? No. No, I do not. It’s all just code, my LLM knows how to write code, it’s fine. But in the place where MCP has intense product market fit, it has it for exactly this reason, which is enterprise. In an enterprise I absolutely do not want to be responsible for distributing code via CLI onto everyone’s machine and going through upgrade cycles.
The idea of having a central repository of business logic that I can version, deprecate, upgrade, control, and access control, and that doesn’t have to go on anyone’s machine or container, is a blessing. That is the only way an enterprise is going to distribute information and context and business logic to its agents. When we talk to security professionals, they’re like: there is no way we are putting CLIs on everyone’s machine so their agents can use it. We will use MCP instead. So all of the debate and the controversy happens at that individual level, where as an individual I don’t think it confers a huge benefit to me. But REST APIs don’t confer a huge benefit to individuals either.
Tristan, what did you see with the dbt MCP server?
Tristan Handy: We released our MCP server about a year ago now, and the adoption has been by far the fastest-growing thing that I’ve ever witnessed. It’s growing faster than dbt was when we first launched dbt. The thing that was surprising to me was just how much people wanted us to host a remote MCP server for them. I had been using it locally and lots of neat things came out of that, and I was like, what’s the problem, why do you guys care so much that we host the thing for you? But it’s exactly what you’re describing: the utility is that you need a common set of logic that can be called from lots of different surfaces.
How do skills and MCP relate?
Jeremiah Lowin: A skill is a way to steer the behavior of your agent. MCP is a way to actually give it access to new capabilities at all. Strictly speaking, skills are a very amorphous, nebulous, kitchen-sink kind of thing, but in the way they’re used 99% of the time it’s essentially a polite note to your agent. That’s how I would think about it. The agent is actually free to ignore the skill. In fact, sometimes it does, which is very frustrating when you have this thing that’s supposed to plug in so organically.
A common thing you’d see in a skill six months ago is behavioral steering. I have a skill that helps my agent explain things to me the way I like to be explained to, which is not as an idiot but as someone who still needs to learn. The most important sentence in it is: talk to me like I’m a colleague who knows what you’re doing but hasn’t been looking over your shoulder. And it just magically changes everything. What’s happening today, though, is you’ll open up a skill and it’ll be like, okay, do the following. Step one, blah blah blah. Step two, blah blah blah. Step three, do not skip this step. Step four, you better have done step three before you get here. I wish it were a joke. It’s because the easiest thing we can do for guiding an agent through a series of steps is give it a polite note that says you’re going to do this, then this, then this.
Walking an agent through a workflow is something we don’t have great primitives for, so we resort to listing the steps and hoping that it works.
So what’s wrong with treating a skill as a workflow?
Jeremiah Lowin: Why I don’t like skills as workflows is that the agent needs all of its capabilities for all steps of the workflow at all times, if the workflow is a self-contained text file. For some of our customers, and some of yours certainly, who are regulated, large, or want to take any action that might be irreversible or affect the business itself — let’s say moving money between accounts if you’re a bank — if I have a fourteen-step process that checks everything is correct and then step fifteen is to move the money, but it’s in a skill, that means I have to give the tool for moving the money to the agent at step one. And that means no matter what, there is a risk that the agent decides to use the tool, just because there’s no strict scoping of the context and information available to it.
My obsession right now, and something we’re working on at Prefect to ship later, is how we actually let you build agentic workflows that are not fifteen steps in a polite note, but fourteen steps and a success criterion — analogous to a data quality check — and then a second step that gives it the potentially dangerous tool subject to that check.
The way our team talks about it, half jokingly, half dead serious, is that it’s like saying: hey Claude, can you go make me a sandwich? And by the way, here’s a bazooka in case you run into any zombies. I don’t know if it’s going to run into any zombies, but now it has a bazooka. Who knows what it’s going to find? Maybe there’s a note that someone left in the fridge that says use the bazooka. We don’t know. And so I’m uncomfortable with these open-ended workflows that boil down to polite notes.
Tristan builds workflows where the steps are deterministic and the agent gets called into narrow slots. Is that the right pattern?
Jeremiah Lowin: I think it’s neither good nor bad. There’s a spectrum from micromanagement to complete autonomy, and what we’re seeking in workflows is a way to move along that spectrum for whatever’s appropriate in the moment. Hypothetically, if you’re moving data from system A to system B, why bring an agent in at all? Do it completely deterministically. I would be uncomfortable with anything that said that type of outcome was wrong.
If we want to nerd out for a second, the key question in that spectrum is actually: how do you know when the agent is done with its job? In the micromanagement case it sounds almost like a completion. Hey, I need help filling this thing out, send me back the thing so I can go on with my code. That’s well known. In the autonomy case, where the goal might be very open-ended, it’s actually quite hard to know when to retake control from the agent.
Every time I hear someone’s working with agents, I’m just like: how do you know they did what you wanted? A lot of people don’t. They guess. Oh, I look at this file. Oh, I go look in the logs. They look at some weird proxy. It’s a surprisingly hard question to answer. Did the agent actually do the thing?
What’s changing in how people describe their workflows?
Jeremiah Lowin: When we talk about data pipelines, we talk imperatively. I’m going to take this data, transform it in this way, load it over here. These are the steps I want done. And when people talk about their agents, I hear them talk exclusively in terms of the outcomes they expect the agent to achieve. This will be done, then that will be done, then this will be done. So when I look at why something like Prefect, which nominally satisfies a lot of these workflow constraints, feels slightly unnatural in an agentic setting, it’s because our entire paradigm is around helping people express how they want things done.
I have this almost academic thing I’m pulling on, which is that agentic workflows are DAGs of outcomes, whereas traditional workflows are DAGs of implementations. A Ralph loop is basically when we force an agent to keep doing something over and over until it inexcusably, with no possible exception, has achieved the goal. That’s interesting, because we have a very clear conception of the success criteria and absolutely no insight into how it should be achieved. So this goal-seeking behavior is the ultimate version of: I do not care what the implementation looks like, I don’t even care how you go about it, I am only obsessed with knowing whether my goal is achieved.
Part of the shift I see on the frontier is that people care less and less about how the thing is done, and more and more about putting guardrails around what it means to do it at all.
Tristan spent eight hours building a documentation agent and couldn’t define what a good column description was. Can most things have a clean definition of success?
Jeremiah Lowin: That’s such a good question. No, I actually don’t think so. Part of what I’m trying to solve for is a class of workflow that does have certain characteristics. We do know what success looks like. I’m also very interested in workflows that are repeatable, need to be audited, need to be governed in some way, or are scheduled or non-interactive. There’s this class of delegated work — the overnight shift, basically — where the question is how we know what it’s doing. That class is ripe to be agentic.
For fully open-ended work, what I’m doing may not be the right paradigm, and a ton of work feels that way. I actually think that’s where chat interfaces are so rich and fantastic, because you can lend the agent your curiosity in that form. Once you’ve done that exploratory work, it may be that you now have a rubric for what a good description is that you want to pass on. And now all of a sudden we can canonicalize the workflow. We can make it real. What you described is exploration, and that’s different. It’s almost not automated in a primal way. It’s interactive.
Do we end up in a world where practitioners have automated the work but still validate every single output?
Tristan Handy: I don’t think we want the future where data practitioners have automated away all of their actual work, but they still need to come and validate the results of literally every single thing the AI has done on their behalf. It is actually often doing the work that allows you to know whether the work is correct or not. And just being in the position of approving pull requests that somebody else has done all day is, I don’t think, a very good job.
Jeremiah Lowin: I don’t think so either. Also probably not a great job for a human, given what we see AIs doing. We have to bottle and sell that spark of intuition that makes us claim that we know something about the data. And every bone in my body wants to say, hell yes, we do — that’s why we are data people, because we know there’s something. Why can’t an agent produce a good graph? Why can’t an agent write a good analysis? Why do they get tripped up? Why do they calculate daily average users differently every single time? Because they are probability models themselves. Because they don’t have an intuition except what they’ve scraped off the internet. And I believe there’s an opportunity for us to inject some of that into them.
What are all the ways this gets harder inside an enterprise?
Jeremiah Lowin: My experience right now, and I just can’t escape it, is that we don’t even get to talk about the cool agentic applications, because we’re dealing with core low-level infrastructure and security requirements everywhere. Everyone has this problem. It’s a very interesting technological shift: usually you have something crazy creating problems for CISOs and they’re just like, no, absolutely not, we’re not ready yet. Instead the CISOs are the ones calling up saying we need a solution to this, because we need to use AI in our business.
Horizon is our product in this space, an MCP gateway and a governance layer for helping get these things safely registered, scrubbing PII from ever leaking out of the MCP server into the agent’s brain. How do we make sure we know how the agents are connecting to our business? That’s where we are right now. I don’t even know if that’s the bottom of the first inning for what we aspire to when we talk about AI in the enterprise.
Where do those calls come from?
Jeremiah Lowin: It is being deployed now. Inside most enterprises there’s at least one team really starting to do fascinating, interesting agentic work, and a lot of times that team wanting to distribute their work into the organization is the cause of the call. The CIO feels like we should want this to happen. They’re asking for it, and yet they literally don’t know how to do it. Or: I asked seven people, I hear that they have seven MCP servers, they don’t know who else is using them, they don’t know how to tap into ours. Many of them did go far down the shadow IT pathway, and now the next wave of calls are people who are worried they’re going to go down that road.
What we observe is that usually that ground-zero team is a data team, because they’re the ones using MCP to avoid having to write yet another pipeline, yet another one-off, yet another refresh. Instead they’re saying, look, just connect your agent to the data and you figure out what you want.
What does that journey look like?
Jeremiah Lowin: It started out with: here’s the MCP server, connect to the warehouse, what happens? They take down the warehouse. So now we put something in front of it. Maybe we use dbt to model out the data, so instead of connecting directly to the warehouse you’re connecting to a curated view. That’s step two. Step three: you’re asking about things we don’t even have in our semantic layer because they’re business-logic adjacent, so I write custom code and deploy it in the MCP server. And now you want graphs.
There’s a new extension called MCP Apps where we can ship a UI over the server. So you’re connecting through my handcrafted business logic, through the dbt layer, into the warehouse, pulling out 100,000 rows which by definition go into your LLM’s brain. You don’t want that. Let me ship you a UI that graphs it instead. It bypasses the context window entirely and you get to make a decision.
All of a sudden we’re where the data industry was sure we’d get five years ago, with a different technology stack in the middle. We didn’t know AI would be part of it: user gets graph from raw curated data without an intermediary. What’s changed is the agent in between, and the danger it runs off and does something else. Especially in a regulated environment, where if an agent is part of a decision tree, that needs to be explained to a regulator.
What can you actually solve at that layer?
Jeremiah Lowin: We can become the central governance plane between what can be done in a business and the agent. We don’t have to be the only provider of that. But as long as you guarantee that anything that can be done in your organization, and any agents you have, run through some layer — ideally ours, but some layer — then no agent can take any action against your business without it being audited. It has to go through a governed layer.
That’s why we don’t want the shadow IT story. We don’t want MCP servers being spun up, we don’t want folks installing CLIs. We want it to go through a place where that activity can be observed. That’s the number one concern. My attempts to even get away from that concern — nobody wants to talk about anything else.
Is that what you’re calling the context layer?
Jeremiah Lowin: Not exactly, no. I would love to be talking about the context layer. This is the infrastructure that even permits us to have that conversation. It was really disappointing for me. I would show up, and my team got to a point where they’re like, don’t talk about that stuff, it’s confusing, we’re going to stop bringing you to meetings. Literally, that’s how it went down. And I was like, but then the agent will be able to be orchestrated from this. And they’re like, nope. Security is the problem they need to solve. Security is the problem they’re coming to us to solve. So this is the base layer.
Now let me take 30 seconds on the context layer, because once you have that handshake in place, it’s a beautiful thing and it works. The agent comes along, and that agent at this moment is a dumb while loop. It’s just sitting there ready to process tokens. It has no context for anything. All of a sudden we have a chance to give it an entire worldview in that moment.
We can say: this is your knowledge, these are your skills, these are the things you’re allowed to do. If at every second of every day you can change what that is and give it the right information at the right time, you can guide the behavior of that agent without ever writing a line of agent framework code. You just take that while loop and say, listen, this is who you are and this is what you can do, take an action. Great. Here’s who you are now and here’s what you’re allowed to do, take another action. We can really govern that behavior without ever owning the agent implementation.
But context is every piece of structured and unstructured data plus everything in every employee’s head. What makes you think one product can do that?
Jeremiah Lowin: Let’s look ahead twelve months and pick an example I think breaks all current technology, which is continuous context. We have a ton of customers in finance, and this is very real for them, where the price of a stock at any moment could be an input into an agent. We could take a very pedantic view and say each one is an event and it can all go into a data lake somewhere. But the point is that this is a continuous stream of changing context, so any attempt to archive it breaks the assumption.
The goal is to plug the agent into the context stream in a way that by construction can’t be predicated on prior storage and archival of that stream. If I want to know the price of a stock today, that’s actually a much easier problem than curating a data lake. I call an API to hit a provider that tells me. And you can imagine continuous context in every industry, not just finance — logistics, supply chain, climate. This conversation is continuous context.
I think part of the business context will always come from the data lake, where it’s been archived and curated and organized, and then there will be some version that’s this continuous wash of information accessed through what we’ll call an MCP tool. Even in a world where we perfectly curated every document form of context, I still see a world where having a handshake layer, where we can give an agent access to a specific set of business logic that informs its context, is a necessary ingredient. Now, I don’t have a technology that does that today. I actually don’t know a technology that can do what I just described.
So has the ambition shifted?
Jeremiah Lowin: As much as, in the blog post you quoted at the beginning, I wanted to be part of the context provider layer, I am now increasingly pulled to solve a problem in the context — I guess I’ll call it the access layer — which is adjacent, more primordial, I don’t know. It’s where we just see this gravity now, and so it’s where we’re shifting. It’s a very strange argument, because it collapses quickly. In the same way when people are like, why do we need MCP, we already had REST?
And the answer is because we needed a way to have a compressed standard and it happens to be called MCP. It’s a terrible answer. It’s a tautological answer. It’s also very true. MCP exists because as a world we decided this is a standard we’re going to get behind. And it’s almost never true that the standard we all agree on is globally optimal. It’s just what we all agreed on.
My personal journey started as: we’re data people, we’re going to assist in the delivery of the context itself. And it transitioned to: we are automation people, we are going to assist in literally the delivery of the context, not the contents themselves. Why can’t you run CLIs? Well, that’s just not how the business is getting done. I have found my own inner peace that sometimes there are just ways that people need to do things.
You’ve heard me mention a couple of times in this conversation that I’m thinking a lot about regulators and auditors. That’s deeply informed how I think about what one can do. If we were having this conversation twelve months ago, or even probably six months ago when I wrote the blog post, I would stand here and say we are going to be the place where the collected curated context is exposed to the agents. And now it’s where it’s exposed. I’m working more closely with partners on what the content of that context is.
If we define the moment Prefect officially becomes an AI company as the point where Horizon revenue eclipses Prefect Cloud revenue, are you there yet?
Jeremiah Lowin: We’re not there yet. Horizon as a commercial product is only about two months old. So not quite yet, but I actually think it’s going to come from a different direction. Prefect Cloud this summer will be fully agentic workflows, as opposed to just data workflows. So I think someone arriving at Prefect in July or August would think that Prefect Cloud is the AI business and Horizon is the AI infrastructure business, as opposed to today, when I think they’re viewed as the opposite.
My goal explicitly is that Prefect across our portfolio will be viewed as an AI business this summer. Part of it will be an AI workflow business, part of it will be an AI infrastructure business. I do think the Horizon product is growing fast enough that it could overtake Cloud, certainly in net new, within the year. But it’s so young that we’re not going to talk about it as the dominant product quite yet.
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.