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

AI Engineer · 16 min · 149 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:01[music]
00:12So, I'm Avi, and I work on product here at Reducto.
00:16And before I dive in right away, I wanted to give you guys some more context on what Reducto is.
00:22Uh 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.
00:34I'll jump into the agents themselves in a second, but I'd like to talk about where we're at first really quick.
00:41In the last 3 years, we've processed over 3 billion documents across customers like Harvey, Scale AI, and top five global tech companies and hedge funds.
00:52Running 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.
01:04And getting AI to work on a clean document with a frontier model is not super hard anymore.
01:11We basically like you can throw something in the cloud, and you might get like 60% of the way there.
01:16But the hard part is production.
01:18Scanned documents, rotated pages, etc. And the model starts hallucinating because a large majority of enterprise data is unstructured.
01:27And so Reducto is a layer that sits between your model and that data.
01:31We 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.
01:41So, now that you know a little more about what we do, I'm going to dive into our main topic with something seemingly unrelated.
01:48Um I visited my girlfriend this past weekend, and she gave me a sticker from the movie Mean Girls.
01:54And basically, it was an agentified version of it.
01:56So, it says, "Get in, loser.
01:58We're building agent-first software."
02:00And in true software engineer fashion, I had to put a sticker like that on my laptop.
02:04And she got this from work, but she asked me like, "What is agent-first software?"
02:09cuz she doesn't work in AI.
02:11And as as I was like doing so or as I was thinking about it, I realized I have a lot of different answers.
02:17Building a really good harness, building a really good API, writing or iterating on prompts.
02:23All of these don't really um land on the agent being put first.
02:28They're more so just optimizing the model.
02:30Agent-first software is inherently an architecture problem.
02:35And so, I think that structure, that architecture, really comes down to one question, and that is who pays for the agent being wrong.
02:45And to that, I think there are like three buckets that you can put this into.
02:48So, you have auto mode to start, where you optimize for autonomy, you write a prompt, and you let the agent do whatever it wants.
02:55And 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, your users, etc.
03:06Then you have user-first.
03:08This is where you optimize the human interface, give the user all the knobs, and then you build on an agent that can't really do much, which is basically just a chatbot experience.
03:18You've both capped the user's understanding of the product because now they can't prompt it, and the agent's capability within as well.
03:27And lastly, the bucket that I think wins here is agent experience in service of the user.
03:33This is where the agent's capabilities are structured to give the model um rich and scoped 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.
03:47This 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.
03:58And here's how I discovered these buckets and came to that last point.
04:03At Reducto, we've been building tools that basically automate end-to-end document work through pipelines.
04:09Think that we first parse a document, then we classify it, or maybe split it into sections, and then extract from it.
04:16Um and that's in use cases like invoicing, contract management, and all these things that require human input.
04:22One 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.
04:31And that's a larger problem across the board because legacy interfaces were designed for kind of building that pipeline.
04:38Meanwhile, 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.
04:49So, the clear move to get here for us was an MCP server.
04:52Let the agent do the heavy lifting and only burden the user with thinking about their use case and writing a prompt.
04:59To 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.
05:10I gave it a really pointed prompt.
05:12I put it in the Slack, and honestly, it was pretty nice.
05:15Um to some extent, it should have worked in that setting.
05:18I knew exactly what I was doing.
05:20I was building a really curated demo, and that's why the standalone demo told me nothing at all.
05:26The real test happened when I gave the MCP to everyone on the team, and immediately it broke.
05:33And here's how.
05:35Someone would feed it a half-baked description from a customer call or maybe a Notion page, and the agent would just start going.
05:43It'd 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.
05:55And that is the root awakening of auto mode in production.
05:59The agent never really said that it's not sure.
06:02It handled with every tool that it had, and there was nowhere for a human to really validate or think about what was going on.
06:09We built something that could communicate with our system, but we hadn't built something that could actually work with it.
06:16And you'd think that the fix here is more detail on the system prompt or more model guidance, but realistically it's architecture.
06:24The whole file that we used to talk to the MCP, I deleted the entire thing in one commit.
06:30And what replaced it wasn't more tools.
06:33It was mostly fewer tools, but they carried the structure of actual work.
06:39So for example, instead of one create step of this workflow to uh call over and over, and just praying that the agent assembled right in the pipeline, I built tools that understood how our internal dashboard or our product works.
06:53For example, a common use case with Reducto is to route our classify endpoint that classifies documents into an extract node.
07:01And what that does is basically extract information downstream.
07:05And instead of basically letting the model guess this or figure it out through the prompt, I turned it into a single classify to extract tool.
07:14And after each step, the agent gets contextual guidance on what actually comes next, with certain tools even chaining automatically like this one.
07:23Rather than the agent having to guess or think about what is right versus being told what's right.
07:29Now the agent doesn't get to freelance the parts that we know are true.
07:34And since agents are stateless, we even added a snapshot tool.
07:38So 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.
07:50And that way they can reference what's actually there instead of guessing variable names, hallucinating, etc. By moving context out of the prompt and into structure, the agent stopped guessing and started referencing.
08:04And 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.
08:18So, 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
08:30so the correct path also becomes the simplest path that the MCP can take.
08:35So, we can build good pipelines now.
08:37We're done, right?
08:38Not really.
08:40Thinking back to auto mode, the agent was confidently wrong and no one could see it.
08:46Um that what we just talked about fixed that for building.
08:49The tools made the structure really legible and the human could follow what the agent did.
08:53But now the problem showed up at runtime.
08:56When the outcome itself that the agent is trying to build goes wrong, who can tell?
09:00For 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?
09:09And with agents it goes wrong quietly.
09:12So, instead of a seg fault or some actual error, um the pipeline runs across 100 documents and maybe it misses scan on page 30 or maybe the user didn't specify what types of documents
09:23were going into the pipeline.
09:26And basically both of these things are the same failure.
09:30The agent itself is very confidently wrong and the uncertainty that the agent has is completely invisible.
09:38So, everything that we did to fix this basically came down to one uh change, which was making uncertainty really legible.
09:46In our system or with Reducto, uh failures carry information.
09:50So, 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,
10:02which actually helped optimize the extract schema over time, and get more accurate document outputs.
10:08But, that's just the outcome uncertainty.
10:11The agent also has to surface its own uncertainty.
10:14When 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.
10:24And rather, it should ask, "I can read this two ways," and tell the user, "What did you mean?"
10:30And 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, etc., that Cloud Code and other like frontier harnesses offer, instead of guessing.
10:47So, we rewarded asking instead of guessing.
10:49And judgment doesn't live in the agent alone.
10:53This 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.
11:03So, 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.
11:14The agent basically satisfies what you wrote, and not the um outcome that you wanted.
11:21So, 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,
11:32then 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.
11:44So, going back to kind of all of these failure modes overall, we had initially an auto mode that nothing nobody could inspect.
11:53We had wrong answers that basically arrived in silence.
11:56And then an agent that passed the test by reward hacking or hiding what it did.
12:01And underneath, they're basically one shape where the agent had more autonomy and more access than the human could verify.
12:10And that intelligence lives in the construction overall.
12:14So, building the pipeline, generating the schema, and pulling in the right context is where the agent is more most powerful and where a mistake is the cheapest because the human is right there.
12:26By 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.
12:35And by using Reducto for the document layer, we can guarantee accurate parses and extractions for parts of the pipeline that we can't trust agents with.
12:44Where the agent operates, it earns trust by being verifiable, correct, and building trust in service of the user.
12:53And the whole conversation we had about legibility overall is what inherently pays off.
12:59Agents 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.
13:10And 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 cloud code sessions
13:23to understand how how was behaving.
13:26Where humans overrode the agent, where confidence of the model ran low, and where it asked questions.
13:32And because we added all this instrumentation, um it flowed back into the long-term guidance that the MCP had overall.
13:41So, the system got better at building pipelines by building more pipelines without us rewriting by hand.
13:47This then became a self-improving loop per org or per user that was building these pipelines.
13:53The 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.
14:05And 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,
14:17but rather I just exposed it in our Cloud Enterprise as product tools.
14:22And the sales team and various other people on the team started basically wiring it into their workflows.
14:27So, 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
14:37and then build a pipeline for that customer downstream.
14:41So, 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
14:53resource.
14:54And 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.
15:05Come check it out."
15:06And it actually paid off in these sales calls.
15:09And I hope the Slack reactions can also help gauge that a little bit.
15:13So, overall, a few months ago I would have told you that agent first is means that you have the best model, the best inference speed or intelligence of the model.
15:25And 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.
15:33To some extent, the agent doesn't go first.
15:36And 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.
15:45So, it's not just what does the agent connect to?
15:49Everyone's agent connects to everything nowadays, and Claude can make a new connector for you immediately.
15:54But, regard Beyond that, it's when your agent is really confidently wrong, who finds out and how fast did they find out?
16:03If you build for that, then you can build for something that people will actually trust with real work.
16:10And yeah, that's about it.
16:11Thank you, guys.
16:12And also, we're at Reducto's at a booth P8, and we are hiring for a lot of positions.
16:17So, please come check it out at reductoai.notcurious.
16:21Thank you.
16:36[music]