Opengeni

Opengeni is open-source AI infrastructure for putting agents directly inside your own product. It gives developers the pieces an agent needs to run reliably in production — durable sessions, isolated sandboxes, credentials, tools and MCP, memory, multi-tenancy and ready-made React components — and lets you either use the managed Opengeni cloud or run the same stack in your own environment. The purpose is stated plainly on the site: agents in your product, infrastructure out of the box. You focus on your agents, Opengeni handles the infrastructure, and the promise of the launch is shipping agents to production in hours rather than spending that time building plumbing. The project is released under Apache-2.0, its source lives on GitHub, and the site notes it is built from running agents in production, with Hydro, Havila and Posten shown as brands already working with it. Getting an agent demo running is easy; running agents for real customers is not. A single dropped connection can end a run. Agent code cannot safely execute next to your secrets. Every user needs their own OAuth tokens, and every API has to be wired before an agent can call it. Agents forget everything between sessions, and in a multi-tenant product every query has to know who is asking. Opengeni frames this as a list of things you do not have to build, and the site walks through each one in turn: durable sessions, sandboxes, credentials, tools and MCP, memory, multi-tenancy and model choice. Each of those is presented as a problem that would otherwise land on your team before the first real user ever touches the agent. Durable sessions are the first building block. Opengeni keeps a run alive when a worker restarts or a tab is closed: the run keeps going and resumes at the event where it left off, with the site's example showing a run resuming at event 128. Agent code then runs in an isolated sandbox, so it cannot run next to your secrets. In the example, the sandbox executes a Python script that detects a duplicate charge, and the credentials it uses are described as scoped and short-lived. That combination matters because agent work is often long-running and unpredictable: durable sessions turn a failure into a pause instead of a lost run, and sandboxes let you hand an agent real code execution without exposing production secrets to it. Credentials and tools cover the other half of the integration problem. Every user of your product needs their own OAuth tokens, and Opengeni handles that: the site shows Stripe, GitHub and Google Drive accounts connected per user, with tokens refreshed automatically over time. On top of credentials, Opengeni lets you plug tools in from an existing API definition — an OpenAPI file such as billing.openapi.yaml yields callable operations like invoices.list, refunds.create and customers.get, and the site presents adding three tools as a single step. Tools and MCP are both supported, which means an agent can act on the systems your customers already rely on rather than only talking about them. Memory, multi-tenancy and model choice complete the core. Memory is built in, so agents learn from past sessions instead of forgetting everything between them; the examples separate workspace-level memory (refunds go to the original card), user-level memory (sends invoices by email) and entries flagged to review first (bills in EUR from April). Multi-tenancy keeps customers apart, with distinct workspaces such as Acme, Globex and Initech and row-level security so that every query knows who is asking. Model choice stays open: OpenAI, Azure OpenAI, OpenRouter or your own OpenAI-compatible endpoint are all listed, and Opengeni states that you can swap models freely as better ones ship, without being locked in. Opengeni's overall approach is that the same session can appear on any surface, because every surface is a client of the same API. The site shows three of them. First, the Opengeni app at app.opengeni.ai, where a session can be started and tracked, including a completed example run that lists each step the agent took. Second, your product, shown as a billing assistant embedded in a customer's billing page, where the same session runs under your own brand. Third, the code, where a React component such as BillingAssistant.tsx is assembled from the @opengeni/sdk and @opengeni/react packages, using OpenGeniClient, OpenGeniProvider and SessionConversation. The client talks to your backend, and the documentation notes that your backend holds the API key and proxies the session routes so the key never reaches the browser. The React components are designed to be restyled quickly. The site lists a five-step customization flow: one variable recolors every surface through your accent, corners can be sharp, soft or round, you can use the font you already ship, and a single attribute flips between light and dark themes. The sample CSS shows custom properties for accent color, radius and font family, and an interactive control panel lets you try accent, corner, font and theme options directly. Because these are the same packages the Opengeni app is built on, the streaming responses, tool steps and composer come with the component rather than having to be rebuilt, which shortens the work between having a working agent and having it appear inside your product. The outcomes Opengeni emphasizes follow directly from those pieces. Sessions that recover from failures mean a run is not lost to a restart. Sandboxes mean agent code does not run beside your secrets. Handled credentials mean each user's own OAuth tokens are managed and refreshed. Tools and MCP mean APIs are wired from an existing definition instead of by hand. Memory means agents carry learning across sessions. Multi-tenancy and row-level security mean customer data stays separated. Model freedom means a better model can be adopted without a rewrite. The launch description also highlights 100+ integrations, human approvals and visibility into every step and dollar spent, so teams can see what an agent did and what it cost. The concrete workflows on the site are customer-support and billing shaped. A customer asks why they were charged twice in March; the agent lists invoices, runs a duplicate-detection step, confirms the duplicate and issues a refund, then explains that two $49 charges landed on March 12 and the duplicate is going back to the card. The same exchange is shown inside a branded billing assistant, with a confirmation that $49 was refunded to a card ending in 4242. Other listed session examples include a weekly churn summary, updating a refund policy document and triaging failed webhooks — all presented as work an agent can carry out inside the same environment, with the steps visible as they happen. Opengeni is aimed at developers and product teams who want agents inside their own product rather than in a separate tool. The integrations shown are Stripe, GitHub and Google Drive, alongside the broader mention of 100+ integrations and support for tools and MCP. The stack is open source under Apache-2.0 and can be self-hosted with a Helm chart on any Kubernetes, with Terraform for AWS, Azure and GCP; the repository is cloned from GitHub. Two deployment paths are offered: the managed Opengeni cloud, where you pay model cost plus 5%, or your own cloud running the same Opengeni API, workers and web app. Self-hosting is free, and a launch promotion gives the first 100 users $100 in cloud credit with the promo code PRODUCTHUNT100. The takeaway is straightforward: Opengeni is infrastructure for agents that actually finish the job. It packages the parts that are tedious and risky to build — durable sessions, sandboxes, credentials, tools, memory, multi-tenancy and model swapping — behind an open-source stack with React components you can restyle in seconds. You can start in the Opengeni cloud or keep everything in your own Kubernetes, and the same session can run in the Opengeni app, inside your product, or straight from your code, all on one API.