Firm: a work management system you keep as text files

The business as a graph

Firm is described as a text-based work management system for technologists, and the pitch is stated in the README's own words: modern businesses are natively digital, but lack a unified view, because the data is scattered across SaaS tools you do not control, so answers require jumping between platforms.

The alternative offered is to think of the business as a graph. Organisations link to people, people link to projects, projects link to tasks, and so on, and Firm lets you define those relationships in plain text files.

That gives you the features listed in the README. Everything in one place, with organisations, contacts, projects and their relationships. Own your data, as plain text files and tooling that runs on your machine. An open data model that you can tailor to your business with custom schemas. Automation of anything, on the argument that search, reporting and integration are just code. And an AI-ready structure, since bots can read, write and query your business structure.

The version control point is the one that matters most in practice. A directory of text files is something you can put in a repository, review in a pull request and roll back. That is a different relationship with your operational data from the one you get when it lives in the database behind a vendor's web interface.

The tool is written in Rust, the homepage is firm.42futures.com, and the current release is 0.5.0.

Installing and taking the first steps

Firm installs with Homebrew.

brew tap 42futures/firm
brew install firm

The alternative is to download a binary from the GitHub releases page, and the repository also carries install.sh and install.ps1 scripts for people who would rather run an installer directly.

The workflow starts by initialising a workspace in a directory of your choice.

cd my_workspace
firm init

Entities are then added by type, by identifier and by fields.

firm add --type organization --id megacorp --field name "Megacorp Ltd."

And read back either by listing a type or by querying with the DSL.

firm list organization
firm query 'from organization | where name contains "Megacorp"'

That query shows the shape of the whole system. The filter is written in a pipeline form, from a type and a where clause, and it reads like a query language rather than like a command line flag soup. The README links the full documentation site for everything else.

The repository root also holds an example directory with subdirectories for a core workspace, a network structure, resources, sales and schemas, which is the fastest way to see what a real Firm workspace looks like before you write one.

The crate layout of a Rust workspace

The Cargo file shows the project is a workspace of five crates, and the names explain the architecture better than any description would.

The members are firm_core, firm_lang, firm_mcp, firm_lsp and firm_cli, with a resolver set to version 3. So the core holds the model and the storage, the language crate holds the DSL and its tooling, the CLI is the command line front end, and the other two are the integrations with editors and with agents.

The language crate has a companion outside the workspace: a tree-sitter-firm directory at the root, which is a grammar for the DSL. That is what makes syntax highlighting, incremental parsing and editor tooling possible for a language that only a handful of people use, and it is a sign that the language is meant to be edited in a text editor like any other.

The source tree also holds a docs directory, which is what generates the documentation site, a CHANGES file, an example directory with several worked workspaces, and the installer scripts.

For anyone evaluating the project as a Rust codebase, this layout is the interesting part: the core is separated from the language and from the front ends, so an embedder could take firm_core without taking the CLI.

Language server and MCP, the two integrations

The two smaller crates are the ones that make the tool usable in a modern workflow, and the README's AI-ready claim is really about them.

The language server crate, firm_lsp, is the standard mechanism for a language to plug into an editor. With a grammar in tree-sitter and a language server in Rust, a developer editing a Firm workspace gets the same completions, diagnostics and navigation they would get in any other language, which matters for a DSL that is meant to be written by hand in plain text files.

The MCP crate, firm_mcp, is the Model Context Protocol server. That is the integration point for the AI-ready claim in the feature list, where bots can read, write and query the business structure.

That combination is the most distinctive thing about Firm. A text file format is easy for an agent to read, but a plain text file with no schema and no query language is not easy for an agent to work with reliably. A structured representation plus a query language plus a protocol server gives an agent the same affordances a human gets from the CLI, and the README frames the whole concept that way: a structured representation of your work makes your business accessible to yourself and to the robots that help you run it.

The practical caution is the same one that applies to any agent with write access to your business data: the agent can modify the graph, and the graph is the source of truth.

The licence question and the boundary of the idea

The licence needs attention because the repository metadata and the README do not agree.

The README says Firm is licensed under AGPL version 3, and spells out what that means in practical terms: you can use and extend it freely, but if you build commercial extensions or services on top of it, those must also be open source under AGPL version 3. The repository metadata, however, lists the licence as MIT. The LICENSE file at the root is the authority, and the README points to it for full details.

That conflict is exactly the kind of thing to resolve before you build anything commercial on top of the tool rather than after.

The other boundary is the idea itself. Firm is a local, file based representation of a business, and it is strongest where the questions are about relationships and status: who works on what, which project a contact belongs to, what is overdue. It is weakest where a real database is stronger, which is concurrent transactional writes and reporting over very large volumes.

The comparison with the alternatives is therefore straightforward. A hosted work management tool gives you a maintained, shared source of truth but you do not control the data or the schema. A database plus a bespoke application gives you both control and concurrency but costs you the whole application. Firm sits between: it gives you the data and the schema in a form you own, and it leaves the application part to you.

That is the trade. If your team wants to query the business rather than record it in one more tool, it is a good trade. If you want a system of record that other people simply use, it is not.

Versions and what to check before you start

The release tags are Firm 0.5.0 from 2026-02-06, Firm 0.4.0 from 2026-01-10 and Firm 0.3.0 from 2025-10-13, and the last push to the repository was on 2026-10-19.

So this is an actively developed project on a pre-1.0 version line, where the version number still moves between minor versions and the language and the CLI are changing shape. That is normal for a tool at this stage, and it means you should expect to read the CHANGES file when you upgrade rather than to rely on a stable specification.

Several things are worth checking before you commit a team to it.

The licence question comes first, as described above. The schema story matters just as much: the open data model is a real feature, the example directory includes a schemas directory, and the practical question is whether you can express your entities in custom schemas or whether you will spend the first weeks modelling. The maturity of the query language is the other open item, since the DSL is young and the README points to the documentation site for the full reference.

The contributing section is a single line, inviting issues and pull requests, and the project is small enough that a specific question about schema design is likely to get a direct answer.

One last practical note. The tool is designed to be run against local files in a directory, and the whole workflow in the README assumes you are inside a workspace. If you are looking for a hosted multi-user work system, this is not that, and nothing in the documentation suggests it is heading there.

Editorial conclusion

Firm suits a technologist team whose operational data is spread across SaaS tools and who want one queryable, version controlled representation of it, because a plain text store with a graph shaped schema and a query language can be read by people, by scripts and by agents in a way that a database behind an API cannot. It is the wrong choice if your workflow genuinely needs a shared transactional database with concurrent writers, and the wrong choice if the AGPL terms in the README are a problem for you, since the licence position needs checking before you build anything commercial on it. Verify first that the licence in the LICENSE file matches what the README says, that the example schemas cover your entities, and that the version you install has the connectors and query features you need.

Frequently asked questions

Official sources

1. 42futures/firm on GitHub
2. License: MIT
3. Project website
4. README
5. Releases