You Already Have a Chatbot. Your Product Needs an Agent.

By now, the chatbot is a solved problem — and a commoditized one. Every enterprise has one. Every employee has one: ChatGPT in a browser tab, Copilot in the sidebar, some internal assistant behind SSO. If a company wanted "a place to go and chat with an AI," it has that already, several times over. Building one more is not the opportunity everyone seems to think it is.

But look at where the work actually happens, and the chat window is nowhere in it. The work is in the booking flow, the support console, the claims tool, the CRM, the internal ops dashboard. Those aren't chatbots — they're products and workflows, with their own screens and data and steps. And most of them shouldn't become a chat window. Asking someone to "book the flight" by opening a separate assistant, waiting, and pasting the confirmation number back into the real tool is a step backward from a booking page that just books the flight.

So the honest version of the pitch isn't "you don't need a chatbot." It's this: most of the time you already have one, and it's sitting in the wrong place for the actual job. What the actual job needs isn't another box to talk to. It's agent functionality inside the product — the booking flow that can plan the itinerary, the support console that drafts and sends the reply, the ops tool that investigates and then acts. The agent doesn't live in a separate destination. It lives in the thing people already use.

That is a different kind of thing to build. You're not standing up a chatbot; you're giving an existing product — or a new one shaped like your product, not like a chat — agentic capability. And here's the catch that turns a weekend idea into a quarter of work: doing that against a real agent runtime is deceptively hard, and none of the hard part is the part you actually care about. It's not "call the API." It's everything around a single turn — streaming the agent's work into your UI so it survives a page refresh, resuming a long-running turn after a dropped connection, giving every user their own configured agent, running that agent on a real computer with real tools, and letting it pause to ask the user a question and then pick the thread back up. That's weeks of undifferentiated plumbing standing between you and the feature you meant to build.

rebyte-app-kit is that plumbing, already built. It's a template: you own the app — it runs on your infrastructure, your domain, your login — and it talks to an agent backend for the parts you shouldn't have to build. What you get out of the box is an application with agentic capability that you fill in and ship. Not a product to log into. A starting point to build from, the way you'd start a project from a Next.js template. It's open on GitHub: github.com/rebyteai-template/rebyte-app-kit — clone it and run pnpm dev, and you have a streaming agent app running against a live backend before you've written a line.

The division of labor is clean. You own the app — the UI, the product logic, the login, the data, everything that makes it yours. The backend handles three things, and only three. The agent: a model carrying your instructions, your tools, your skills — the thing that decides and acts. The session: the live conversation and its turns — streaming the work onto your screen, surviving a refresh, resuming after a dropped connection, pausing to ask you something and picking up exactly where it left off. And the runtime: a real computer the agent works on, with a filesystem and tools, that persists across turns so it can actually do things instead of just describing them. You never build those three. You point the agent at your instructions and skills, configure it per user, and the session and runtime run underneath.

How you turn it into your product

The part that's yours is small and contained. There's one folder — domain/ — that holds everything specific to your vertical, and you never reach below it into the machinery. You give the agent its instructions and hand it the resources it should use: a skill, an MCP server, an internal API, a prompt. You decide which built-in tools it's allowed — web search on or off, whether it may stop and ask a human. That's a few lines in one file.

Then you configure it per user. Each of your users gets their own agent — their own session and runtime — and the template writes your persona and tool switches onto it through a plain config call, on that user's first turn. This is the move that makes it a customized builder rather than one global bot: the exact same code is a flight-booking assistant for one product and a design copilot for another, purely by what you configured.

And you build whatever UI you want around it. The kit ships a deliberately plain one so you'll throw it away — chat on one side, a domain pane on the other that you replace with your tables, forms, and confirm gates. Because the whole point is to sit inside an app you already have, it comes with an embed key: drop the experience into an existing product or an iframe, guard it with a shared secret, and let identity keep flowing from your own login. The streaming, the resumability, the per-user config, the runtime underneath — you don't rebuild any of it. You edit domain/.

What that looks like end to end

Make it concrete with a flight-booking product. You start from the empty template. In domain/ you write the persona — you are a flight-booking assistant — and point the agent at a search skill that hits your fares API. You turn web search off, because it should book from your inventory, not the open web. You leave "ask the user" on, because booking a flight is exactly the kind of consequential step an agent should confirm before it commits.

Now a traveler, inside the booking product — not a chat app — types where and when they want to go. The agent plans an itinerary on its own computer, calling your fares skill. Mid-turn it hits a fork: two fares, materially different, which one? It pauses and asks — and that question renders as a card right there in the flow. The traveler taps a fare; the same session resumes with that answer in context and completes the booking. If they refresh the page halfway through, nothing is lost: the session rebuilds losslessly and keeps streaming where it was. None of that — the resumable session, the in-flow question, the per-user configured agent, the computer it ran on — is code you wrote. It's the backend. You wrote domain/ — your persona, your skill, your UI. A completely different product, a design tool say, is the same backbone with a different domain/.

The point

The chatbot is already everywhere, and mostly beside the point. The leverage now is giving the products and workflows people actually work in the ability to act — agentic capability, in place, on infrastructure you own. rebyte-app-kit is how you build that without rebuilding the hard parts first.

The code is open — clone it, read it, ship on it: github.com/rebyteai-template/rebyte-app-kit. cp .dev.vars.example .dev.vars → add your API key → pnpm install && pnpm dev, then open domain/ and make it yours.