# OpenAlly A cross-platform AI agent product for personal and business work, with a shared Rust runtime and practical tools for getting things done. By Satyajit Pradhan Published: 2026-09-14 Updated: 2026-09-16 Canonical: https://satyajiit.dev/work/openally/ ![OpenAlly cover](https://satyajiit.dev/images/cover-openally-v3-960.webp) OpenAlly is a cross-platform AI agent product for individuals and businesses. I’m building it at Matterward Labs to help people get useful work done: organise information, make websites and apps, and handle the everyday operations of a business. ## Start with the job someone needs done A person may need to turn scattered information into a plan. A small business may need to organise customers, inventory, orders, bookings, invoices, or payments. Those tasks are connected in the working day. OpenAlly brings agents and practical tools into one product so a conversation can lead into the work itself. The product has Android and Mac interfaces, with iPhone part of its cross-platform direction. Platform availability and install options live on the [OpenAlly website](https://openally.ai/). ## One runtime, several interfaces The implementation separates the interface from the device-side runtime. The interfaces share TypeScript packages, while a Rust kernel owns the agent loop and the tools that act on local work. The mobile interface is React Native; the desktop application uses a Tauri shell. The mobile interface talks to the Rust kernel through a native bridge. This gives the product a defined boundary between presenting a task and carrying it out. Agent sessions, model access, tool execution, and local records belong behind that boundary rather than being duplicated across screen components. When the interface changes, a better screen should not require a second implementation of what an order means or how a tool is allowed to act. My work connects these parts into a product that people can use, while keeping their responsibilities explicit. ## Model choice is a product decision OpenAlly connects to different model providers and to compatible self-hosted models. People can choose the model that suits the job rather than rebuilding their workflow around a single provider. Supporting that choice requires a consistent path for requests, results, and failures inside the runtime. Some work needs a capable remote model; other work benefits from local processing on supported devices. The interface needs to make those choices understandable. Privacy depends on the selected model and connected services, so local records should never be confused with a claim that no information can leave the device. ## Business records stay close to the work OpenAlly stores operational records such as inventory, orders, invoices, and payments in SQLite on the device. Optional hosted services and connected channels have their own responsibilities. Keeping those boundaries explicit makes it easier to reason about data ownership, availability, and what an agent is actually permitted to access. I care about the less visible parts of that experience: a clear account of what happened, predictable permission checks, and failures a person can understand. An agent making a useful suggestion and an agent taking an action are different responsibilities. The system has to treat them that way. ## Aster has a specific role [Aster](/work/aster/) is a separate Android companion for accessibility-based screen interaction. It can give an agent a way to inspect and operate an Android interface when the user enables it. That capability is Android-specific; it does not define OpenAlly as an Android-only product. OpenAlly coordinates agents and work. Aster provides a particular device capability, behind a separate permission boundary. [Giving AI an Android phone](/writing/giving-ai-an-android-phone/) goes deeper into that boundary. ## The thread from commerce to consumer AI Building [ZyadaShop](/work/zyadashop/) and contributing to [merchant platforms](/work/merchant-platforms/) made me spend time with the systems behind everyday work. I’m carrying that interest into consumer AI with OpenAlly: start with a real task, give it an understandable interface, and build the machinery needed to follow through. OpenAlly and its architecture are still changing. This page describes the boundaries I’m building around; the public site lists what ships today. ## What you can do ### Build an app: Give your website a home on Android. WebToApp packages an existing HTTPS website with your app name, icon, colours, and chosen device capabilities. Keep the signing key, generate an APK, and handle store submission as its own step. Example request: “Turn my shop’s website into an Android app.” 1. Connect the website and choose the branding. 2. Review device capabilities and the signing setup. 3. Build the APK; prepare an AAB if you plan to publish. ![Give your website a home on Android.](https://satyajiit.dev/images/sunday-website-640.webp) ### Run the shop: Stock, orders, and money. In the same working day. Business tools bring the catalog, stock locations, orders, invoices, and payments into OpenAlly. An agent can work with the records you allow it to access; refunds and other consequential actions remain decisions for the owner. Example request: “Help me understand what is in stock before I take the next order.” 1. Keep products, prices, and stock locations together. 2. Follow an order into payment and fulfilment. 3. Review the action before money or stock moves. ![Stock, orders, and money. In the same working day.](https://satyajiit.dev/images/openally-desktop-business-960.webp) ### Delegate a routine: Give recurring work an agent and a place to run. Create an agent with a defined role and model, then set up recurring work for connected channels. The agent team and Automations screens keep those choices visible instead of burying them in a conversation. Example request: “Keep this channel’s recurring work on a schedule.” 1. Give the agent a job and choose its model. 2. Connect the channel the work belongs to. 3. Set up the routine and inspect its activity. ![Give recurring work an agent and a place to run.](https://satyajiit.dev/images/openally-automations-640.webp) ## Inside the app ### Put a routine to work. ![OpenAlly Automations screen showing scheduled workflows for LinkedIn, YouTube, X, and Instagram.](https://satyajiit.dev/images/openally-automations-640.webp) Set up recurring work for connected channels from the Automations screen. ### Each agent has a job. ![OpenAlly Agent team screen showing assistants for support, sales, development, and other roles.](https://satyajiit.dev/images/openally-agents-640.webp) A team of agents, with roles and model choices visible in one place. ### Keep the business close. ![OpenAlly Business screen with inventory, catalog, orders, customers, and tax settings.](https://satyajiit.dev/images/openally-business-640.webp) Catalog, inventory, orders, and customers alongside the work of your agents. ### Make the idea tangible. ![Sunday café website demo, with a menu and working sample bag.](https://satyajiit.dev/images/sunday-website-640.webp) Try Sunday, a working sample café website, inside an Android app frame. The menu and demo bag work. ## Product figures - **4+** Google Play rating - **5K+** Android installs Play Console · shared by Satyajit, as of 2026-09-14. Figures from my Play Console. The public listing is still catching up. ## Sources & further reading - [OpenAlly product and platform availability](https://openally.ai/) - [OpenAlly trust and control](https://openally.ai/under-the-hood) - [Matterward Labs](https://matterwardlabs.com)