Project Golem: A Node.js Agent Runtime With a Dashboard, Memory Modes and a Scheduler

The gap Project Golem is trying to fill

Most chat interfaces treat a session as the unit of work. You explain your project, get an answer, close the tab, and explain it again tomorrow. Project Golem is built around the opposite assumption: that the useful unit is a long-running workspace with state. The README frames it as an AI work system rather than a chatbot, and the feature list backs that framing up with persistent memory, a skill loader, MCP tool mounting, a calendar, and a dashboard that exposes each of those as its own route.

The intended user is someone running this on their own machine or private network. The README lists personal AI workbench, local private AI via Ollama or LM Studio, and long-term project accompaniment as the primary scenarios. That is a narrower audience than a general assistant app. If you are happy with a hosted product and do not care where the inference runs, nothing here is aimed at you.

There is also a second, less conventional layer. The same runtime ships a text RPG mode, a bond diary with levels and weekly summaries, and stock watchlists for Taiwan and US markets. Those are not incidental demos. They appear as first-class dashboard routes and slash commands, which tells you the project is as much a personal companion environment as a productivity tool.

How the runtime, memory and dashboard fit together

The repository layout in the README separates four concerns. apps/runtime is the startup entry point, apps/dashboard is the dashboard plugin layer, src/ holds the core logic described as brain, manager, services and bridges, and packages/ holds shared modules for memory, protocol and security. Two compatibility entry points sit at the root: index.js forwards to apps/runtime and dashboard.js starts the dashboard. The web-dashboard directory is a separate Next.js application.

Memory is switchable. The README names two modes, lancedb-pro and native, selected through GOLEM_MEMORY_MODE, and describes a pipeline of summarisation and retrieval rather than raw transcript storage. The dashboard exposes both /dashboard/memory and /dashboard/memory-firewall, which suggests writes are filtered before they reach the store. The README does not document the firewall's rules, so treat that as an area to inspect in the code before trusting it with sensitive material.

The brain is abstracted behind GOLEM_BACKEND with three documented values. gemini drives a browser session through Playwright, described in the README as Browser-in-the-Loop. ollama and lmstudio talk to local HTTP endpoints. That abstraction is the most consequential design decision in the project, because it means the same memory and tool layer sits on top of very different transports, one of which is a web page rather than an API.

Multi-agent work is a named mode rather than a separate service. The README describes an Interactive Multi-Agent mode where you create role groups for discussion and consensus output, with /dashboard/agents and /dashboard/office as the surfaces for it. High-risk operations route through /dashboard/action-gate, an approval flow that pairs with the risk command protection and permission checks listed under security governance.

Getting it running: setup.sh, npm scripts and the env keys that matter

The documented requirements are Node.js >=20 <23, npm, and Chromium or Google Chrome if you intend to use the Gemini Web backend. Installation is a shell script rather than a package install. On Windows the README insists on Git Bash; on macOS it uses Terminal. Both cases are the same two lines: cd into the extracted project-golem-main folder, then ./setup.sh. The script then walks you through installation or a launch menu.

Day to day you will use a small set of npm scripts. npm run dashboard starts the runtime together with the web dashboard, npm start starts the core runtime alone, npm run dev runs under nodemon, npm run doctor performs an environment health check, npm run arch:check enforces architecture boundaries, and npm test runs the test suite. The dashboard is documented at http://localhost:3000/dashboard by default.

Configuration is environment variables. The default block sets GOLEM_BACKEND=gemini, GOLEM_MEMORY_MODE=lancedb-pro, PLAYWRIGHT_STEALTH_ENABLED=true and ALLOW_REMOTE_ACCESS=false. The Ollama block adds GOLEM_OLLAMA_BASE_URL=http://127.0.0.1:11434, GOLEM_OLLAMA_BRAIN_MODEL=llama3.1:8b, GOLEM_EMBEDDING_PROVIDER=ollama and GOLEM_OLLAMA_EMBEDDING_MODEL=nomic-embed-text. The LM Studio block uses GOLEM_LMSTUDIO_BASE_URL=http://127.0.0.1:1234/v1 with GOLEM_LMSTUDIO_BRAIN_MODEL and an empty GOLEM_LMSTUDIO_API_KEY. Note that embeddings are configured separately from the brain model in the Ollama example, so a backend swap is not a single-variable change.

Remote access is off by default and the README pairs it with REMOTE_ACCESS_PASSWORD and SYSTEM_OP_TOKEN. If you enable it, the documented advice is to set both plus a firewall or VPN. For server deployment the README points at docker compose up -d --build and two guides, docs/DOCKER-LOCAL.zh-TW.md and docs/VPS_VNC_Setup_Guide.md. The VNC guide exists because the Gemini Web path needs a visible browser, which is the clearest signal of where this project's operational weight sits.

The Gemini Web backend is the interesting bet and the biggest liability

Driving a model through a logged-in browser session instead of an official API is the part of Project Golem that will divide people. The upside is obvious from the README's own framing: it lets you use a Gemini subscription you already pay for, with no per-token billing and no API key to manage. PLAYWRIGHT_STEALTH_ENABLED=true exists to make that automation less detectable.

The costs are equally clear. You need Chromium or Chrome installed. You need a session that stays logged in. Any change to the provider's page structure, bot detection or terms of service can break the backend in a way no amount of application code can fix, and the project cannot patch around it quickly. The VPS guide's reliance on noVNC exists precisely because this mode wants a real browser surface, which makes headless server deployment awkward in a way that an HTTP backend is not.

This is not a reason to avoid the project. It is a reason to decide which backend you are actually planning to run before you invest time in memory tuning and skill authoring. If your answer is Ollama or LM Studio, you get a conventional local HTTP integration and the browser layer becomes irrelevant. If your answer is Gemini Web, you are accepting an operational dependency on someone else's front end.

Skills, MCP and the slash-command surface

Extension happens through two mechanisms. Skills are loadable units you install, enable, test and manage from /dashboard/skills, with /skills listing what is installed and /learn <feature> asking Golem to attempt to generate a new one. MCP servers are mounted through /dashboard/mcp, with /install mcp-url <url> taking an HTTPS JSON configuration. Skills installed from GitHub use /install skill-gh <url>.

Running arbitrary generated skills and third-party MCP servers is a real attack surface, and the README acknowledges this by listing remote access protection, operation tokens, risk command protection and permission checks under security governance, with the Action Gate route as the approval step for high-risk operations. What the README does not provide is a specification of the permission model: which commands are classified as risky, what the token actually gates, and whether a generated skill inherits the same restrictions as a hand-written one. Until you read packages/security and the Action Gate implementation, treat /learn as a feature to use with the same caution you would apply to running a script a stranger sent you.

The conversational command set is broader than a typical agent shell. Beyond /help and /new, there are /new_memory to reset the underlying memory state, /stocks TSM NVDA 2330 and /stockboard for market context, and /rpg start with /rpg bind for the text RPG mode and channel binding. That spread is the clearest evidence that this is one person's working environment published as a project, not a scoped product with a narrow contract.

The licence is the constraint that decides most adoptions

The repository metadata reports the licence as NOASSERTION, and the README states plainly that the project uses a Source-Available Non-Commercial licence, pointing to LICENSE and COMMERCIAL-LICENSE.md. Source-available is not the same as open source. You can read the code, and the README implies you can run and modify it, but commercial use is carved out and requires a separate commercial licence from the author.

For a personal workbench this distinction rarely matters. For anyone evaluating Project Golem as a component inside a product, it is the first thing to resolve, ahead of any technical question. The presence of a separate commercial licence file means a paid path exists, but the terms are not in the material here, so the only reliable move is to read both files and, if the answer affects revenue, get proper legal advice rather than inferring from the README's one-line summary.

The versioning adds a second practical consideration. The README badge shows 9.7.9 while the most recent release listed is v9.6.14, with v9.6.12 and v9.6.6 close behind in mid-May 2026 and the last push in late June 2026. Releases that frequent, with a README ahead of the tagged version, mean you should pin to a tag rather than track main if you care about reproducibility. There is no published upgrade procedure in the material, so plan on re-reading the README and checking docs/ before each jump, particularly around GOLEM_MEMORY_MODE, since a memory format change is the kind of thing that makes a rollback painful.

Where Project Golem is the wrong tool

The obvious alternative is a plain orchestration library such as LangChain or LlamaIndex, and the difference is structural rather than feature-by-feature. Those libraries give you composable pieces, a retriever, a tool interface, a chain, and leave the application, the UI and the persistence layer to you. Project Golem gives you the assembled application: a Next.js dashboard with roughly eighteen documented routes, a runtime process, a memory store, a scheduler, bridges to Telegram and Discord, and an opinionated set of slash commands. You trade control over the seams for not having to build the seams.

That trade is wrong in several concrete cases. If you need to embed agent behaviour inside an existing service, pulling in a dashboard, a browser automation layer and a text RPG mode is dead weight. If you need a permissive licence, the non-commercial term settles it before any technical comparison. If your deployment target is a small container with no browser, the Gemini Web path is unavailable and you are effectively running the Ollama or LM Studio configuration, at which point you should ask whether you want the rest of the application.

There is also a documentation gap worth naming. The README is primarily in Chinese with an English README.en.md linked at the top, and the doc map points to Chinese-language guides for the dashboard, MCP, memory architecture, commands and Docker. The English surface appears thinner. If your team cannot read the Chinese docs, you will be working from the code for anything the English README does not cover, and the memory firewall and permission model are exactly the areas where that matters most.

Editorial conclusion

Adopt Project Golem if you want a single self-hosted process that combines a model backend, persistent memory, MCP tools and a browser dashboard, and you are comfortable running Node.js 20 to 22 with Chromium present. Do not adopt it if you need a permissively licensed dependency for a commercial product, or if you want a small library rather than an application with its own UI. Verify first that your chosen backend actually answers: run npm run doctor, then start with GOLEM_BACKEND=ollama against a local server before committing to the Gemini Web path, because that path depends on browser automation and a logged-in session rather than a documented HTTP API.

Official sources

1. Arvincreator/project-golem on GitHub
2. Issues
3. README
4. Releases