Is soul.py suitable for enterprise use?

Yes, but as an embedded memory primitive rather than a standalone deployment platform. Enterprises use soul.py by embedding it inside their AI products — CRM assistants, internal tools, customer-facing agents — where it provides persistent memory and configurable identity per agent instance. It is not yet a multi-tenant platform for 50+ concurrent users sharing a single deployment.

What is the difference between soul.py and SoulMate API for enterprise?

soul.py (pip install soul-agent) is an open-source Python library you embed directly in your application. SoulMate API is a hosted REST service built on soul.py that handles memory storage, retrieval, and RAG+RLM hybrid search via HTTP. For enterprise, SoulMate API is the faster path — no infrastructure to run, just HTTP calls from your existing stack.

Can soul.py handle multiple users with separate memories?

Not natively in v0.1-v2.0 — the architecture assumes one MEMORY.md per agent instance. For multi-user scenarios, the current pattern is to instantiate a separate soul.py agent per user, each pointing to their own memory files. The roadmap includes a first-class multi-tenant mode with per-user memory namespacing in a future release.

How does soul.py compare to OpenLobster for enterprise deployments?

OpenLobster is a full deployment platform (Go binary, Neo4j graph memory, multi-user, auth, cron scheduler) designed to run as infrastructure. soul.py is a library you embed in your own application. OpenLobster is better if you want to deploy a self-hosted AI assistant server for a team. soul.py is better if you're building a product and want to own the memory layer inside it.

What enterprises are already using soul.py patterns?

The soul.py architecture powers the AI systems at AATS (American Association for Thoracic Surgery), including the AATS Risk Calculator, AI Knowledge Portal, and AI Curriculum platform. QuantMD and ThinkCreate.AI use soul.py-based memory in production ML pipelines and clinical decision support tools.

soul.py for Enterprise: What's Ready Today, What's Coming

By Prahlad Menon Published 2026-03-15 4 min read

The most common question I get after people try soul.py for their personal agent: “Can we use this at work?”

Short answer: yes — but you need to understand what soul.py is before you architect around it. It’s not a self-hosted AI platform. It’s a memory primitive — a library you embed inside your product.

That distinction matters a lot for how you design enterprise deployments.

What soul.py actually is

pip install soul-agent gives you a Python library with three things:

Identity injection — SOUL.md defines who the agent is, what it knows, how it communicates
Memory persistence — MEMORY.md + daily notes survive across sessions, providing context to each LLM call
Retrieval — v2.0 adds RAG (vector search) and RLM (full synthesis) so the agent doesn’t just inject raw files but queries them intelligently

What it doesn’t give you: a server, a UI, a multi-user model, an auth layer, or infrastructure to run.

That’s not a bug. It’s the design. soul.py is meant to be embedded — inside your application, your agent, your product. The memory layer is yours to own.

What’s ready for enterprise today

1. Embedded agent memory in your product

The cleanest enterprise use case: you’re building a product with an AI component, and you want that AI to remember things across sessions.

from soul_agent import SoulAgent

agent = SoulAgent(
    soul_path="./agents/sales-assistant/SOUL.md",
    memory_path="./agents/sales-assistant/MEMORY.md"
)

response = agent.ask("What do we know about Acme Corp's procurement timeline?")

The agent reads SOUL.md (who it is, what it knows about your product and domain) and MEMORY.md (accumulated context about customers, deals, decisions) on every call. No database. No server. Just files your app controls.

This is already production-ready. It’s what powers the AI tools at AATS — the Risk Calculator, Knowledge Portal, and AI Curriculum platform all use soul.py-based memory patterns.

2. SoulMate API — hosted memory via HTTP

If you don’t want to manage files yourself, SoulMate API is the hosted layer built on top of soul.py. Your app makes HTTP calls:

POST /memory/ask
{
  "query": "What do we know about Acme Corp?",
  "session_id": "crm-agent-001"
}

SoulMate handles storage, RAG retrieval, and the RLM synthesis layer. You get persistent, queryable agent memory without running any infrastructure. Already running in production on Railway.

3. Per-instance agent identity

soul.py’s SOUL.md is a first-class configuration primitive. In enterprise, this means every agent instance can have a distinct identity:

A customer support agent that knows your product docs, tone guidelines, and escalation rules
A sales assistant that knows your ICP, objection handling playbook, and deal history
An internal analyst that knows your data schemas, reporting conventions, and key stakeholders

Each gets its own SOUL.md. Each builds its own MEMORY.md. The identity layer is explicit, auditable, and editable by non-engineers.

4. Git as audit trail

Since memory lives in files, you get version control for free. Every memory update is a commit. You can see exactly what the agent learned, when it learned it, and roll back if something goes wrong.

For regulated industries (healthcare, finance) this is significant. An auditable, diff-able record of what the AI knows and when it learned it is a compliance asset, not just a convenience.

Where the gaps are

Honest accounting:

Multi-user concurrency. One MEMORY.md as a shared write target breaks under concurrent sessions. The current workaround is one agent instance per user — each with their own memory files. That works but requires you to manage the per-user instantiation.

No native access control. soul.py has no concept of “this user can see this memory, that user can’t.” If you need role-based memory access, you’re building that layer yourself.

Graph relationships. “What do all of our Midwest accounts have in common?” is a multi-hop query that markdown handles awkwardly. You can approximate it with RAG, but a proper knowledge graph would do it better.

No built-in UI. There’s no admin dashboard for browsing or editing agent memory. You’re working directly with files or building your own interface.

The roadmap

Near-term (v3.0):

First-class multi-tenant mode — namespace memory by user_id, instantiate agents per user without manual file management
SQLite backend option — for users who want something between flat files and a full database
Memory schema validation — typed memory entries, not just freeform markdown

Medium-term:

SoulMate API multi-tenant — managed per-user memory with a single API key
Memory access control — simple permission model (read/write/admin per memory namespace)
Structured knowledge extraction — auto-extract entities and relationships from conversations into a queryable format

Longer-term:

SoulSearch for Teams — the browser extension, but with a shared organizational memory layer on top of individual user memory
Optional graph backend — for teams that need the relationship modeling without giving up soul.py’s portability guarantees

The honest positioning

Use case	soul.py today	Notes
Single-user personal agent	✅ Ready	This is the core use case
Embedded memory in your product	✅ Ready	Production-proven at AATS
Hosted memory via HTTP	✅ Ready	SoulMate API
Multi-user with separate memories	⚠️ Workaround	Instantiate per user
50-user self-hosted AI assistant	❌ Not yet	Use OpenLobster for this
Graph relationship queries	❌ Not yet	v3.0 roadmap
Enterprise SSO / RBAC	❌ Not yet	Build yourself or wait

If you need a self-hosted AI platform your whole team can log into, with a UI and proper multi-user support out of the box — OpenLobster is doing that work right now and worth watching.

If you’re building a product and want to own the memory layer inside it — soul.py is the right foundation. No lock-in, no black boxes, full control over what the agent knows and how it learns.

Get started: pip install soul-agent · GitHub · SoulMate API