Install & first mission

Current version: v0.4.2.14

Runs on: Windows or Linux

Web interface: http://localhost:8713/ui

Formicaria is a self-hosted AI workspace built around a simple idea: give the colony a goal, let the Queen organize the work, and have specialized roles research, inspect, build, test, review, and report back.

You use it through a browser, much like a normal AI chat. The difference is that a request can become a structured mission with a visible task trail, safety checks, proposed file changes, and a result you can inspect before anything is applied.

Formicaria runs on your own hardware and keeps its history in a local SQLite database. The easiest model setup is Ollama, although external model providers can also be added after installation.

New here? Start with the Windows or Linux instructions below. You do not need to edit a configuration file, build the source, or understand the colony architecture to get the first mission running.

#Pick the install that fits you

#Before you install

Formicaria is the application. The AI model normally runs through Ollama, either on the same computer or on another machine on your network.

For the simplest first setup, you need:

• A 64-bit Windows or Linux computer
• A web browser
• Ollama with at least one chat model installed
• About 10 GB of free disk space for Formicaria, its data, and a small model
• 8 GB of system RAM at minimum; 16 GB or more is much more comfortable

The model is what uses most of the RAM and GPU memory. Formicaria itself is comparatively light. A GPU is helpful but not required for a small Ollama model.

This guide uses llama3.1:8b as an approachable starter model. It is not hardcoded into Formicaria, and you can choose a different model that better fits your hardware.

#Windows quick start

The desktop app. FormicariaDesktop.exe — included in the Windows download below — is Formicaria as a native Windows application: the same colony and the same console the server install runs, in its own window instead of a browser tab. Double-click it and it boots the colony in-process (bound to this computer only) and opens the console; if a Formicaria server is already running on this machine it attaches to that one instead of starting a second colony. If anything goes wrong it says so in the window, and the full story is in %LOCALAPPDATA%\Anthill\desktop.log. It needs the Microsoft Edge WebView2 Runtime, which Windows 11 and updated Windows 10 already include (otherwise: aka.ms/webview2).

Using the desktop app? Do steps 1–2 below, then just run FormicariaDesktop.exe — steps 3–4 are the browser-based server route.

#1. Install Ollama

Download and install Ollama for Windows.

Open PowerShell and download one model:

ollama pull llama3.1:8b

If PowerShell says ollama is not recognized, close PowerShell, open it again, and retry.

#2. Install Formicaria

Download formicaria-setup-<version>.exe from the latest release and run it. It walks the normal Windows steps: license agreement, install location, a desktop icon (on by default — untick it in the same screen if you don't want one), a Start Menu entry, and a standard uninstaller. When it finishes, hit the desktop icon.

Formicaria installs for you, not for the whole machine — under %LOCALAPPDATA%\Programs\Anthill — so Windows never asks for administrator approval, to install or to update.

Updates install themselves. A new release is downloaded in the background, checked against the SHA-256 published beside it, and applied the next time you start Formicaria: no wizard, no prompt, no administrator approval. A download that does not match its published checksum is deleted and never run. Turn it off, or switch it to notify-only, with auto_update in Settings → Colony. Your colony's memory and settings live under %LOCALAPPDATA%\Anthill and survive every update, reinstall, and uninstall.

If you have an older copy installed under Program Files (all users), Formicaria offers to move it once — Windows asks for approval that one time, to remove the old copy, and never again.

Prefer a portable copy instead? The formicaria-<version>-win-x64.zip still exists — extract it somewhere permanent, such as:

C:\Formicaria

Either download already contains the .NET runtime, and since v0.3.18.0 the FORAGER knowledge engine with its own Node runtime, in a forager folder beside the program. You do not need to install the .NET SDK, Node, or FORAGER.

#3. Start Formicaria

Open the extracted folder, right-click an empty area, and choose Open in Terminal. Then run:

.\anthill.exe --api --host 127.0.0.1

Keep that terminal open while Formicaria is running.

If Windows SmartScreen appears, make sure the file came from the official release link above before choosing More info → Run anyway.

#4. Open the colony

Go to:

http://localhost:8713/ui

Create the first administrator account, sign in, and continue to Your first mission.

The command above keeps Formicaria local to that computer. If you later want to reach it from another device on your private network, start it with --host 0.0.0.0 and use the LAN address printed in the terminal.

#Linux quick start

These instructions use the prebuilt release, so the .NET SDK is not required.

#1. Install Ollama and a model

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b

#2. Download and unpack Formicaria

mkdir -p "$HOME/formicaria"
cd "$HOME/formicaria"
curl -fLO https://github.com/Formicaria/formicaria-releases/releases/download/v0.4.2.14/formicaria-0.4.2.14-linux-x64.tar.gz
tar --no-same-owner -xzf formicaria-0.4.2.14-linux-x64.tar.gz
chmod +x anthill

#3. Start it

./anthill --api --host 127.0.0.1

Open http://localhost:8713/ui, create the first administrator account, and continue to Your first mission.

For a headless server that should be available on your private network, use:

./anthill --api --host 0.0.0.0

Then open the LAN URL printed at startup. Do not expose port 8713 directly to the public internet.

#LXC and systemd install

This is the easiest always-on installation for Proxmox or a dedicated Debian/Ubuntu machine. The installer creates an unprivileged anthill service account, builds Formicaria, starts it with systemd, and keeps its data across upgrades.

For a Proxmox LXC, a practical starting size is:

• Debian 12 or Ubuntu 22.04/24.04
• Unprivileged container
• 2 CPU cores
• 4 GB RAM
• 16 GB disk
• DHCP or a reserved LAN address

That is enough for Formicaria itself. Ollama will usually run on a separate machine with more memory or a GPU.

This route builds Formicaria from source inside the container, so it needs read access to the source repository (a deploy key on the box; the script's header says how) and is the way the maintainers run their own deployments. Without repository access, use the tarball from the Linux quick start above and the systemd notes in docs/DEPLOYMENT.md.

Open the container console as root, clone the repository to /opt/anthill/src, and run:

apt-get update && apt-get install -y curl ca-certificates git
bash /opt/anthill/src/modules/anthill/deploy/lxc/setup.sh

Check that the service started:

systemctl status formicaria --no-pager
journalctl -u formicaria -n 30 --no-pager

The log prints the URL to open from another computer. Create the administrator account there.

If Ollama is on another machine, sign in and set its address under Settings → Colony → Ollama Host, for example:

http://192.168.1.50:11434

Ollama must be listening on the network, and your firewall must allow the Formicaria machine to reach port 11434. See Using Ollama on another machine.

The complete Proxmox, systemd, Docker, and Windows-service notes live in docs/DEPLOYMENT.md.

#Docker

Use this route if you are already comfortable with Docker. The included Compose file is designed for a Linux Docker host and uses host networking so a local Ollama service works without extra container networking.

cd modules/anthill      # inside a checkout of the repository
docker compose up -d --build
docker compose logs -f anthill

The Compose route builds the image from source, so it needs a checkout of the repository.

Open the URL shown in the logs. Formicaria's database and configuration are stored in the named anthill-data volume.

Docker Desktop on Windows and macOS needs bridge networking instead of the shipped host-network configuration. Follow the bridge-mode example in docs/DEPLOYMENT.md.

#Your first mission

#1. Confirm the model is ready

If Ollama has exactly one model installed, Formicaria uses it automatically. If you have several, Formicaria will ask you to choose instead of guessing.

To select one manually:

1. Open Settings.
2. Choose Models in the Settings rail.
3. Pick the model under Default model, such as llama3.1:8b.
4. Click Save changes.

You can see installed model names with:

ollama list

#2. Send a simple message

Open Chat and try:

Explain how this colony processes a mission. Keep the answer short.

Formicaria should create a mission, route the work, and return an answer in the conversation. The mission details are there when you want them, but you do not need to understand every internal event to use Chat.

#3. Give it a project to work with

Formicaria can only inspect files inside its configured workspace boundary.

1. Put the project in Git so you can restore it if needed.
2. In Formicaria, open Security → Workspace Boundary.
3. Set agent_workspace_dir to the absolute path of the project.
4. Save the setting.

For example:

C:\Users\you\source\my-project

or:

/home/you/source/my-project

For Docker, the project must also be bind-mounted into the container. The example is in docs/DEPLOYMENT.md.

Start with a read-only mission:

Inspect this project and explain what it does. Do not change any files.

#What is enabled on a new install?

The colony ships with the full twelve-role roster available. Roles still run only when a mission actually needs them; enabling the full roster does not force every role into every mission.

These are the fresh-install defaults that matter most:

For colony-run missions, the SAFE_LOCAL safety profile keeps web search, the ant shell tool, file writing, patch application, and unattended auto-apply closed until you deliberately enable them. The read-only file tool remains available inside the workspace boundary.

Before allowing repository changes:

• Use a Git repository with a clean backup or remote.
• Keep the workspace boundary as narrow as possible.
• Review proposed changes and verification evidence.
• Leave auto-apply off until you have tested the full flow on a disposable project.
• Disable the admin Operator Shell if you do not need a browser-accessible terminal.

Formicaria is still pre-1.0 software under active development. It has deliberate safety gates, but it should not be trusted with irreplaceable files or unattended production changes. The measured current state and known gaps are kept in docs/PLAN.md.

#Organizational knowledge (FORAGER)

Formicaria can answer from your organization's own documents — contracts, runbooks, decision records — instead of from the model's training. The knowledge itself lives in FORAGER, a separate local application that turns documents into evidence-backed statements. Formicaria never parses a document, never stores knowledge, and never resolves a contradiction: it asks FORAGER and presents what comes back with its support level and its provenance intact.

It is off on a new install, and a colony with it off is a normal colony. No tools are registered, the Knowledge page says so, and nothing about missions changes. It also adds no tables to Formicaria's database, so turning it on and off again leaves nothing behind.

#FORAGER is in the box

Since v0.3.18.0 every release archive and the Windows installer carry FORAGER beside anthill, in a forager/ folder — the engine, its interface and its own Node runtime, so there is nothing to install and nothing to download. The colony finds it there and runs it itself: open Knowledge and press Enable knowledge, and the engine starts under the colony's supervision, on a loopback port only the colony knows, with a credential the colony mints at every start. Its data lives under the colony's own data directory (forager-data), and it stops when the colony stops. Steps 1 and 2 below are for the other arrangement — a FORAGER you run yourself, on this machine or another — and knowledge_forager_bundled: false in .anthill/config.json is how you tell the colony to ignore the one it shipped with.

#1. Run FORAGER yourself (only if you want to)

Follow FORAGER's own install guide. It binds 127.0.0.1:8790 by default and runs in deterministic mode with no model provider configured, which is enough — extraction quality improves with a model, but nothing here requires one.

Check it is up before going further:

curl http://127.0.0.1:8790/api/ready

A healthy instance answers {"status":"ok", …}. Formicaria probes this same path, so if curl cannot reach it, neither can the colony.

#2. Point Formicaria at it and map your projects

Edit .anthill/config.json. With the engine that shipped in the box, skip the endpoint and set only the project map; for a FORAGER you run yourself, the endpoint too:

{
  "knowledge_forager_endpoint": "http://127.0.0.1:8790",
  "knowledge_project_map": {
    "proj_acme": "acme-contracts",
    "proj_platform": "platform-runbooks"
  },
  "knowledge_default_project": ""
}

knowledge_project_map maps your Formicaria project id to a FORAGER project id, and it is the scope boundary rather than a convenience. A mission whose project is not in the map retrieves nothing — it does not fall back to a default, because a mission that silently borrowed a default scope would be reading another tenant's knowledge. knowledge_default_project is only for callers that have no project at all, such as a direct console query; it is never a fallback for a mission.

Or do both from the console, without touching the file. The bar at the top of every Knowledge section binds the Formicaria project it shows to one of the knowledge bases FORAGER holds, picked from FORAGER's own list — or makes a new one: give it a name and say what it is for, and the colony makes it in FORAGER and binds it in the same step (Sources offers the same while nothing is bound). Knowledge › Connection lists every binding and changes where FORAGER is — loopback addresses only. What stays in the file is knowledge_forager_allow_remote (below): it decides whether the colony may trust a service on another machine as its source of fact, and a compromised console must not be able to widen that.

#3. Turn it on

Open Knowledge and press Enable knowledge. It takes effect on the next request — no restart — because the module re-reads its settings on every call.

If the page shows the switch as pinned by ANTHILL_KNOWLEDGE_ENABLED, that environment variable overrides the config file; change it where the process environment is defined. You can also set "knowledge_enabled": true in the file directly.

#4. Use it

The Knowledge area is laid out the way FORAGER lays itself out, in FORAGER's words: its three places — Sources, Knowledge and Review — then Exports, then two sections that are the colony's own. A bar at the top of every section picks the Formicaria project, says which knowledge base it reads with FORAGER's counts and how many disagreements await review, and shows where the engine stands.

Every statement carries its support level — direct fact, supported inference, uncertain inference, unverified claim — and a control that opens the exact source excerpt behind it.

Missions reach the same knowledge through tools that are registered only while the integration is on. Five of them are read-only — knowledge_search, knowledge_retrieve (the main retrieval path), knowledge_get, knowledge_evidence and knowledge_entity — and all five are scoped to the mission's project through the map above, so a mission cannot name a FORAGER project directly.

The sixth, knowledge_review, does not change anything: it writes a proposal into Formicaria's approval pipeline for an operator to accept or decline. Nothing a mission does can edit your knowledge base.

Reading needs the read_knowledge permission, and so do making an export and downloading one (downloading also takes the project's operator or administrator role); making a knowledge base, starting, cancelling and retrying ingestion, and deciding what FORAGER asks a person to decide — a disagreement, a possible duplicate, a statement's review — need manage_knowledge. Both are granted by default — knowledge_enabled is the gate that actually matters, and it ships closed. Deciding is Forager's paid curation (forager.knowledge.curate): a colony whose Forager subscription has lapsed is refused it, and keeps reading and exporting everything it has.

Import by path on the FORAGER the colony runs. FORAGER reads a folder only under one it was allowed, and allows none by default. knowledge_forager_input_roots is the list the colony hands the engine it runs (as FORAGER_ALLOWED_INPUT_ROOTS) when it starts; it is empty by default, so nothing is allowed until you allow it. Every folder must lie inside the colony's workspace (agent_workspace_dir), where the colony's own import by path already confines a path — a folder outside is refused, with the reason. Sources › Import by path says what FORAGER may read now, lets an administrator edit the list, and offers Restart FORAGER now while a saved change waits for the engine's next start. A FORAGER you run yourself reads its own FORAGER_ALLOWED_INPUT_ROOTS.

#Reaching a FORAGER on another machine

FORAGER authenticates every /api route, but it is built to own its loopback interface, and across a network the colony's credential is all that stands between that network and your knowledge base. Formicaria therefore refuses a non-loopback endpoint unless you say otherwise:

{
  "knowledge_forager_endpoint": "https://forager.internal:8790",
  "knowledge_forager_allow_remote": true,
  "knowledge_forager_token": "…"
}

knowledge_forager_token is required against FORAGER 0.7.0 and later, loopback or not: FORAGER authenticates every /api route, and a colony without a credential gets 401 on every retrieval and ingestion call. Mint an fgr_ integration token in FORAGER's Settings, scope it to read and ingest, limit it to the projects you have mapped, and paste it here. Rotating it takes effect on the next call. (This paragraph used to say the token was only for proxied installs; that was true before FORAGER 2026-09-08 and false after.) knowledge_forager_allow_remote is not editable from the console on purpose — putting a knowledge base on your network over plain HTTP is a decision to make in the file, deliberately, rather than one to inherit from a copied config.

#When something is not working

The Knowledge area tells these apart on purpose — every section shows how to fix the first four, under the bar, since nothing else works until they are fixed — and which one you are in decides what to check:

A mission that cannot reach knowledge reports itself unavailable rather than answering from assumption, and missions continue without it.

For the boundary, the retrieval pipeline, the API surface and the security model, see docs/FORAGER_INTEGRATION.md, docs/KNOWLEDGE_ARCHITECTURE.md, docs/KNOWLEDGE_API.md and docs/KNOWLEDGE_SECURITY.md.

#Using Ollama on another machine

On the Ollama machine, make Ollama listen on the network.

Linux:

sudo systemctl edit ollama

Add:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Then restart it:

sudo systemctl daemon-reload
sudo systemctl restart ollama

From the Formicaria machine, confirm it is reachable:

curl http://OLLAMA_MACHINE_IP:11434/api/tags

Finally, set Settings → Colony → Ollama Host to:

http://OLLAMA_MACHINE_IP:11434

Only expose Ollama to a trusted private network or protect it with an appropriate network boundary.

#Signing in to a colony on another machine

Every colony serves its own console, so opening http://OTHER_MACHINE_IP:8713/ui in a browser needs nothing more.

The sign-in form's Connecting to Formicaria on another machine? is for a console that stays where it is, such as the desktop app's, and sends every call to the address typed there. A browser allows that only when both machines say so, each in its .anthill/config.json.

On the machine whose console you open, list the colony it may reach:

"console_connect_origins": ["http://OTHER_MACHINE_IP:8713"]

On the machine you sign in to, list the address you open that console at, exactly as the browser's address bar shows it (scheme, host and port; the desktop app's is http://127.0.0.1:8713):

"api_allowed_origins": ["http://THIS_MACHINE_IP:8713"]

Restart both. Each entry is an exact origin: a wildcard, a path or anything else is ignored with a warning at start. Both lists are empty by default, which keeps a console to the colony that served it. A call from another origin still signs in and passes every check a call from the colony's own console does.

A session belongs to the colony that issued it. Changing the address a console talks to, on the sign-in form or under Settings › Connection › API base URL, ends that browser's session before anything is sent, so neither machine ever receives the other's; the console asks you to sign in at the new address and reopens on it once you have.

#Where Formicaria keeps its data

Formicaria creates its configuration automatically on first launch. You do not need to copy or edit config.example.json to get started.

That directory contains the databases (anthill.db, infrastructure.db, and micromound.db once devices are turned on), configuration, logs, backups, exports, workspace, and local encryption material. Back it up before upgrading or moving the installation: Settings → Diagnostics → Back up now while Formicaria runs, or anthill --backup with it stopped — either takes every database, checks the copy and rehearses restoring it (docs/MIGRATION.md). The colony deletes every backup in its backup folder (backups in that directory) 30 days after it was taken — backup_retention_days, 7 to 90, changes the window — so copy a backup you are relying on somewhere else. What the colony said to itself while working — agent messages, artifacts, task results, events and source records — is deleted 180 days after its mission ended (event_retention_days; 0 keeps it all), and approvals, escalation decisions and metrics after two years; a running mission is never touched (one a stopped colony left running is ended as failed at the next start, counted as ended at its last sign of life), and the colony's own log of what its operators and API did is not swept (docs/MIGRATION.md). A decided patch loses its file contents and pre-apply backups 90 days after the decision (patch_retention_days, 30 to 365), conversations are kept until deleted unless conversation_retention_days chooses 90, 180 or 365 days of inactivity, and device evidence is kept 24 months (device_evidence_retention_months, never fewer than 12). The FORAGER engine the colony runs keeps what it derives by FORAGER's own windows — caches 90 days, the model's output 7, unsupported knowledge 180 — and Settings → Diagnostics sets them (forager_*_retention_*; left unset, FORAGER's default or its FORAGER_RETENTION_* variable applies, and a change applies at the engine's next start). Do not publish the directory or commit it to Git.

An installation upgraded from a version before v0.4.2.0 keeps each module's tables inside anthill.db, and says so when it starts, until you stop Formicaria and run anthill --migrate-stores, which backs everything up, rehearses the move on the copy, and then moves them. See docs/MIGRATION.md.

Most settings are easier and safer to change through the web interface. The generated configuration file is .anthill/config.json if you need it for advanced deployment work.

Useful launch overrides:

#Updating

Back up the .anthill data directory first.

#Windows or Linux release archive

1. Stop Formicaria.
2. Download the newest archive from Releases.
3. Replace the program files with the files from the new archive.
4. Keep the existing .anthill directory.
5. Start Formicaria again.

Database and configuration migrations run automatically at startup.

#LXC / systemd

A service installed by deploy/lxc/setup.sh updates itself the same way the Windows app does: the colony downloads the next release's linux-x64 archive, verifies it against the published digest, and the unit's pre-start hook swaps it in at the next systemctl restart formicaria (or reboot). auto_update in .anthill/config.json turns that off or makes it notify-only. To rebuild from source instead:

cd /opt/anthill/src
git pull --ff-only
bash deploy/lxc/setup.sh

#Docker deployment

git pull --ff-only
docker compose up -d --build

The anthill-data volume remains in place.

#Source checkout

git pull --ff-only
dotnet build Anthill.sln -c Release
dotnet test Anthill.sln -c Release --no-build

#Troubleshooting

#The web page does not open

• Make sure the Formicaria process is still running.
• Use http://localhost:8713/ui on the same computer.
• On another device, use the LAN URL printed at startup.
• Do not enter http://0.0.0.0:8713; 0.0.0.0 is a listening address, not a browser address.
• If port 8713 is busy, restart with --port 8714 and open that port instead.
• For LAN access, make sure the host firewall allows the selected port on private networks.

#Ollama is unreachable or no model is selected

Check Ollama locally:

ollama list
curl http://localhost:11434/api/tags

If Ollama is on another machine, replace localhost with its IP address. If several models are installed, choose one under Settings → Colony.

#A mission cannot read the project

• Confirm Security → Workspace Boundary points to the project's absolute path.
• Confirm the Formicaria user has permission to read that directory.
• For Docker, confirm the directory is mounted inside the container.
• For an external coding agent, confirm its working directory is still inside the same boundary.

#Reset a broken configuration without deleting mission history

Stop Formicaria and rename .anthill/config.json to config.json.bak. Start Formicaria again and it will create a fresh configuration. Your SQLite databases remain in .anthill/ (anthill.db and the files beside it).

#Find the logs

LXC / systemd:

journalctl -u formicaria -n 100 --no-pager

Docker:

docker compose logs --tail 100 anthill

Portable Windows or Linux installs print startup and runtime errors in the terminal where Formicaria was started.

If you report a problem (formicaria.us/contact), include your Formicaria version, operating system, installation method, and the relevant error text. Remove API keys, tokens, passwords, webhook URLs, and other secrets first.

#Command-line checks

Run these from the folder containing anthill or anthill.exe.

Linux:

./anthill --version
./anthill --selftest
./anthill --status

Windows PowerShell:

.\anthill.exe --version
.\anthill.exe --selftest
.\anthill.exe --status

Run anthill --help for the complete command list.

These open the colony's database, so they need it to themselves: while Formicaria is running, stop it first. One database has one writer. A command started while a colony is running is refused — it names the process that holds the database, changes nothing, and exits with code 11 — and the same goes for --set-password, so a lock-out is recovered by stopping the service, resetting the password, and starting it again. The files beside the databases named anthill.db.owner, infrastructure.db.owner and micromound.db.owner are how this is enforced; never delete them. anthill --inventory is the exception: it only reads, and works on a running colony. See docs/MIGRATION.md.

#Build from source

You only need this section if you are developing Formicaria, which means you have access to the repository it lives in (modules/anthill of the Formicaria repository).

Requirements:

• .NET 10 SDK
• Git
• Optional: CMake and a C++20 compiler for the native kernel

The native kernel is optional. Without a C++ toolchain, Formicaria uses the managed C# implementation.

Clone and run:

cd modules/anthill      # inside a checkout of the repository
dotnet run --project src/Anthill.Cli -- --api --host 127.0.0.1

Run the full validation and publish flow:

Linux:

./build.sh

Windows PowerShell:

.\build.ps1

Run only the tests:

dotnet test Anthill.sln -c Release

#How the repository is organized

src/Anthill.Cli/          Command-line entry point
src/Anthill.Api/          Web API and runtime host
src/Anthill.Core/         Queen, mission flow, memory, policy, and domain logic
src/Anthill.Modules/      Reasoning, tools, and infrastructure integrations
src/Anthill.SDK/          Shared contracts for modules and tools
src/Anthill.UI/           Browser interface
tests/                    Automated test projects
deploy/lxc/               LXC and systemd installer
docs/                     Architecture, operations, and roadmap documentation

#Learn more

• docs/PLAN.md — what is working now and what is still missing
• docs/ANT_EXECUTION.md — canonical colony roles and execution gates
• docs/APPROVALS.md — patch and approval lifecycle
• docs/AUTONOMY.md — Director, objectives, budgets, and stop controls
• docs/MISSION_REPLAY.md — Mission Replay configuration (settings only; no replay engine yet)
• docs/FORAGER_INTEGRATION.md — organizational knowledge from FORAGER: the boundary and the integration decision
• docs/KNOWLEDGE_ARCHITECTURE.md — layers, types, scope and configuration
• docs/RAG.md — evidence-first retrieval, and why it is not similarity search
• docs/KNOWLEDGE_API.md — the /knowledge/* routes and the agent tools
• docs/KNOWLEDGE_SECURITY.md — tenant isolation, the ingestion fence, and what it deliberately cannot do
• docs/MODULE_CONTRACT.md — what a first-party module declares, how the host resolves the set, and the fixtures that hold both
• docs/DEPLOYMENT.md — detailed deployment and service setup
• CHANGELOG.md — complete release history

#Current release

The shipped defaults make the full twelve-role roster available to new installations, confine write-capable external agents to Formicaria's workspace boundary, and ensures Archivist output exists before the learning pass consumes it. Finalization steps are also recorded so they are not applied twice during recovery.

That is the only release summary kept in this README. Older release notes belong in CHANGELOG.md.

#License

Apache License 2.0