Rabbyte's Vision of the Future

The future isn’t about the next SaaS with AI. The future is multiple clients leveraging a wide range of models. The only thing they need is the ability to consume proper context.

Our goal is to create a business context platform. A central requirement of a distributed toolchain is to give any LLM adequate context, so its ability to work “for you” or “alongside you” is maximised.

Setting the stage

Let’s go through a few steps we can see at play; if you reach the same conclusion, it will be the basis for our current and future work.

Mention of LLMs has either piqued your interest or triggered a complete disgust (I don’t blame you, too much hype everywhere). One thing is clear: LLMs aren’t going anywhere, and to use them effectively, we have to adapt to this tool.

Let’s start with what your experience might be. You might be a coder who one-shots the whole app with Opus 4.5, or a coder who cannot get LLM to make a single line change correctly. You might be arguing that ChatGPT 5.1 is so much better than ChatGPT 5.2, while others cannot say a single bad word about Gemini 2.5 Flash.

What does this tell us? We have two variables: model and context.

Let’s tackle the question of the model.

Different models are suitable for various tasks. It’s not only about “providers” using the latest model from OpenAI, Anthropic, or Google. I’m asking whether the model's strength is sufficient for this task. Who cares. Let’s put everything on the latest models, right? MONEY, SPEED. Unless you have tried to use the API for LLMs, you might not know how much cheaper and faster “dumber” models can be, and yet they are perfectly capable of executing your desired tasks.

So why are some people getting great results with cheaper, “dumber” models, while you might struggle with the basics? It’s all about context! Context is king. Provide enough information, guardrails, and tools to ensure the highest possible success rate.

Models need to be interchangeable; it’s essential to provide the correct context and the appropriate amount.

What about the MCP?

There has been so much hype about it, even though it's literally “hosted tools” you might have already known, if you’ve been working with Agents. That led many companies to introduce MCPs for their APIs, which is encouraging.

It shifts how you interact with LLM. As an end consumer, you can ask yourself a simple question: where are you most likely to interact with MCP? It’s the ChatGPT Desktop App, Claude Desktop, and Cursor. Let’s put a pin in that, and we will circle back to it in a moment.

Why am I talking about all of this?

Looking at what the latest startups are doing paints an almost opposite picture. Each company is trying to integrate its own “chat” into apps—different summaries, analyses, etc.

I have a few concerns with that approach.

You don’t know what model is used. You receive an artificial number of “credits” for usage, which you can purchase more of. You have no idea how many credits you actually need. Practically impossible to represent the number of actions and their actual costs in dollars. What if what you need from the “AI Chat” is much simpler and can be handled by a smaller, less expensive model? Are you paying “premium” for almost basic/simple tasks? There’s no transparency for users. Yet all these companies switch between models and adjust pricing on short notice, since it’s challenging to accurately calculate per-user margins once LLM usage begins.

The catalogue of models is expanding monthly, and prices vary. If you are a business owner who will start relying on LLMs for specific tasks, this may feel uncomfortable due to their unpredictability. Businesses value the ability to predict operational costs. BYOK is a way to go.

You might be thinking: “I don’t really care, I’ve got deep pockets.” Let’s move to another issue. Given how important context is, how will those products provide it? A simple example: we are developing a web app. We’ve got analytics, UI/UX designers, coders, and some PMs. We’ll use Jira for tasks, GitLab for version control, Confluence for documentation, and Figma for design. Some of the coders you code with use ClaudeCode, some use Codex, and others use OpenCode.

Our goal is to maximize the capabilities of each LLM for each role to increase productivity. Where do you even start? You have multiple products, all with “AI”, all of them with their credits. Documenting anything has historically been the most neglected part of any project.

Context is King

It’s close to impossible to provide precise context when incomplete data are spread across multiple systems that do not talk to each other, barely integrate, and all push you to use their proprietary AI chat. Some may have MCP (back to MCP); others will be self-hosted behind a VPN. Who knows if any of the MCP even runs? It’s a headache, and we haven’t even considered building our own internal system that likely doesn't integrate with 15 different products and doesn't expose MCP.

It’s essential to understand how the average person already interacts with LLMs. They pay for the subscription, and use it through desktop/mobile/web app. They cannot maximize it for their own data unless they pay for multiple SaaS platforms that expose MCP.

You should see the picture as clearly as we do at Rabbyte.

How are we attempting to solve this?

Let’s start with the kernel: it's a simple web application with wiring for packages, event dispatching, webhooks, permissions, API, and MCP.

It doesn’t do anything by itself; it should only serve as a base for our future development, for which you will hopefully accompany us. Primitives that hold data consistency. Business domain logic so that you can leave the Excel behind. Connectors to external applications that format data to bring context to other applications.

All of it is ready to use by the LLM and the Client, which is MCP compatible. An average person should be able to interact with all of their data with simple integration

It’s not going to be enough; of course, we need a cultural shift where we do not execute tasks but collect, structure, and maintain information.