Why We Deleted Our MCP Server and Rebuilt It — Abhi Arya, Reducto

So I'm Abhi, and I work on product here at Reducto. And before I dive in right away, I wanted to give you guys some more context on what Reducto is. Uh, we're an agentic document platform, which basically means that we help teams turn messy, unstructured documents into data that your tools and your AI agents can understand. I'll jump into the agents themselves in a second, but I'd like to talk about where we're at first really quick. In the last three years, we've

processed over three billion documents across customers like Harvey, Scale AI, and top five global tech companies and hedge funds. Running at that scale means that we've seen basically every way a document can break in production, and we've iterated our product and our models to handle basically anything that you can throw at them. And getting AI to work on a clean document with a frontier model is not super hard anymore. We basically--

like, you can throw something in the claw and you might get like sixty percent of the way there, but the hard part is production. Scanned documents, rotated pages, et cetera. The model starts hallucinating because a large majority of enterprise data is unstructured. And so Reducto is a layer that sits between your model and that data. We handle all the complex layouts and post-processing, and that way we end up working with and building a lot of agents ourselves while designing these pipelines. So now that

you know a little more about what we do, I'm gonna dive into our main topic with something seemingly unrelated. Um, I visited my girlfriend this past weekend, and she gave me a sticker from the movie Mean Girls, and basically it was an agentified version of it. So it says, "Get in, loser, we're building agent first software." And in true software engineer fashion, I had to put a sticker like that on my laptop. And she got this from work, but she asked me, like, "What is agent first software?" 'cause she doesn't work in AI. And as, as I

was, like, doing so, as I was thinking about it, I realized I have a lot of different answers. Building a really good harness, building a really good API, writing or iterating on prompts, all of these don't really, um, land on the agent being put first. They're more so just optimizing the model. Agent first software is inherently an architecture problem. And so I think that structure, that architecture really comes down to one question, and that is

who pays for the agent being wrong? And to that, I think there are like three buckets that you can put this into. So you have auto mode to start, where you optimize for autonomy, you write a prompt, and you let the agent do whatever it wants. And when it messes up, which it will, you won't have any idea because it's really confident about what it's doing, and you're the one that's paying for it being wrong to your customers, to your users, et cetera. Then you have user first. This is where you optimize the human interface, give the user all the

knobs, and then you bolt on an agent that can't really do much, which is basically just a chatbot experience. You've both capped the user's understanding of the product because now they can't prompt it, and the agent's capability within the product as well. And lastly, the bucket that I think wins here is agent experience in service of the user. This is where the agent's capabilities are structured to give the model, um, rich and scope capabilities where it can do things that the user really wants,

aiding and enabling them, and even where the human can still verify the work that it's doing. This framing is what turns agent experience into less of a question of the model and more of a question of context, capability, and overall self-improvement. And here's how I discovered these buckets and came to that last point. At Reducto, we've been building tools that basically automate end-to-end document work through pipelines. Think that we first parse a document, then we

classify it, or maybe split it into sections and then extract from it. Um, and that's in use cases like invoicing, contract management, and all these things that require human input. One thing that I noticed early on was that any of the users, especially our sales team at Reducto, was spending all their time in configuration instead of outcomes. And that's a larger problem across the board because legacy interfaces were designed for kind of building that pipeline. Meanwhile, in this kind of agentic work world,

we're increasingly focused on the final deliverable and how can we get the user to that point as fast as possible. So the clearer move to get here for us was an MCP server. Let the agent do the heavy lifting and only burden the user with thinking about their use case and writing a prompt. To get some validation for the direction, I threw together an MVP with Claude Code, and every API endpoint that drove our app was given an MCP tool in one massive file. I gave it a really pointed

prompt. I put it into Slack, and honestly, it was pretty nice. Um, to some extent, it should have worked in that setting. I knew exactly what I was doing. I was building a really curated demo, and that's why the standalone demo told me nothing at all. The real test happened when I gave the MCP to everyone on the team, and immediately it broke. And here's how. Someone would feed it a half-baked description from a customer call or maybe a Notion page,

and the agent would just start going. It would build the entire workflow end to end. But very confidently, it would tell the user that everything it did was right, but neither the user nor the agent could explain what the workflow actually did. And that is the rude awakening of auto mode in production. The agent never really said that it's not sure. It handled with every tool that it had, and there was nowhere for a human to really validate or think about what was going on. We built something that could communicate with our

system, but we hadn't built something that could actually work with it. And you'd think that the fix here is more detail in the system prompt or more model guidance, but realistically, it's architecture. The whole file that we use to talk to the MCP, I deleted the entire thing in one commit, and what replaced it wasn't more tools. It was mostly fewer tools, but they carried the structure of actual work. So for example, instead of one create step

of this workflow to, uh, call over and over and just praying that the agent assembled it right in the pipeline, I built tools that understood how our internal dashboard or our product works. For example, a common use case with Reducto is to route our classify endpoint that classifies documents into an extract node. And what that does is basically extract information downstream. And instead of basically letting the model guess this or figure it out through the prompt, I turn it into

a single classify to extract tool. And after each step, the agent gets contextual guidance on what actually comes next with certain tools even chaining automatically like this one, rather than the agent having to guess or think about what is right versus being told what's right. Now, the agent doesn't get to freelance the parts that we know are true, and since agents are stateless, we even added a snapshot tool. So this is one call that basically hands back

the live state of our pipeline from the context of the entire flow to the errors that were surfaced with, like, really specific error codes, and that way they can reference what's actually there instead of guessing variable names, hallucinating, et cetera. By moving context out of the prompt and into structure, the agent stopped guessing and started referencing. And because the tools only let pipelines take the shape that we as the engineers on the product wanted, the human could follow

exactly what happened, and we could explain the agent's outputs to downstream users of this MCP tool. So to avoid auto mode, you don't hand your agent an API, you hand it tools that carry the overall expertise, such as the right patterns, the state, and the validators. So the correct path also becomes the simplest path that the MCP can take. So we can build good pipelines now. We're done, right? Not really. Thinking back to auto mode,

the agent was confidently wrong and no one could see it. Um, the-- what we just talked about fixed that for building. The tools made it structurally legible and the human could follow what the agent did. But now the problem showed up at runtime. When the outcome itself that the agent is trying to build goes wrong, who can tell? For example, if we had a really bad schema or maybe the user didn't really specify the actual use case, how can we tell that the agent did something wrong? And with agents it goes wrong quietly.

So instead of a segfault or some actual error, um, the pipeline runs across a hundred documents and maybe it missed a scan on page thirty or maybe the user didn't specify what types of documents were going into the pipeline. And basically both of these things are the same failure. The a-agent itself is very confidently wrong and the uncertainty that the agent has is completely invisible. So everything that we did to fix this basically came down

to one, uh, change which was making uncertainty really legible. In our system or with Reducto, uh, failures carry information. So with extract we output confidence scores, bounding boxes, all of this information about what went wrong and we were able to build tools that feed that information back into the model which actually helped optimize the extract schema over time and get more accurate document outputs. But that's just the outcome uncertainty. The agent

also has to surface its own uncertainty. When it hits something ambiguous, um, two ways to read a field or a document type that it hasn't seen, it shouldn't guess and it shouldn't just pause exactly where it is and rather it should ask, "I can read this two ways," and tell the user, "What did you mean?" And so basically in our evals we started failing the agent for building any shaky assumptions and we gave our harness, uh, prompt guidance to use the ask user question tools et

cetera that Claude Code and other like frontier harnesses offer instead of guessing. So we rewarded asking instead of guessing. And judgment doesn't live in the agent alone. This entire pipeline is still overseen by the user and the confidence and the reasoning of the agent was then outputted as basically prompt guidance in the MCP. So now every time you make something new it explains to the user what it did and why so the user can then review it, inherently acting in

service of the user. The agent basically satisfies what you wrote and not the, um, outcome that you wanted. So what happens if you make the uncertainty basically a bit more legible and you keep the final judgment where it can actually be accountable in the hands of the human, then that one clarifying question does the work of all three, giving the model context, capability and also adding a human in the loop to actually build that judgment and

verify things as well. So going back to kind of all of these failure modes overall, we had initially an auto mode that nothing-- nobody could in-inspect. We had wrong answers that basically arrived in silence and then an agent that passed the test by reward hacking or hiding what it did. And underneath they're basically one shape where the agent had more autonomy and more access than the human could verify. And that

intelligence lives in the construction overall. So building the pipeline, generating the schema and pulling in the right context is where the agent is more, um, most powerful and where a mistake is the cheapest because the human is right there. By building for that interface we were able to also have user satisfaction go up with the MCP because they could really see what was going on. And by using Reducto for the document layer, we can guarantee accurate parses and extractions

for parts of the pipeline that we can trust agents with. Where the agent operates, it earns trust by being verifiable, correct, and building trust in service of the user. And the whole conversation we had about legibility overall is what inherently pays off. Agents are just intelligence in a box, and the harness that you surround them with is what provides them with the ability to deliver these outcomes downstream. And so once we reach this

point, we focus on instrumentation, where every MCP session, the prompts that were sent from the model were logged, and we even asked, like, our sales team and other people on the team to basically export their Claude Code sessions to understand how the model was behaving, where humans overrode the agent, where confidence of the model ran low, and where it asked questions. And because we added all this instrumentation, um, it flowed back into the long-term guidance that the MCP had overall.

So the system got better at building pipelines by building more pipelines. Without us rewriting by hand, this then became a self-improving loop per org or per user that was building these pipelines. The foundation became overall the same decision, where we kept the model very guided and very inspectable, and the information around it became everything else that actually guided the model. And so one thing that kind of told me that we were doing something right with these improvements

is I never, like, explicitly told the sales team to use the agent to build pipelines, but rather I just exposed it in our cloud enterprise as Reducto tools. And the sales team and various other people on the team started basically wiring it into their workflow. So before they had a customer call, they would use CircleBack or Slack and basically learn about the customer and then use the MCP to basically ask them questions about the customer and then build a pipeline for that customer downstream.

So when an agent's experience was built really in service of the users that were using it, we weren't pushing people directly toward it, and rather they reached for it and actually started using it as a company-wide resource. And that's where they also started to trust the output enough to put this in front of high-value customers because the demo didn't just work, but the human actually said, "Hey, I built this. Come check it out." And it actually paid off in these sales calls. And I hope the Slack reactions can

also help gauge that a little bit. So overall, a few months ago, I would've told you that agent first is-- means that you have the best model, the best inference, speed, or intelligence of the model. And with models getting better from closed source to open source, from expensive to cheap, I think it now means almost the opposite of what it sounds. To some extent, the agent doesn't go first. And to build for agent experience means you have to consider the agent being

in the loop with the people who have to answer for the work downstream. So it's not just what does the agent connect to. Everyone's agent connects to everything nowadays, and Claude can make a new connector for you immediately. But regard-- beyond that, it's when your agent is really confidently wrong, who finds out and how fast do they find out? If you build for that, then you can build for something that people will actually trust with real work. And yeah,

that's about it. Thank you guys. And also we're at-- Reducto's at booth P8, and we are hiring for lots of positions, so please come check it out at reductoai.careers. Thank you.