Abhi Arya, who works on product at Reducto, explains how the company replaced its first MCP server, which exposed one tool per API endpoint, with a smaller set of tools that reflect real workflows. He frames agent-first software around the question of who pays when the agent is wrong, and compares three approaches: auto mode, user-first, and agent experience in service of the user. Topics include adding a snapshot tool for live state, making uncertainty visible through confidence scores and asking instead of guessing, and using instrumentation to create a self-improving loop. These are the speaker's account of Reducto's experience, not independently verified results. # Video Identity Observations **Video:** "Why We Deleted Our MCP Server and Rebuilt It — Abhi Arya, Reducto" ## Intended Audience - **AI engineers and technical practitioners** — the talk assumes familiarity with MCP, Claude Code, pipelines, and agent harnesses; the speaker references "software engineer fashion" and discusses architecture decisions in technical depth. - **Teams building agentic products** — the framing ("agent-first software is inherently an architecture problem") addresses builders deciding how to expose tools to agents. - **Conference attendees in an AI/dev ecosystem** — booth promotion ("we're at a booth P8, and we are hiring") and Slack-reaction references indicate a live developer-conference setting. ## Claimed Scope - A **single company case study**, explicitly scoped by the speaker: "At Reducto, we've been building tools that basically automate end-to-end document work." - A **generalized design thesis** drawn from that case study: three buckets ("auto mode," "user-first," "agent experience in service of the user"), with the speaker arguing the third "wins." - Company scale claims offered as credibility context: "we've processed over 3 billion documents across customers like Harvey, Scale AI, and top five global tech companies and hedge funds." ## Self-Description Evidence - **Company description (creator claim):** "we're an agentic document platform... we help teams turn messy, unstructured documents into data that your tools and your AI agents can understand." - **Speaker role:** "I'm Avi, and I work on product here at Reducto" (title renders the name as Abhi Arya). - **Hiring/recruiting signal:** "Reducto's at a booth P8, and we are hiring for a lot of positions" at reductoai.notcurious. ## Demonstrated (Non-Claimed) Presentation Patterns - Uses a **personal anecdote as the on-ramp** (the Mean Girls sticker: "Get in, loser. We're building agent-first software") before the technical argument. - Frames methodology as **iteration from failure**: an MVP that "broke" when team-wide, then deletion ("I deleted the entire thing in one commit") and rebuild with fewer, structured tools. - Employs **repeatable frameworks** (three buckets; "context, capability, and self-improvement") and a rhetorical closing question ("when your agent is really confidently wrong, who finds out and how fast?"). - Grounds claims in **internal adoption evidence**: sales team organically adopted the MCP, instrumentation of sessions, and improved "user satisfaction." ## Distinguishing Claims vs. Demonstration - The 3-billion-document scale, customer names, and self-improving-loop outcomes are **creator assertions**, not independently verified within the material. - The narrative arc (failure → architectural insight → organic adoption) is a **curated presentation of the project**, constructed for a talk rather than a raw engineering record. # Delivery Observation — "Why We Deleted Our MCP Server and Rebuilt It" (Abhi Arya, Reducto) ## Overall Style Conversational technical talk structured around a narrative arc: context → anecdote → framework → failure story → fix → lesson. The speaker works through the talk with frequent hedging fillers and self-corrections, but the underlying structure is deliberate and highly scaffolded. ## Recurring Phrases & Vocabulary - **"Basically"** — the dominant filler/hedge, used constantly to soften or paraphrase: - "we've seen **basically** every way a document can break" - "**basically** both of these things are the same failure" - "**basically** came down to one uh change" - **"Confidently wrong"** — a signature phrase, repeated at key moments: - "very confidently, it would tell the user that everything it did was right" - "the agent was confidently wrong and no one could see it" - "when your agent is really confidently wrong, who finds out" - **"Legible / legibility"** — a thematic keyword used three times: "making uncertainty really legible," "the tools made the structure really legible," "the whole conversation we had about legibility overall." - **"Really"** — a frequent intensifier: "a really pointed prompt," "a really bad schema," "a really good harness." - **Framing via questions** — key transitions are posed as questions: "**who pays for the agent being wrong**," "**how can we tell that the agent did something wrong?**" ## Teaching Habits - **Concrete before abstract**: opens the framework with a personal anecdote (the *Mean Girls* sticker: "Get in, loser. We're building agent-first software") before stating the thesis. - **Enumerated buckets**: presents exactly three categories — "auto mode," "user-first," and "agent experience in service of the user" — then tells the audience which "wins." - **Concrete counterexamples**: uses specific failure imagery — "misses scan on page 30," "two ways to read a field." - **Anticipates objections**: "And you'd think that the fix here is more detail on the system prompt... but realistically it's architecture." Also: "We can build good pipelines now. We're done, right? Not really." - **Callback structure**: the closing returns to the opening question — "when your agent is really confidently wrong, who finds out and how fast did they find out?" — mirroring "who pays for the agent being wrong." ## Communication Patterns - **Contrast pairs as a rhetorical engine**: "It's not just what does the agent connect to... it's when your agent is really confidently wrong"; "we built something that could communicate with our system, but we hadn't built something that could actually work with it." - **Quoting the system's dialogue**: voices the agent — 'it should ask, "I can read this two ways," and tell the user, "What did you mean?"' — and quotes users: "the human actually said, 'Hey, I built this. Come check it out.'" - **Narrative honesty about failure**: deliberately foregrounds the failure ("immediately it broke," "the standalone demo told me nothing at all") before the fix. - **Numbers as credibility anchors**: "over 3 billion documents," "a pipeline runs across 100 documents," "in the last 3 years." ## Uncertainty Notes - The single-transcript sample limits confidence: **"basically," "really,"** and **"confidently wrong"** recur often enough to treat as stable, but the **question-framing** and **callback** habits are judged stable partly from the talk's internal structure rather than cross-video evidence. - Some transcript lines show possible transcription artifacts (e.g., "notcurious" near the end, "how how was behaving"), so exact word fidelity in those spots is uncertain. # Observation: "Why We Deleted Our MCP Server and Rebuilt It" **Source:** Video `01a15ca6-e1fb-78c5-97bc-4fd39bf2a8e9` **Speaker:** Abhi Arya, Reducto (per curated title metadata; the transcript has the speaker introduce himself as "Avi," who "works on product here at Reducto") **Format:** Conference-style talk on designing agent interfaces (MCP server) for document-pipeline tooling **Nature of claims:** Experience-based position, supported by anecdote and self-reported company metrics. No independent evidence is presented. --- ## 1. Company Context (Self-Described) - **Reducto** is described as an "agentic document platform" that turns "messy, unstructured documents" into data for tools and AI agents. - **Self-reported scale:** over 3 billion documents processed in the last 3 years. - **Named customers:** Harvey, Scale AI, and "top five global tech companies and hedge funds." - **Stated positioning:** Reducto is "a layer that sits between your model and that data," handling layouts and post-processing. - **Stated limitation of frontier models:** On clean documents, a frontier model "might get like 60% of the way there." The speaker says production problems (scanned documents, rotated pages) cause hallucination. > *Source basis: self-report. The speaker presents these figures without external verification.* --- ## 2. Core Thesis The speaker states the thesis as follows: > "Agent-first software is inherently an architecture problem." - The central question for architecture is **"who pays for the agent being wrong."** - Improvements to the model, the harness, the API, or prompts are described as "just optimizing the model" and do not, on the speaker's account, put the agent first. - Later revision: the speaker says that "a few months ago" he would have defined agent-first as having the best model, inference speed, or intelligence. He now says it "means almost the opposite of what it sounds," and that "to some extent, the agent doesn't go first." --- ## 3. Three Architectural Buckets The speaker proposes three categories, each defined by who bears the cost of agent error. ### 3.1 Auto Mode - Optimizes for autonomy: write a prompt, let the agent act. - **Stated failure:** The agent is "really confident," so the user "won't have any idea" when it errs, and the user's customers bear the cost. ### 3.2 User-First - Optimizes the human interface by exposing "all the knobs," built on an agent that "can't really do much" (described as "basically just a chatbot experience"). - **Stated failure:** It caps both the user's understanding of the product and the agent's capability. ### 3.3 Agent Experience in Service of the User (Preferred) - Agent capabilities are structured as "rich and scoped," so it can do what the user wants while the human "can still verify the work." - The speaker says this reframes agent quality "less of a question of the model and more of a question of context, capability, and overall self-improvement." --- ## 4. Diagnosis: How Auto Mode Failed in Production **Narrative as stated:** 1. The speaker built an MVP with Claude Code, wrapping "every API endpoint that drove our app" as an MCP tool in one large file. 2. The speaker acknowledges the demo was curated: "I knew exactly what I was doing... that's why the standalone demo told me nothing at all." 3. When rolled out team-wide, it "immediately broke." 4. Users fed it half-baked inputs (customer-call notes, Notion pages). The agent built full workflows confidently, and neither user nor agent could explain what the workflow did. **Stated root cause:** > "We built something that could communicate with our system, but we hadn't built something that could actually work with it." - The speaker says the agent "never really said that it's not sure," and there was "nowhere for a human to really validate." - Stated remedy direction: "you'd think... more detail on the system prompt or more model guidance, but realistically it's architecture." --- ## 5. Architectural Response: Fewer, Structured Tools The speaker deleted the entire MCP file "in one commit" and replaced it with **fewer tools that carry the structure of actual work**. **Specific design moves described:** - **Composite tools:** A "classify to extract" tool replaces letting the model choose the routing. Some tools "chain automatically." - **Contextual guidance:** After each step, the agent receives guidance on what comes next. - **Snapshot tool:** One call returns "the live state of our pipeline," including flow context and errors with specific error codes. The speaker states that because agents are stateless, this lets them "reference what's actually there instead of guessing." - **Constrained shape:** Tools "only let pipelines take the shape that we as the engineers... wanted." **Stated principle:** > "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." **Stated result:** "Context" moved "out of the prompt and into structure," so the agent "stopped guessing and started referencing," and humans could follow what happened. --- ## 6. The Runtime Problem: Quiet Failure After fixing build-time legibility, the speaker says the problem moved to runtime: - Failures are quiet rather than explicit. Example: a pipeline across 100 documents "misses scan on page 30," or the user did not specify document types. - The speaker frames both as "the same failure": the agent is "very confidently wrong," and "the uncertainty that the agent has is completely invisible." **Two forms of uncertainty the speaker distinguishes:** | Type | Description | Stated handling | |---|---|---| | **Outcome uncertainty** | Whether the extracted output is correct | Extract outputs confidence scores and bounding boxes; tools feed this back to the model, which the speaker says "helped optimize the extract schema over time" | | **Agent uncertainty** | Ambiguity the agent encounters, such as two readings of a field | The agent should ask rather than guess. The speaker says evals now "fail the agent" for shaky assumptions and reward asking via ask-user-question tools | > "We rewarded asking instead of guessing." **Stated principle:** The final judgment should stay with the human. The agent's reasoning and confidence are surfaced in the MCP output so that users can review what was built and why. The speaker claims one clarifying question "does the work of all three" (context, capability, and human-in-the-loop verification). This is stated as the speaker's conclusion. --- ## 7. Instrumentation and Self-Improvement - Every MCP session's prompts were logged. - Sales and other staff were asked to export Claude Code sessions to observe where humans overrode the agent, where model confidence ran low, and where it asked questions. - The speaker says this data "flowed back into the long-term guidance," creating "a self-improving loop per org or per user" without manual rewrites. **Caveat implicit in the talk:** The speaker presents this as improvement. The talk does not quantify improvement, describe measurement methods, or show before-and-after results. --- ## 8. Adoption Claims - The speaker says he "never explicitly told the sales team to use the agent." Instead, it was exposed as a product tool in the Cloud Enterprise offering, and staff adopted it. - Reported workflow: sales staff use CircleBack or Slack to learn about a customer, query the MCP about that customer, and build a pipeline before the call. - Stated outcome: staff began "to put this in front of high-value customers," and the speaker says this "paid off in these sales calls." - The speaker references Slack reactions as a gauge, without showing them. > *Source basis: anecdotal and internal. No figures are presented for sales impact, adoption rate, or user satisfaction. The speaker says user satisfaction "went up," without quantifying it.* --- ## 9. Closing Synthesis - Earlier framing: agent-first means model quality. - Revised framing: agent-first means "the agent being in the loop with the people who have to answer for the work downstream." - Evaluation criterion offered: **"when your agent is really confidently wrong, who finds out and how fast did they find out?"** - Metaphor used: "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." --- ## 10. Qualifications, Tensions, and Unresolved Points **Qualifications the speaker stated:** - The MVP demo was "really curated," so its results were not evidence. - The agent is "to some extent" not first in agent-first design. - Frontier models are "not super hard anymore" for clean documents, but production is hard. **Tensions visible in the transcript:** 1. **Autonomy vs. verifiability.** The speaker argues against auto mode, yet also wants agents to be "rich and scoped" and to "do things that the user really wants." How much autonomy remains acceptable is not specified. 2. **Structured tools vs. agent judgment.** Tools were designed so "the agent doesn't get to freelance the parts that we know are true," while the speaker also argues the agent should exercise judgment by asking questions. The boundary between these is not defined. 3. **Strong guarantees vs. probabilistic components.** The speaker says "we can guarantee accurate parses and extractions" for parts of the pipeline, while elsewhere saying uncertainty must be surfaced because outputs can be wrong. The "guarantee" is not elaborated. 4. **Human-in-the-loop as safeguard vs. human burden.** The talk moves the burden of judgment onto users (clarifying questions, reviewing reasoning) while also claiming the agent is less burdensome to the user than legacy configuration. The speaker says legacy interfaces made users "spend all their time in configuration instead of outcomes," but does not discuss the review cost introduced by his design. 5. **Evidence strength.** The thesis rests on one company's experience. Scale, customer names, and adoption are self-reported. Claims such as "reward hacking" and "hiding what it did" describe failure modes but are not illustrated with specific examples in the transcript. **Unresolved questions raised but not answered:** - How is "confidence" calibrated for the agent itself, as opposed to the extraction model's confidence scores? - What counts as an ambiguity that warrants a question, and how is over-asking controlled? - What measured outcomes support the self-improvement loop? --- ## 11. Speaker Identification Note The curated title identifies the speaker as **Abhi Arya, Reducto**. The transcript introduces the speaker as "Avi" and as working "on product here at Reducto." Attribution in this record follows the curated metadata. The name difference may reflect a transcription error, and it is not resolved within the source. # Speaker & Provenance Record ## Video Identification - **Title:** Why We Deleted Our MCP Server and Rebuilt It — Abhi Arya, Reducto - **Video ID:** 01a15ca6-e1fb-78c5-97bc-4fd39bf2a8e9 ## Speaker & Role ### Abhi ("Avi") Arya — Creator / Presenter - **Self-identified role:** Works on **product** at **Reducto**. - Self-introduction at transcript start: *"I'm Avi, and I work on product here at Reducto."* - Delivers the entire talk; no other speakers identified in the transcript. - **Note:** The title names him "Abhi Arya"; he introduces himself as "Avi" — likely the same person, but this is an inference from metadata, not an explicit transcript statement. ## Provenance Facts from the Talk ### First-Person Company Claims (Reducto — self-reported, not independently verified) - Processed **over 3 billion documents** in the last 3 years. - Customers named: **Harvey, Scale AI**, "top five global tech companies and hedge funds." - Built an MCP server MVP, later deleted and rebuilt; internal sales-team adoption reported. ### Third-Party Tools & Products Referenced - **Claude Code** — used for the MVP and cited for "ask user question" harness tools. - **Notion, Slack, CircleBack** — used in internal workflows. - **Mean Girls** — pop-culture sticker reference ("Get in, loser. We're building agent-first software."). ### Referenced Concepts / Sources of Claims - Framing of "agent-first software" as an architecture question ("who pays for the agent being wrong") — presenter's own framing. - Descriptions of Reducto product mechanics (classify → extract, snapshot tool, confidence scores, bounding boxes) — first-person product claims. - No external citations, studies, or attributed third-party research appear in the transcript. ## Promotional Segments ⚠️ - **Closing promotion:** Reducto is **hiring**; booth **P8**; URL given as **reductoai.notcurious** (uncertain rendering; possibly a sponsor/host domain tied to the event). - The entire talk doubles as company/product exposition (Reducto platform capabilities), though framed as a technical talk. ## Comment Availability - Transcript mentions **Slack reactions** as an audience-engagement gauge ("I hope the Slack reactions can also help gauge that a little bit"), indicating a live event context. No comment-section availability is stated or inferable from the supplied material — **recorded as unavailable/unspecified**. ## Availability Limits - No curated metadata beyond title was supplied; speaker identity rests on the title and the transcript self-introduction. - Transcript ends with music; no Q&A segment captured. \>\> So, I'm Avi, 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 3 years, we've processed over 3 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 cloud, and you might get like 60% of the way there. But the hard part is production. Scanned documents, rotated pages, etc. And 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 going to 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?" cuz she doesn't work in AI. And as as I was like doing so or 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, your users, etc. Then you have user-first. This 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. You'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. 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 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. 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 clear 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 in the 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'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. And that is the root 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 on the system prompt or more model guidance, but realistically it's architecture. The whole file that we used 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 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 turned 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, etc. 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 that what we just talked about fixed that for building. The tools made the structure really 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 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 were going into the pipeline. And basically both of these things are the same failure. The 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, etc., that Cloud 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 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 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't 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 cloud code sessions to understand how how 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 product tools. And the sales team and various other people on the team started basically wiring it into their workflows. 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 have 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 did 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 a booth P8, and we are hiring for a lot of positions. So, please come check it out at reductoai.notcurious. Thank you. \>\> \[music\]