fount: a modular agent runtime that loads parts instead of prompts

What fount actually replaces

Most chat frontends treat a character as a prompt plus a UI skin. fount treats it as a program. The README describes the project as a programmable, standardised, modular, customisable agent runtime platform that loads various parts to provide services, and the package.json description repeats the same idea in shorter form: a programmable, standardised, modular, customisable agent framework.

The intended audience follows from that. The README's own "Why not fount?" list names a steeper learning curve and code knowledge needed. That is unusually direct for a project README, and it is accurate: the parts you install are JavaScript modules, and the interesting ones run logic, not just text. If your goal is to change how an agent decides what to do next, or to attach it to a terminal, a browser, Telegram or a Bluetooth device, the runtime is the point. If your goal is to swap a paragraph of system prompt, you are paying the learning curve for nothing.

Parts, providers and the default character ZL-31

The architecture visible in the repository is a runtime plus loadable parts. The top-level tree carries a default/ directory next to src/, path/, docs/ and a set of build files, and the README refers to the community's fount agents and to agent-oriented plugins that other LLM chat frontends do not have. Parts are the unit of extension.

Provider configuration is environment-driven. The .env.example file lists the keys the runtime expects, including OPENAI_API_KEY, OPENAI_BASE_URL, OPENAI_MODEL, GEMINI_API_KEY, GEMINI_MODEL, GEMINI_BASE_URL, ATLASCLOUD_API_KEY and EVOLINK_API_KEY, plus FOUNT_API_KEY for agent and testing work. It also carries FOUNT_LOCALE, FOUNT_V8_FLAGS and FOUNT_DIR. Note that the file is an example, not a schema: it does not say which part consumes which key.

One documented shortcut is worth knowing before you plan anything else. The README states that you configure the API and then use the default character ZL-31 to complete part configuration, part creation and all user operations through conversation, with no onboarding. That is a real design decision: the runtime bootstraps itself through a chat interface, so the first thing you do is talk to a character rather than edit a config file.

Installing fount and getting ZL-31 to answer

The README's quick start is a single command, run through npx. The package name is the-fount, which is not the same as the repository name, so copy it exactly.

npx the-fount

The README points to its installation section for other options, and the repository ships a docker-compose.yml for the container route. That file maps two host ports, 8931 and 16698, and mounts ./data and ./node_modules into the container, with restart set to unless-stopped. The comments in the compose file describe the data mount as user data storage and the node_modules mount as a cache for dependencies produced by that user data, which tells you parts can pull in their own packages at runtime.

docker compose up -d

Once the runtime is up, the documented path is to set a provider key and then talk to ZL-31 to finish configuration. The .env.example shows the shape of those keys, so the minimum viable setup is an OpenAI or Gemini key plus the matching model and base URL variables.

OPENAI_API_KEY=
OPENAI_BASE_URL=
OPENAI_MODEL=

Where the documentation goes quiet

The README is long on positioning and short on operations. It does not document rollback of a part upgrade, and it does not describe a permission model for parts beyond the warning that some community parts may contain malicious code and that you should judge and choose carefully. That warning is the whole security story in the available documentation. There is no sandbox described, no signature scheme, no review queue.

The release history is also narrow. The recent releases are runner-v0.0.0.5, runner-v0.0.0.4 and runner-v0.0.0.3, dated 2026-08-28, 2026-08-26 and 2026-08-16. All three are 0.0.0.x versions of the runner, published within twelve days of each other. That is a component moving quickly at a very early version number, not a stable API surface. The last push to the repository was on 2026-09-14, so the codebase is current, but current is not the same as settled.

The polyglot scaffolding is the other honest signal. The tree contains Cargo.toml, Package.swift, build.gradle, build.sbt, mix.exs, stack.yaml, fount.csproj and deno.json alongside package.json. Cargo.toml declares a binary whose path is src/runner/polyglot/cargo/main.rs. Read that as an intent to let the runner be launched from several language toolchains. The README does not explain why you would pick one over another, and the primary language is JavaScript.

fount compared with SillyTavern and the hosted chat platforms

The README does the comparison work itself, and it is unusually willing to send people elsewhere. It recommends SillyTavern when you need a character or feature that requires STscript or SillyTavern plugins, character.ai when you want an LLM-driven character without agent features and do not want to configure software, ChatGPT or similar platforms when you just want to chat, and OpenClaw when you want to try AI agents without deep customisation.

The difference in approach is where the extension point sits. SillyTavern extends through STscript and its plugin system on top of a role-play frontend; fount's extension point is the part, and the README frames parts as agent-oriented plugins that other LLM chat frontends do not have. That is a claim about the kind of code you can run, not about the quality of either project. If your customisation fits inside a prompt template and a regex, SillyTavern is the smaller commitment. If it needs to call an API, read a file or drive a device, fount is built for that and SillyTavern is not.

Licence and upgrade cost

The repository metadata reports the licence as NOASSERTION, which means no standard licence identifier was detected. The LICENSE file exists at the top level, but the available documentation does not state its terms, and the README does not discuss licensing. If you plan to redistribute fount, bundle it into a product or ship parts of it to customers, read that file before you build anything on top of it. This is not legal advice, and the absence of a recognised identifier is a question to resolve rather than a conclusion to draw.

The upgrade cost is concrete. package.json defines the update script as a git pull --rebase origin master, so the documented upgrade path for a source install is a rebase against the default branch. If you have local changes to parts or to src/, a rebase will surface them. The runner releases are all 0.0.0.x, which means part interfaces can move without a major version bump to warn you. Pin what you depend on and keep your own parts in a directory the update script does not touch.

Editorial conclusion

Adopt fount if you write JavaScript and want to change how an agent decides things rather than how its prompt reads, and you accept that community parts are unreviewed code you install on your own machine. Do not adopt it if you want a chat product with a support contract, or if you will only ever edit system prompts, because SillyTavern covers that with far less setup. Before committing, verify three things yourself: which provider keys your chosen part actually reads, whether the part you want is maintained by anyone other than its original author, and what the LICENSE file says, because the repository metadata reports NOASSERTION and the README does not settle the question.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. steve02081504/fount on GitHub