OpenAgent review: a self-hosted Go assistant that runs browser, shell and MCP tools

What OpenAgent actually solves, and for whom

The README describes OpenAgent as "an open-source personal AI assistant that brings together powerful LLMs, your own knowledge base, and autonomous agent loops, all in one self-hostable platform." The operative word is self-hostable. Most assistant stacks force a choice: a chat UI that cannot touch your files, or an agent framework that is a library you have to wire into your own service. OpenAgent positions itself as the whole thing, shipped as one binary, listening on port 14000.

The audience is narrow but real. It is for an engineer or small team that already has model provider credentials, has documents worth indexing, and wants the agent to do things rather than only answer. The feature table lists browser-use, web search and fetch, shell execution, Office file read and write, and MCP integration. Each of those is a capability that a plain chat wrapper does not have, and each one is also a reason the deployment deserves care.

If you only want a chat interface over an API key, OpenAgent is heavier than you need. The install pulls a Go server, a built web frontend, a skills directory, and a database. The value only shows up once you start attaching tools and documents.

The agent loop, the tool surface and the MCP boundary

The architecture visible in the repository is a Go server (main.go, controllers/, routers/, model/, tool/, mcp/, skills/) with an embedded frontend built from web/ and served from web/build. The Dockerfile confirms this split: a node:22 stage builds the frontend, a golang:1.25 stage compiles the server, and the final alpine image copies server_${BUILDX_ARCH}, data, conf/app.conf, skills, web/build and a pptx-worker bundle.

The loop itself is a tool-calling loop. The README's tool table says the agent can navigate and click in a real browser, search the web, run shell commands, read and write Word, Excel and PowerPoint files, and call any MCP-compatible server over SSE, Stdio or StreamableHTTP. The go.mod file backs this up with concrete dependencies: chromedp for browser control, go-mcp for the protocol, go-pty for terminal work, gooxml for Office documents, and go-git for repository operations.

The design choice worth naming is that all of these tools sit inside the same process as the chat endpoint. There is no separate sandbox service described in the repository. Shell execution and browser control are agent capabilities, not opt-in plugins behind a second network hop. That makes the trust boundary the OpenAgent process itself, and the repository does not describe a permission model for individual tools beyond the Casbin and Casdoor dependencies listed in go.mod.

Installing OpenAgent and getting to the first agent run

The README gives pre-built binaries for Linux, macOS and Windows on x86_64 and arm64, and states that the installer downloads the latest release and starts OpenAgent on port 14000. On macOS, Linux or WSL the command is a single curl piped to bash. On Windows the README says it runs natively, with no WSL and no Docker required, and gives a PowerShell one-liner.

curl -fsSL https://raw.githubusercontent.com/the-open-agent/openagent/master/scripts/install.sh | bash

When that finishes, the server should be listening. Open the address the README names and you are in the web UI.

# after install, open in a browser:
# http://localhost:14000

The README lists three optional environment variables for the installer: OPENAGENT_VERSION, INSTALL_DIR and BIN_DIR. Those are the only install-time knobs the README documents. If you prefer containers, the repository ships a docker-compose.yml with an openagent service on port 14000 and a MySQL 8.0.25 dependency, and the README's Docker path is a single command.

docker-compose up

The compose file pins the database to platform linux/amd64 and sets MYSQL_ROOT_PASSWORD to 123456, which is a default you should change before anything leaves a laptop. The openagent service mounts ./conf into /conf/ and runs the entrypoint ./server --createDatabase=true, so the schema is created on first boot.

Building from source needs Go 1.25.0 or newer for the backend and Node.js 20 or newer plus Yarn 1.x for the frontend. The README's two commands are go build at the repository root, then cd web && yarn install && yarn start for the UI. Once the server is up, the first real use is to connect a provider, upload a document for the knowledge base, and then ask a question that forces a tool call, such as a web search, so you can watch the tool invocation and its return value in the UI.

Where OpenAgent gets in your way

The honest limitation is operational, not conceptual. The README does not document rollback, and it does not document a migration path between releases. The repository has a migration/ directory and the release cadence is fast (v2.90.0, v2.90.1 and v2.91.0 all landed within a few days in September 2026), which means the schema and the configuration surface move. A self-hosted deployment that stores conversations, documents and embeddings in MySQL inherits that movement.

The second limitation is the trust surface. Shell execution, browser control and MCP servers are all first-class tools in the same loop. The README presents this as a feature, and for a personal assistant on your own machine it is. For a shared deployment it is a problem the repository does not solve: nothing in the README or the repository layout describes per-user tool permissions, and the compose file's default database password is a hint about the intended deployment context.

The third is platform. The docker-compose.yml pins MySQL to linux/amd64, so an arm64 host running the compose path will need emulation. The README advertises arm64 binaries for the native installer, but the container path is a different story.

OpenAgent compared with OpenCode and Claude Code

The search data around this project is full of comparisons, and two of them are worth taking seriously: openagent vs opencode and openagent vs claude code. The difference is scope, not quality.

Claude Code and OpenCode are coding agents. Their world is a repository, their tools are file edits, shell commands and diffs, and their output is code. OpenAgent includes a coding agent among its capabilities, but the README frames the product as a personal assistant with a knowledge base, a browser, Office automation and MCP. The go.mod dependency list reflects that breadth: chromedp, gooxml, go-pty, go-git and go-mcp all sit in the same module.

So the practical difference is what you point the agent at. If your task is refactoring a service, a dedicated coding agent has a narrower and better-defined loop. If your task is answering questions over your own documents while occasionally browsing, running a script, or calling an internal MCP server, OpenAgent's scope is the point. Choosing OpenAgent for pure code work means carrying a browser, an Office library and a RAG pipeline you will not use.

Licence, upgrade cost and what the repository tells you

OpenAgent is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. The README and repository do not discuss trademark use of the OpenAgent name, and this is not legal advice; if you plan to redistribute a modified build, read the LICENSE file at the repository root rather than a summary.

The upgrade cost is the part the README is quiet about. There is a .releaserc.json and a .goreleaser.yaml at the top level, and releases arrive frequently, but the README does not describe an upgrade procedure, a version compatibility policy, or how the migration/ directory is applied. The Dockerfile copies conf/app.conf into the image, and the compose file mounts ./conf over it, so configuration lives outside the container and will persist across image updates. That is the one upgrade-friendly detail visible in the repository.

The repository is not archived, and the last push was on 2026-09-09, which is recent. That tells you the project is being worked on. It does not tell you the API or the schema is stable, and the release numbers in the v2.90.x range suggest rapid iteration rather than a frozen surface.

Editorial conclusion

Adopt OpenAgent if you want a self-hosted assistant where the agent loop, the RAG knowledge base and the tool surface live behind one Go binary and one port, and you accept that shell execution and browser control are part of the same trust boundary as your model provider keys. Do not adopt it if you need a documented rollback path, a stable v1 API surface, or a deployment where MySQL 8.0.25 on linux/amd64 is not acceptable. Before you commit, install it on a throwaway host, open http://localhost:14000, wire one provider key and one MCP server, and read the conf/app.conf and docker-compose.yml files to confirm the database and port choices match your environment.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. the-open-agent/openagent on GitHub