ArovyAI / ArovyMCP - The Research Became the Map

At Arovy, I designed and prototyped ArovyAI and ArovyMCP, our take on the agentic experience managing Salesforce. I did initial research into chat experiences on leading AI products which led to a catalog of 127 chat components. That catalog became the backbone of our prioritization and planning exercises for the rest of the year as we delivered on both the user facing customer experience and the grounding and correctness aspects that made ArovyAI a trustworthy partner. I also built the evaluation suite and talk about that more in Vision Evals.

The Challenge

Arovy had a solid foundation of helping Salesforce admins understand how entities in their org are connected, how fields are used, and what's changed but towards the end of 2025 it was clear to me that our customers were moving towards agentic experiences and were starting to look for them both in the platform and connecting to the platform via Claude, ChatGPT, etc. After an early 2026 Customer Advisory Board meeting, I built a compelling case to leadership that the time was now. On the outside both a chatbot and an MCP server seem easy to design: an input box, some text bubbles, and wrap the API and you're done. I stood up prototypes of both and was quickly humbled by just how many components and interactions sit behind them. A "suggested prompt" chip is one button, but for us generic options weren't helpful. I suggested generating them dynamically, and now had to consider how long to wait, how much data was necessary for the suggestion to be helpful and how many suggestions to show. On the MCP side, "where is this field used" is a pretty standard question, but just wrapping the API caused Claude to stumble around looking for the right tool, filling up its context window along the way.

The Solution

Seeing the depth of the problem, I decided we needed more comprehensive research to give us a better base to build on. I reviewed all the major AI providers and their interactions using Atomic Design to categorize them from tactical elements (a suggested prompt button) to theory (building trust). The result was a catalog of 127 components in 15 categories, each marked as table stakes or differentiator, and each sorted into a bucket (31 MVP, 18 for V2, 23 for V3, 46 Skip, 9 to decide).

Next I built two prototypes against the MVP list. My prototype used real OpenAI streaming, a drawer that pushes the page instead of covering it, and page-context awareness so the assistant knows what you're looking at. On the MCP side I wrote a Python server over our REST API, collapsing our 72+ endpoints into about two dozen intent-grouped tools. Having both of these allowed me to bring a real experience to the planning meetings with Engineering, which helped bring clarity and speed to the process.

Then Engineering built the production systems: a .NET backend, a CopilotKit front end, and a C# MCP server with OAuth, all sharing one tool layer. I reviewed their first chat build against the prototype as the target experience, then refined it in place with my own PR, which removed 4,462 lines and added 478 across 22 files. After that I shipped the beta tag, inline entity links, Mermaid diagrams, launch prompt chips and three backend fixes myself.

The part I didn't plan for is what the catalog did after I was done with it. In September, our VP of Engineering took it as the source of truth for the ArovyAI objective in Shortcut, every component got a row in a delivery tracker, and the first quality epic, Grounding & Answer Correctness, was cut "at the component level" from one of its categories: 57 stories from one row of the research. The research had become the map.

Key Decisions & Rationale

• The assistant should be the product, with no mascot standing in front of it. We named it three times. Lumi was a lynx I drew for entertainment value, Ari came with a shield and ten or fifteen icon versions, and it shipped with no name at all as ArovyAI. Teams conflate personality with humanization: the UI can have character while the prompt stays plain, and if you create a thing with a name, it has its own brand now, which takes away from your brand capital. The company made the call, and my PR carried it out: shield gone, first-person copy gone, the answer reads like a document instead of a chat bubble.
• One tool layer, two doors. A customer should get the same answer whether they ask in our app or in Claude Desktop, so the in-app chat and the MCP server share one set of tools, and the MCP server is a gateway to those tools rather than an agent with opinions of its own. The pitch against Salesforce's own MCP was simple: through ours you can only read and change metadata, and crucially, you can't touch PII. The second door paid off with an enterprise security customer who told us the MCP was the added value because their company was pushing everyone toward Claude, and whose admin now runs SOX separation-of-duty audits through Arovy MCP in Claude Desktop.
• Never deny a feature we have, never promise one we don't. After launch I read the conversations in Pendo and found the assistant telling customers we had no MCP server, in about 6% of conversations, because no tool surfaced our own capabilities. I shipped a capability search tool to the backend with one rule: unbuilt features are omitted entirely, never listed as coming soon.

Outcomes

Arovy MCP went live for a first customer on August 13, 2026, and on September 29 I turned ArovyAI and the MCP server on for all customers during our customer success call. In the first week, 226 people were active in the app, 29 clicked the chat icon and 21 had a conversation, which told us the problem was discoverability rather than the answers, so I prototyped an "Ask ArovyAI" button to replace the generic floating icon. The questions themselves were what the research predicted: about 44% were some form of "where is this field used," and about half of conversations had a follow-up, which is why chat history shipped ahead of the prompt library customers asked for.

One security software customer told us, "I've spent a lot of time playing with the AI tool, and I have to say it's amazing," and rated their disappointment at losing it a 10 out of 10. Alongside the launch I started an eval suite, 202 cases with gold answers, which found seven tool bugs in its first runs; that work has customer data in it, so the version I can show is the one I built at home for my camera alerts.

Reflection

I expected the catalog to be a reference for me, and it turned into the thing that organized the team. That cut both ways. A row that says "source attribution / inline citations" reads like a requirement to an engineer and a CEO, and I spent a grooming session explaining that we don't want inline citations, we want a way for the customer to get to the data. Generic primitives need translating into what they mean for your product before they're put on a board, and I'd write that translation into the catalog next time instead of carrying it in my head. By the end the tracker had grown to 183 components with 48 done, and the quality epic was just getting started when I left. In my experience the research you can hand to someone else is worth more than the prototype only you can run, because the map keeps working after you've left the room.