Their findings on KV-cache invalidation are spot on for a single-context approach.
Strata's architecture is philosophically different. Instead of loading a large toolset and masking it, we guide the LLM through a multi-step dialogue. Each step (e.g., choosing an app, then a category) is a separate, very small, and cheap LLM call.
So, we trade one massive prompt for a few tiny ones. This avoids the KV-cache issue because the context for each decision is minimal, and it prevents model confusion because the agent only ever sees the tools relevant to its current step. It's a different path to the same goal: making the agent smarter by not overwhelming it. Thanks for the great link!
We also provide an open-source version for Strata so that you can have full control. You can self-host it on your own infrastructure, so your credentials never have to touch our servers.
Yeah I see what you mean. Many MCP clients has the ability to ask human for confirmation before a tool call is executed. In this way, you can check the tool call before it executes.
1. Hi! We noticed this for Strata as well so we are ONLY counting the execute_action in Strata. This means the fee is the same as using the traditional, flat approaches. In other words, the 3 previous calls does not cost you anything!
2. I think the main drawback of search method is like giving a human lots of tools/APIs but you can ONLY access them via a search interface. This feels weird and should be improved. For our approaches, the step by step methods allow you to see what categories/actions are available. We also provide a documentation search so that you get the best out of both worlds.
1. Oh okay great, maybe clarify it in the pricing page? That mcp server call means just execute. But its' still 10x more expensive right?
2. From what i understand it's just nested search right? It is not anything different, if you do flat or embedding search or fuzzy/agentic nested is a choice for sure, but Im just saying not sure how defensible this is, if all other mcp competitors or even users themselves put in a nested search tool
1. Sure, we will clarify that in the pricing page, thank you! As you can see from our evaluation, we are much better than official MCP servers. I think people care more about getting things done correctly. Otherwise, you waste all the model tokens for nothing. We do have enterprise deals where we can work out a customized pricing plan for your specific use case. Come talk to us if you are interested.
2. One VERY important distinction is that the model is doing the "search" here, not some RAG algorithm or vector database. Therefore, as the model becomes smarter, this approach will be more accurate as well.
1. I was not talking about official MCP servers, those are often even free. Im talking about pricing of other devtools for aggregating tools/mcp's. I think this is an obvious space to build i agree, i just worry about differentiation. Its a search space not as big as web search, or complex (order doesnt matter).
2. Yes, i see, this is what i meant by agentic search. Essentially is a tiny subagent, taking list of tools in and out the relevant ones. Still implementable in 5 mins. But i guess if the experience is very smooth enterprise might pay?
1. Yes I agree. To be honest we are a young company (as you can tell we are from YC X25), so we are still figuring out the pricing. But thank you for the feedback and sharing your thoughts.
2. Yes the idea is not complex once you understand it. But there are some nuances we found along the way and supporting more integrations are always important but requires engineering efforts. Thank you!
We are SOC2 compliant. So this will not be a problem. Come talk to us if you are interested in using this for your clients and we can work out the details.
