Glossary
Every term used across these docs, in one place and in plain language. Grouped by topic; skim it once and the rest of the docs read easily.
The big idea
Agent
An AI assistant for one store. Technically it's just data — config + memory + history — stored as a row in the database. It "comes alive" only while handling a request. See What is Agentfy.ai 2.0?
Ephemeral
"Exists only for a moment." Our agent's runtime is ephemeral: it runs during a single turn or task, then disappears. The opposite of always-on.
Always-on
A service that runs continuously whether or not it's doing work (and costs money the whole time). The 1.x model ran one always-on server per agent; 2.0 avoids that for agents.
Scale-to-zero
When there's no traffic, nothing runs and nothing costs. The brain and hands both scale to zero.
Turn
One request → response cycle of the agent: a message comes in, the brain handles it, an answer goes out.
The moving parts
Brain
The part that thinks and replies. It's the api service run for one turn — there's no separate "agent server". See How it works.
Hands
The part that does real-computer work (scripts, files, browser, long jobs). Provided by a worker.
Worker
The on-demand worker that is the hands. A container with a real OS (bash + Chromium) that runs one task, then exits — created per task as a Kubernetes Job. See Worker.
Task
A unit of work the brain hands off to a worker (e.g. "scrape this page", "generate this file").
Agent type
What an agent is — standard (what an owner creates) or concierge (the team's system agent). One declaration says what each type may do, and both the server and the interface read it. Only the server assigns a type. See Anatomy.
Concierge
The team's own system agent — one per team, persona shipped in code. It answers in the team chat and can act on the team's agents. Not renamable, not deletable, not exportable. It is an Agent row like any other — one per team, its id derived from the team's — so its conversation is stored, listed and read back through the ordinary agent paths, and survives a reload.
What it says the product can and cannot do comes from one capability declaration, not from prose in its persona. Anything the declaration does not cover, it treats as "I would not claim either way" — never as "Agentfy cannot do that".
Autostart (heartbeat)
The agent waking itself on an interval and running a full turn with no message from anyone. A single global sweeper decides who is due; a busy agent is skipped, and a tick with nothing to say writes nothing. See Autostart.
Turn lock
The hold that makes an agent run one turn at a time — what autostart consults before firing a tick. See Runtime model.
Execution profile
Whether an agent is allowed hands at all, and how much machine they get — none · light · browser · heavy · warm. It is a column on the agent, none by default, so no release ever grants hands to an agent that did not have them. A none agent touches neither the queue nor the cluster. See Anatomy.
Tool grant
Which of the worker's tools this agent's sessions may be given. A subset of the ten names the tool split assigns to the hands; empty by default, which means a worker with no tools rather than a worker with all of them.
Activity history
The agent's own short record of what it did — answered, acted, refused — one readable line each, with before → after on anything it changed. Refusals are rows like any other. See Activity.
Platform administrator
The account that may see every team, not just its own. A different thing from being an admin inside a team, and deliberately hard to grant. See Platform role.
Knowledge
What the agent knows about the store — its catalog and docs — kept in a separate service and queried on demand. Built on LightRAG.
Memory
The agent's recall: short-term (the current conversation) and long-term (facts kept across conversations). See Chat → Memory.
How it's deployed
api
The main deployable: the Core (control center) and the ephemeral brain — one image. See The pieces.
app / admin
The two Nuxt web apps: app is the customer cabinet, admin is the admin panel.
Control plane / data plane
A way to split the system by lifecycle: the control plane is always-on (api Core, web apps); the data plane is the ephemeral brain + hands that run only on demand. Not a microservice split by feature.
Container image
A packaged, runnable build of one piece (api / app / admin / worker). Each piece ships its own Dockerfile. See Container images.
How the code is organized
CleanSlice
The architecture framework these apps use — full-stack NestJS + Nuxt, organized into vertical slices. (CleanSlice docs.) See How we build it.
Slice
A self-contained feature module that owns everything it needs: its routes, logic, data access, and (on the frontend) its components and pages. Named in the singular (user, not users).
Layer / group
Slices are grouped into stacked layers (infra → setup → system → user → admin → runtime → agent → billing). Dependencies point only downward — a higher layer may use lower ones, never the reverse. See Layered slices.
Gateway
The data-access pattern: an abstract contract (IXxxGateway) lives in domain/, the concrete implementation in data/. Prisma is the repository — there are no *Repository classes.
Connectors & data
MCP (Model Context Protocol)
The standard "socket" through which tools, data, and knowledge plug into an agent. Attach an MCP server and the agent gains those actions/sources — without changing the brain.
Tool
An action the agent can take, exposed over MCP — e.g. the OpenCart API for products and orders.
LightRAG
The open-source graph-RAG library we run as the knowledge service, with a separate workspace per knowledge base. See Knowledge.
RLM (Recursive Language Models)
The no-index retrieval path: the brain recursively inspects raw data (peek/grep/slice in the worker, sub-LLM calls on the pieces) instead of querying a pre-built index. Zero ingestion, pay-at-query. See RLM.
Postgres / Redis / object storage
Where state lives, so the ephemeral runtime can stay stateless: Postgres (agents, sessions, tasks, messages, billing), Redis (queue, events, locks), object storage (files/artifacts).
Product & market
OpenCart
The first e-commerce platform we target — a large base of self-hosted stores with an extensible API. Later: WooCommerce, PrestaShop, Magento, Shopify. See Mission & market.
Greenfield
Built fresh, not ported. 2.0 is a greenfield rebuild; 1.x is only a reference for what the product does. See Migration reference.