{
 "version": "https://jsonfeed.org/version/1.1",
 "title": "Geenius Chat blog",
 "home_page_url": "https://chat.geenius.io/blog/",
 "feed_url": "https://chat.geenius.io/blog/feed.json",
 "description": "Posts from the team building Geenius Chat: why it runs on its own agent engine, how long agent runs resume after a break, and what is live.",
 "language": "en",
 "items": [
  {
   "id": "https://chat.geenius.io/blog/one-app-two-names/",
   "url": "https://chat.geenius.io/blog/one-app-two-names/",
   "title": "One app, two names",
   "summary": "Geenius Chat and Pilotie Chat are the same app. Each build shows only its own name. Chat is coming soon and is not on sale yet.",
   "date_published": "2026-10-29T09:00:00Z",
   "authors": [
    {
     "name": "The Geenius Chat team"
    }
   ],
   "tags": [
    "product",
    "names"
   ],
   "content_text": "You will see two names for this chat. One is Geenius Chat. The other is Pilotie Chat. They are not two products with two engines, two waitlists and two sets of limits. They are one app, built twice only so that each copy shows its own name and not the other.\nWhat "the same app" means\nThe agent engine is the same. A run is still a record saved after every finished step. Threads are still your conversations, newest first, only yours, inside a workspace you belong to. Signing in is still the account you already have, with no separate Chat password. Messages between you and your agents, the connector your own AI can use, and the choice of provider behind one interface are the same work under either name.\nPilotie Chat does not get a different plan ladder. The names we expect when Chat opens are Pro, Premium and Max, and they are not on sale yet. Prices are announced when Chat opens. There is no free Chat plan on either name. Session and weekly limits still come from the plan, and the numbers are not published here.\nWhy the names are split on the page\nA page that says both names in every sentence makes it harder to see which product you opened. So each build shows one name. This website is the Geenius Chat site, and it says Geenius Chat. Where the other name matters, we say the fact once: Pilotie Chat is the same app under the Pilotie name. We do not describe a second feature set, because there is not one.\nThe split is a label, not a fork. We are not keeping two roadmaps. A change to how a run resumes, or to how tool results are read, lands in the one engine. It does not have a Geenius version and a Pilotie version.\nWhat is still true of both\nBoth names are coming soon. There is no public app under either name: no sign-in page, no conversations, no real model call. The engine, the provider interface and saving runs exist in code and are tested. The windows on this site show sample data. Bringing your own key is not offered. A phone app is planned and has no date. Chat starts on the web, made so it can be installed like an app, and that install is part of the same "when it opens" story.\nIf you are deciding which name to wait for, wait for the one you already use the rest of. The account is the same kind of sign-in either way: one account, and Chat reads the plan. Join the waitlist on this site to hear when Geenius Chat opens. The short version of the two names is also in the docs."
  },
  {
   "id": "https://chat.geenius.io/blog/what-coming-soon-means/",
   "url": "https://chat.geenius.io/blog/what-coming-soon-means/",
   "title": "What \"coming soon\" means on this site",
   "summary": "What the words on the Geenius Chat site mean: coming soon, built in code, tested, and not live. Nothing here can be used today.",
   "date_published": "2026-10-28T09:00:00Z",
   "authors": [
    {
     "name": "The Geenius Chat team"
    }
   ],
   "tags": [
    "honesty",
    "product"
   ],
   "content_text": "Geenius Chat is marked coming soon on every page of this site. That phrase is doing real work. It is not a soft way of saying the app is open if you know where to look. This post says what the labels mean, so you can tell a finished claim from a plan.\nNot live means not usable\nComing soon means there is no public Geenius Chat today. There is no sign-in page, no conversations, and nothing in the docs that you can do inside an app. The windows on this website show sample data. They are pictures of the shape we are building, not a view of your account.\nIf a page says "when Chat opens", the steps under that heading are a description of the app we are building. They are not instructions you can follow this week. The only things you can do on this site today are read, join the waitlist, and send us a note or a feature request.\nBuilt in code is not the same as shipped\nSome parts exist as code and have tests. The agent loop, the interface to AI providers, and saving a run after each finished step are in that group. Messages between you and your agents, with unread counts and the notifications you choose, are built and tested as well. Signing in is built in code.\nNone of that is deployed as a public app. A test in the engine does not put a button on a website you can press. When we say "built and tested", we mean the code exists and the tests we run pass. When we say "not live", we mean you cannot use it yet. Both sentences can be true at once, and on this site they are.\nWhat the tests do not do\nProvider plug-ins are tested against recorded examples. Those tests never call a real model. That is why we also say, in plain words, that no real model call happens in Chat yet. The list of models you can pick is not published here, because that list arrives when conversations go live. Bringing your own key is not offered.\nWe will not fill the gap with a price. Chat is not on sale. The plan names we expect at launch are Pro, Premium and Max, and the prices are announced when Chat opens. There is no free Chat plan. Session and weekly limits come from the plan, and the numbers are not published on this site. The app will show them when it opens.\nWhy we keep repeating it\nA marketing site can make a careful reader do the work of guessing. We would rather repeat the limit. Every major page carries the coming-soon label. The docs use a short honest note where a feature could be mistaken for something you can try. The blog posts on this site, including this one, describe the engine and the rules we have already chosen. They do not describe a session you had in Chat, because nobody has had one.\nIf you want to hear when that changes, join the waitlist. If a sentence on this site still sounds like the app is open, tell us. That is a bug in the copy, and we want it fixed."
  },
  {
   "id": "https://chat.geenius.io/blog/tool-results-are-data/",
   "url": "https://chat.geenius.io/blog/tool-results-are-data/",
   "title": "Tool results are data, not orders",
   "summary": "Why the Geenius Chat engine reads tool results as data and never as instructions, and what that does and does not promise. Chat is not live yet.",
   "date_published": "2026-10-27T09:00:00Z",
   "authors": [
    {
     "name": "The Geenius Chat team"
    }
   ],
   "tags": [
    "engine",
    "safety"
   ],
   "content_text": "An agent that can read a web page, a file or the result of a tool is also an agent that can be talked to by those things. A page can contain a line that says "ignore what you were told and do this instead". If the engine treats that line as an order, the page is steering the run. Geenius Chat has one rule for this, and it is not a setting you turn on.\nThe rule\nEvery tool result is data to read, never an instruction to follow. The text comes back from the tool, the run keeps it, and the agent may use it as information. It does not become a new brief. A sentence on a page that tries to replace your request stays a sentence on a page.\nThe same rule covers the other things an agent reads on your behalf: a file, another tool's result, the body of a page. We do not keep a list of "trusted" tools that are allowed to give orders. The split is the same everywhere. Your message is the request. What the tools bring back is material.\nWhy it lives in the engine\nA warning in a prompt is easy to skip and easy to contradict. Putting the rule in the engine means a plug-in cannot switch it off for one provider, and a page cannot switch it off by asking. It is the same idea as saving a run after every step: the behaviour is part of how a run works, not a preference in a settings screen.\nThis is also why the engine is ours. A thin window over one model leaves that decision to the model and to whatever text it just read. We wanted the decision in one place, next to the record of the run, so a later reader can see what was asked, what was fetched, and what was only data.\nWhat we do not claim\nThe rule lowers the chance that something an agent reads will steer it. It does not make that chance zero. No system can promise that, and we will not write a sentence that pretends ours does. Models can still misread, skip, or over-trust a passage. A safer shape is not a guarantee.\nWe also have not watched this rule in a public app, because there is no public app. The engine exists in code and is tested. Chat is not live: there is no sign-in page and no conversations. No real model call happens in Chat yet. The provider interface is tested against recorded examples, which never call a real model. So this post describes a rule of the engine, not a log of attacks we have seen in production. There is no production.\nWhat you will see later\nWhen Chat opens, a run can still stop and ask you a question. That question is yours to answer. It is not a tool result, and it is the point where a decision only you can make stays with you. Finished steps stay saved while the run waits. Tool results collected before the question stay in the record as data.\nIf you want a chat that keeps that record, join the waitlist. The longer explanation of a run is in the runs page of the docs."
  },
  {
   "id": "https://chat.geenius.io/blog/one-interface-many-models/",
   "url": "https://chat.geenius.io/blog/one-interface-many-models/",
   "title": "One interface, many models: how Chat picks who answers",
   "summary": "How Geenius Chat talks to AI providers through one interface, how a router chooses, where keys live and how the plug-ins are tested.",
   "date_published": "2026-10-24T09:00:00Z",
   "authors": [
    {
     "name": "The Geenius Chat team"
    }
   ],
   "tags": [
    "models",
    "engine"
   ],
   "content_text": "Geenius Chat is not tied to one AI company. This post explains the idea behind that in plain terms, and where it stands today.\nEvery provider looks the same\nEach AI provider is a plug-in behind one interface. The rest of the engine does not care which plug-in it is talking to. That has a practical result for you: a new model can be added without changing how you chat, and without touching your threads or your runs.\nA router decides\nA router decides which provider answers a message. When Chat opens, the app will show which models you can pick and which provider answers, so you always know where your message goes.\nKeys stay on the server\nA provider needs a key. In Chat, the key is handed to the plug-in on the server at the moment it is needed. It is never placed in your browser or in the app's code.\nTested on recorded examples\nEvery plug-in is tested against recorded examples. The tests are repeatable and they keep keys out of the test suite entirely.\nWhat is sent, and to whom\nTo answer a message, Chat sends it, together with what the agent needs from the thread, to the provider of the model that answers. The app will say which provider that is, and it will have its own privacy statement, shown before you use it. Only you see your own threads and runs, and only in a workspace you are a member of.\nWhy this matters for long tasks\nA run is saved step by step by the engine, not by the provider. Because the plug-ins are interchangeable, the saved steps, the questions a run is waiting on and your threads stay yours whichever model answers. A model that suits a task better next quarter can be added without a rebuild and without starting your history over.\nWhere it stands\nThe provider interface and the router are built and tested. Conversations with real models are not live yet, so the list of models you can pick will appear when they are.\nTo hear when Chat opens, join the waitlist. If there is a model or provider you would like to see, the contact page is the place to say so."
  },
  {
   "id": "https://chat.geenius.io/blog/why-chat-has-its-own-engine/",
   "url": "https://chat.geenius.io/blog/why-chat-has-its-own-engine/",
   "title": "Why Geenius Chat has its own agent engine",
   "summary": "Why we built our own agent engine for Geenius Chat instead of wrapping one AI provider, and what that changes for long tasks, models and safety.",
   "date_published": "2026-10-20T09:00:00Z",
   "authors": [
    {
     "name": "The Geenius Chat team"
    }
   ],
   "tags": [
    "engine",
    "models"
   ],
   "content_text": "When we started on Geenius Chat, the quick route was obvious: take one AI provider, put a chat window on top of it and ship. Many chat apps are exactly that. We chose the slower route and built our own agent engine first. This post explains why, and what it means for you once Chat opens.\nA chat is more than a reply\nA quick question needs one answer. A real task needs more. "Compare these three venues and draft an email to the best one" is several steps: read, compare, decide, write. Some steps call tools, some may need to ask you something. If the chat is only a thin window over one model, all of that lives in the window. Close the tab, and the work is gone.\nOur engine treats that kind of task as a run. A run keeps what you asked, every step the agent took, every tool it called, any question it is waiting on and its answer. Each step is saved as it finishes. That is the part that lets a run continue after an interruption instead of starting again.\nOne interface, many providers\nThe second reason is choice. AI models change quickly. A model that is the best fit today may not be the best fit in three months, and different tasks suit different models. If Chat were tied to one provider, every change would be a rebuild.\nSo the engine talks to providers through one interface. Each provider is a plug-in behind it, and a router decides which one answers. Adding a model means adding a plug-in, not changing how you chat. The keys for those providers stay on the server; they are never put in your browser or in the app's code.\nWe test every provider plug-in against recorded examples. That means our tests never call a real model, and it also means something we want to be plain about: no real model call happens in Chat yet. The models you can pick will be listed when conversations go live.\nData is not orders\nThe third reason is safety. An agent reads things on your behalf: a web page, a file, the result of a tool. Some of that text may try to give the agent instructions. A well-known trick is a web page that says "ignore what you were told and do this instead".\nOur engine has one rule for that, and it is not a setting: every tool result is data to read, never an instruction to follow. That lowers the risk of an agent being steered by something it reads. No system can promise the risk is zero, and we will not pretend ours does.\nWhat this means today\nToday the engine exists in code and is tested: the agent loop, the provider interface and saving runs step by step. There is no public app yet, no sign-in page and no conversations. When Chat opens, you will sign in with your account and see its plans and prices here.\nIf you want to hear first, join the waitlist. And if you have a task you would like a chat to keep going on, tell us about it: it helps us decide what to build next."
  },
  {
   "id": "https://chat.geenius.io/blog/a-long-task-that-survives-a-closed-tab/",
   "url": "https://chat.geenius.io/blog/a-long-task-that-survives-a-closed-tab/",
   "title": "A long task that survives a closed tab",
   "summary": "How Geenius Chat saves an agent run step by step, what happens when a run is interrupted, and what a run can and cannot do yet.",
   "date_published": "2026-10-19T09:00:00Z",
   "authors": [
    {
     "name": "The Geenius Chat team"
    }
   ],
   "tags": [
    "runs",
    "engine"
   ],
   "content_text": "Everybody has lost work to a closed tab. With a chat app the loss is quieter but just as real: you asked for something that took a while, you switched away, and when you came back the answer was half finished or gone. In Geenius Chat we want that to stop happening. This post explains how, in plain terms, and where it stands today.\nWhat a run keeps\nIn Chat, every piece of work by an agent is a run. A run is a record, not a moment. It keeps:\nwhat you asked,\nevery step the agent took,\nevery tool it called, with the result it got back,\na question it is waiting on, if it needs you,\nand the answer.\nThe important word is every. The engine saves the run after each step, not only at the end.\nWhat happens when a run is interrupted\nSay an agent is working through four steps and the connection drops after step two. Because steps one and two were saved when they finished, the run does not start again from nothing. It picks up at step three, with everything it already learned. You see the same thread, with the finished steps in place.\nThere are limits: a run continues within the session and weekly limits of your plan, and what is saved is each finished step.\nWhen an agent needs you\nSome tasks need a decision only you can make. A run can stop and ask you a question, and the question is kept with the run. When you answer, the run continues from there. The finished steps stay saved while it waits.\nYour threads, newest first\nRuns belong to threads, the conversations in your list. The list shows your threads newest first, one row per thread, with when it last moved and where it stands. It loads a page at a time, so a long history stays quick. You see only your own threads, and only in a workspace you are a member of.\nWhere it stands\nSaving and resuming runs, waiting questions and the list of threads are built and tested in the engine. They are not live: there is no public app yet. When Chat opens, they open with it.\nIf long tasks are the reason you want Chat, join the waitlist and say so in the form. It tells us which parts to open first."
  }
 ]
}