Configuring Auto Learning Agents
This page is the reference for the first two layers, the runtime settings and the per-area config files. The third layer, the markdown files that shape what agents actually say and do, has its own guide in instruction files. Most day-to-day configuration happens in the web UI's Config tab, which edits these same files for you, so think of this page as the map of what lives where.
settings.txt: The Runtime Configuration
settings.txt sits at the root of the install (in the data volume on Docker) and holds the platform-wide runtime configuration as a single JSON object. It is re-read constantly while the system runs, so an edit applies on the next tick of whatever reads it. The keys:
homepath is the absolute path of the install with a trailing slash. Every tool uses it to find the installation, so it is the one value a bare-server install must set correctly. Docker installs ship with it set.
memory_bank_port and analysis_port are the sockets for the two always-on Python services, 9500 for embeddings and storage, 9510 for topic classification and anomaly detection. The defaults work for almost everyone, change them only if those ports are taken.
models_installed lists which model families this install can use, claude, codex, or both, and controls which models the UI offers in every model picker. Add ollama models by running them locally, the AI models guide covers each key.
users holds the login accounts for the web UI: a name, an email, and a bcrypt password hash per account. Accounts are managed from the System panel in the Config tab, so you rarely touch this by hand. A fresh install seeds the first account.
memory_backend selects the memory engine: local for the bundled sentence-transformers and sqlite-vec stack that works with zero setup, or adaptive_recall together with adaptive_recall_url and adaptive_recall_token for the premium upgrade with knowledge graphs and multi-strategy retrieval. Switching backends is exactly this one change.
API keys live here too: AWS credentials power Polly voice synthesis, and the BrightData token and zone names (brightdata_api_token, brightdata_serp_zone, brightdata_unlocker_zone) unlock the scraping APIs. api_url connects the optional API backend used by the webpages and broadcast features. The tts settings choose and tune the speech voice, and trainOllama switches on the weekly fine-tuning run that trains a local model from your own memory data.
The config Directory: Per-Area Settings
Each platform area keeps its own JSON file in config/, and each file is watched, so edits reconcile live while agents run:
agents.json defines your task agents: id, type, enabled, tick timing, model, and instructions file for custom agents. This is the heart of creating agents, and the Config tab's Models panel edits it visually. Adding, editing, enabling, disabling, and deleting agents all apply without a restart, and edits to a busy agent wait politely for its current task to finish.
chatbot.json connects messaging platforms, Discord, Slack, WhatsApp, and Telegram, with tokens and per-platform options, and the platform list is extensible. marketing.json holds the email and SMS providers and sending configuration for the marketing preset. customerservice.json holds the IMAP and SMTP accounts the support preset answers. socialmedia.json holds the credentials and options for the seven social platforms. webpages.json configures website deployment along with Google Analytics and Search Console reporting (ga4_property_id, ga4_key_file, gsc_site_url).
The Config tab in the web UI exposes each of these as its own panel, Marketing, Customer Service, Social Media, Webpages, plus the Models panel for agents and pipelines and the System panel for users and voice, so the files are always editable without leaving the browser.
memory/system: The Behavior Files
The third layer is a set of owner-editable markdown files in memory/system that the UI exposes directly: your brand voice, product descriptions, support policies, coding standards, compliance rules, and image guidelines. Agents read these every time they work, which is how a one-paragraph edit to your brand voice changes the tone of every outgoing message at once. The instruction files guide documents the full memory layout, including the per-agent role files and the core agent instructions.
Configuring Through .env on Docker
Docker installs add a convenience wrapper: a .env file at the project root, documented by .env.example. On every container start, the values you set in .env are applied into the persisted settings.txt, the memory backend, Adaptive Recall connection, BrightData credentials, and API backend, while everything you have not set keeps its current value. The pattern is simple: put the stable, machine-level choices in .env, and manage everything else from the UI while the system runs.
How Live Configuration Behaves
The platform treats configuration as data, not as startup state. settings.txt is read again on every tick by whatever needs it, the config files are watched for changes, and the memory files are read fresh each time an agent works. This is why the system can run for weeks while you reshape it: change a model, rotate a key, add an agent, rewrite a policy, and the running system absorbs the change at its next natural boundary. The one habit worth forming is editing through the UI when a panel exists for it, the UI validates as it writes, and the underlying file stays yours to edit by hand whenever you prefer.
Three layers, all live: settings.txt for the runtime, config/ JSON for each area, and markdown files for behavior. Edit any of them, from the UI or by hand, and the running system picks the change up without a restart.