Proma: a desktop agent that treats context layout as the product
Proma brings a seamless general-purpose Agent experience to your workflow. Built for 100× professionals and the proactive Agent era
At a glance
- What is it?
- Proma is an AGPL-3.0 TypeScript desktop agent that splits its window into session management, agent output, and an auxiliary pane of files, terminals, browsers and sub-sessions. The README is candid that the open source build now trails a commercial one, which is the central adoption question.
- Who is it for?
- Adopt Proma if you are an agent-heavy user who wants a visible terminal, a visible browser and on-disk memory files (AGENTS.md, MEMORY.md) that you can read and edit yourself, and if you accept that the repository's own README says the open source build is on a slower update cadence than the commercial one.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Proma targets: context assembly, not model access
Most desktop chat clients treat the conversation as the unit of work. Proma treats the project as the unit and the conversation as a disposable container inside it. The README states the position directly: better context is the precondition for a smarter agent, and the product's job is helping you organise that context. Everything else in the feature list follows from it.
The intended user is someone already running agents for hours a day. The README calls them professional users and heavy agent users, and the feature list is shaped accordingly: plan mode, project partitions, memory, an embedded browser, an embedded terminal, scheduled tasks, and remote channels for WeChat, Feishu, DingTalk and Slack. This is not a first agent for someone who wants to ask a few questions. It is a workspace for people who have already hit the ceiling of a single long chat thread and want the scaffolding around it to be explicit rather than implicit.
The concrete pain is context pollution. A long thread accumulates half-finished reasoning, abandoned branches, and file references you no longer need. Proma's answer is structural: separate projects, separate sessions, separate sub-sessions, and a right-hand pane that holds the artefacts instead of the transcript.
The three-column layout and what each column is for
The README describes a deliberate split. The left column manages sessions and acts as the entry point for main functions. The centre column is the agent's output area and the place where you and the agent interact. The right column is everything auxiliary: project files, the agent's file changes, document previews, sub-session interaction, the embedded browser, the terminal, Obsidian, the calendar, Todo, and Skills.
That is a stronger design claim than it first appears. Document preview, browser and terminal are not modal dialogs that steal the centre column. They sit beside the conversation so you can watch the agent work in one pane while reading the file it is editing in another. The README's own framing is that everything on the right exists to help the agent in the middle produce a better result.
File changes are tracked by round rather than as one undifferentiated list, and for programming work the README says diffs are shown. For worktree-based development, the agent selects the relevant worktree and a terminal button appears next to it, so one click drops you into a shell in that worktree. Whether that round-by-round grouping stays readable on a long session is something the README does not address, and it is the kind of thing that only shows up after a few hours of real use.
Sub-sessions, exploration and the difference from a plain subagent
Two mechanisms carry most of Proma's context argument. The first is sub-sessions and main sessions. The README describes a sub-session as conceptually similar to a subagent but with a cleaner upstream context, a persistent environment you can keep iterating in, freer model choice, and better performance. The stated use cases are parallel processing across multiple agents, deep research, adversarial analysis, and a pattern where the main session repairs while sub-sessions keep reviewing.
The second is exploration mode. After the agent finishes output, you can click explore and create branches that reuse the prior context. The README is explicit that this is exploration rather than forking: when you are done, a button in the top right of the exploration returns everything to the main line. The stated purpose is to stop uncertain judgements or marginal questions from contaminating the main session's context. You get many parallel investigations and then decide what to bring back.
That is a real architectural choice with a real cost. Exploration only pays off if you actually prune. If you return everything, you have rebuilt the pollution you were trying to avoid, and the README offers no automatic filter for deciding what is worth keeping. The judgement stays with you.
Memory lives in files you can read: AGENTS.md and MEMORY.md
Proma's memory is project-scoped and file-backed. Each project gets its own AGENTS.md, which the README describes as project-level constraints on agent behaviour: where project files should live, interaction rules, required information, conventions to follow. Below that, MEMORY.md acts as the index for the whole memory, with more specific memories organised under categories.
Putting this on disk rather than in an opaque store is the part worth noting. You can open AGENTS.md in an editor, diff it, and commit it if you want the conventions versioned alongside the code. The README also offers a bootstrapping path for people who have been using Proma for a while without any of this existing: start a new session and ask the agent to form the current project's AGENTS.md and to explore the last half month or month of sessions to extract memories about you and the project.
Skills and MCP servers are scoped per project too. The README gives a reason that is easy to miss: too many skills and MCP servers degrade agent capability, so partitioning by project trims that context naturally. It then names the cost honestly, which is that it requires more attention from the human. That trade is the recurring shape of this product.
Getting it running, and the licence you are accepting
Installation is a download rather than a build. The README points to GitHub Releases for the open source build and lists macOS Apple Silicon, macOS Intel, Windows, an Ubuntu/Debian x86_64 .deb, and a Linux x86_64 AppImage. Linux installation, security boundary and support scope are covered separately in docs/linux.md, and that document is the one to read before deploying on a shared machine, because the README does not restate its contents.
There is no documented npm install, no CLI bootstrap, and no configuration snippet in the supplied material. Configuration happens in the application: the README says open source users add and manage their own AI provider channels and API keys, and configure search and image generation services with their own keys as needed. The repository topics list agent-sdk, chatbot, chatgpt, claude, gemini and llm, which is consistent with a bring-your-own-provider model, but the README does not name specific provider configuration keys, so you should not expect a documented config file schema from this material.
The licence is AGPL-3.0. For an application you run locally for yourself, that is usually unremarkable. If you intend to modify Proma and expose it to others over a network, the AGPL's source-availability obligations are the thing to examine with your own counsel. Nothing here is legal advice, and the README itself does not discuss licence implications at all.
The open source build is deliberately the slower one
This is the limitation that matters most, and the project states it without hedging. The README says that because the team's capacity and time are limited, they were forced to slow the open source edition's feature updates and iteration pace and focus on developing the commercial version. Open source users get necessary updates and fixes; commercial users get a faster cadence, timely fixes, and what the README calls a smoother experience.
The comparison table widens the gap. The open source build has no built-in model channel, so you supply and evaluate your own providers. It has no managed search or image generation. It has no team quota management, no organisational Skills distribution, and no Proma Cloud API keys for wiring LLM, tool and multimodal capabilities into your own services. The README also warns that with third-party relay services you must judge the extra trust and data-processing risk yourself.
One genuinely useful property: the README states that open source users can download the commercial build and install over the top, and that local data is preserved and inherited. So the open source edition is not a dead end, it is a starting point you can migrate from. The reverse migration is not described.
A second limitation is self-imposed by the design. Project-scoped skills and MCP mean someone has to decide, per project, which capabilities are in scope. The README admits this needs more human attention. If you will not do that curation, the partitioning buys you nothing.
Where Proma is the wrong tool, and what to compare it against
Proma is the wrong tool in three situations. If you want a hosted assistant with model access bundled in, the open source build does not provide it and the README redirects you to the commercial download. If you work on one small task at a time and never accumulate project context, the project partitions, memory files and sub-sessions are overhead you will pay for and not use. And if you need a headless agent embedded in a CI pipeline or a server process, nothing in this material suggests Proma is that: it is a desktop application with a window layout, and the embedded browser and terminal are visible by design.
The closest comparison in the same space is an editor-native agent, of which Cursor is the obvious example. The approaches differ in where the agent lives. Cursor puts the agent inside the editor, so the file tree, the diff view and the language server are already there and the agent inherits them. Proma builds the working environment around the agent instead: the terminal, the browser, the document previews and the sub-sessions are Proma's own, and it integrates with Obsidian for markdown-heavy knowledge work rather than being an editor first. If your work is mostly code in one repository, the editor-native approach gives you less to configure. If your work spans research, documents, browser automation and scheduled tasks alongside code, Proma's pane layout is aimed at exactly that mix, and the README's own example of running a social account and feeding replies back into Todo is not a coding scenario at all.
Maintenance cost and what to check before committing
The maintenance surface has three parts. First, provider management: you own the accounts, balances and usage for every channel you configure, and the README's comparison table lists this as a commercial-edition benefit you give up. Second, project hygiene: AGENTS.md, MEMORY.md, per-project skills and per-project MCP all need periodic pruning, and the README explicitly ties skill and MCP bloat to degraded agent capability. Third, upgrade cadence: the open source build receives necessary updates and fixes, which is a narrower promise than the commercial build's faster cadence, so plan for the possibility that a feature you read about on the homepage has not landed in the build you downloaded.
The release history in the supplied material shows v0.19.52 on 2026-09-09, v0.19.37 the day before, and v0.19.31 four days before that. That is a fast version number, but the material does not say which of those releases are open source versus commercial, so do not read the version cadence as a statement about the open source build's velocity.
Before committing, check the release assets against your platform, read docs/linux.md if you are on Linux, confirm you have API keys for at least one provider, and decide whether the AGPL-3.0 obligations fit your distribution plans. If the answer to the last two is yes and you are comfortable supplying your own model access, the open source build is a coherent desktop agent. If you want the model channel, the search, the image generation and the team quota controls managed for you, the README is telling you plainly that the commercial build is where those live.
Editorial conclusion
Adopt Proma if you are an agent-heavy user who wants a visible terminal, a visible browser and on-disk memory files (AGENTS.md, MEMORY.md) that you can read and edit yourself, and if you accept that the repository's own README says the open source build is on a slower update cadence than the commercial one. Do not adopt it if you need a hosted service with managed model access and team quota controls, because that is explicitly the commercial edition's role, or if AGPL-3.0 obligations are incompatible with how you plan to distribute a modified build. Verify first: that the release you download matches your platform (macOS Apple Silicon or Intel, Windows, Ubuntu/Debian .deb, or Linux x86_64 AppImage), that you have your own provider API keys since the open source build has no built-in channel, and that the Linux security boundary described in docs/linux.md matches your threat model.
Community notes