What is Agentfy.ai 2.0?
Agentfy.ai gives every online store its own AI agent — one that answers customers, knows the catalog, and can act on the store, 24/7. Version 2.0 is a ground-up rebuild whose whole job is to make that cheap enough to give to every store (OpenCart first). For the business case, see Mission & market.
The one big idea
An agent is a row in the database. It "comes alive" only while it's handling a request, then disappears.
That's the whole thing. Everything else in these docs follows from it.
The old way ran one always-on server per agent — you paid for the agent to exist, even while it sat idle (which is most of the time). Cost grew with the number of agents, so "an agent for every store" was simply too expensive.
2.0 flips it. An agent is just data — its config, memory, and history live in the database. When a message arrives, a shared, stateless service loads that data, "becomes" the agent for one reply, and lets go. Nothing is reserved while the agent waits. Cost grows with real traffic, not with how many agents exist — so giving one more store an agent costs almost nothing.
Why this matters (in one line)
You pay for work, not for presence.
| Old way (1.x) | Agentfy.ai 2.0 | |
|---|---|---|
| An agent is… | an always-on server | a row in the database |
| You pay for… | the agent existing (idle or not) | actual requests being handled |
| Cost grows with… | number of agents | traffic |
| "Agent for every store"? | too expensive | the default |
The whole thing in 60 seconds
- Always available, never always-on. The agent is data; it runs only during a request.
- A brain and a pair of hands. The "brain" thinks and replies; when a job needs a real computer (run a script, browse a site), it hands that off to a short-lived "hands" worker. → How it works
- Knowledge and tools plug in. The store's catalog (knowledge) and its APIs (tools) attach to the agent over a standard connector (MCP) — the brain itself stays small.
- Built as four deployables.
api,app,admin,worker. → The pieces - Organized as layered slices. A strict, predictable code structure. → How we build it
- Runs on shared, cheap infrastructure. One small Kubernetes cluster; state in Postgres/Redis.
New to the terms here (agent, ephemeral, brain/hands, slice, MCP)? Keep the Glossary open in another tab.
A clean rebuild, not a port
2.0 is greenfield. We do not port the 1.x code — today's version (an AWS-locked, request-centric RAG chatbot) is a reference for what the product does, not a migration plan. We build fresh on CleanSlice (NestJS + Prisma) and adopt the LightRAG library for knowledge. See the Migration reference for the 1.x mapping.
Where to go next
| If you want to… | Read |
|---|---|
| Understand the mental model | How it works |
| See what gets deployed | The pieces |
| Write code in the repo | How we build it |
| Look up a term | Glossary |
| Go deep on the architecture | Layered slices · Runtime model |
Where the code lives
- Workspace / scaffold:
cleanslice/agentfy2/— these docs, the app folders, the slice/README scaffold. - Prior engineering plan:
agentfy/agentfy/api2/ACTION-PLAN.md(drawn from). - References: Ranch (
cleanslice/ranch) for k8s / browser / pod-streaming patterns;cleanslice/runtimefor tool-executors.