Artha Engine: The Semantic Runtime Behind Memuron

Every team shipping AI agents eventually hits the same wall: the model reasons well, but nothing durable survives the session. The market responds with vector databases, conversation buffers, knowledge graphs, and "memory layers" that are really search indexes with marketing.

AlphaNimble's answer splits into two layers:

• Artha Engine — a small Python runtime for semantic transduction
• Memuron — the product memory platform built on that runtime

This post explains what Artha Engine actually is, what it deliberately is not, and why that separation matters if you care about auditability, replay, and shipping regulated verticals.

Not a memory app

Artha Engine is not Memuron. It is not Mem0, Zep, a notes tool, or a graph database with an API.

It is a runtime for this loop:

outside-world input
  → encoder
  → Arthaanu (typed semantic object)
  → append-only semantic event
  → projection replay
  → decoder / recipe / API response
  → trace back to source events

Memory systems disagree about what representation should be primary. RAG wants chunks. Fact extractors want bullet memories. Graph systems want entities and edges. Agent frameworks want episodes and summaries.

Artha's position is simple:

The semantic object is primary. Everything else is an encoding, lifecycle output, projection, or decoding.

When you build on the engine, you do not ask "where should I store this JSON?" You ask:

• What semantic object is being created?
• What event preserves it?
• Which projection makes it fast to read?
• Which decoder turns it into the product output?

Four layers to keep separate

Arthaanu

An Arthaanu is an identity-bearing unit of meaning: artha_id, name, value_type, and a typed value. It is not necessarily a database row, a document, or a chat message. Those are product interpretations.

Event

The semantic event ledger is canonical truth. Meaningful changes append events — create, lifecycle transforms, updates, deletes with domain metadata. Projection rows are never authoritative on their own.

Projection

Projections are derived read models rebuilt from events: memory tables, link indexes, collection placements, search surfaces. If a projection drifts or corrupts, you replay from the ledger.

Decoder

Decoders cross back to the outside world: API responses, context packs, graph exports, UI rows. They should be fast and should not redo ingestion work that belongs in encoders.

Confusing these layers is how memory systems become impossible to audit.

Core stays small; products stay opinionated

Artha Engine owns mechanics that every serious memory product needs:

• typed representation registries
• append-only semantic storage (PostgreSQL or SQLite)
• projection replay with watermarks and failure status
• generic vector search and ranked fusion helpers
• typed actions — one Python function becomes HTTP route, MCP tool, and CLI command
• discovery via /_artha/manifest and /_artha/openapi
• auth seams (Clerk, API keys, JWT) without baking in product RBAC

Profiles and products own philosophy:

• domain Arthaanu value types
• Guardian prompts and ingest policy
• scope and tenancy rules
• ranking and consolidation
• UX and vertical semantics

Memuron is the first production product on this stack. It writes memory.created, link.created, and related events; refreshes memuron_memories, memuron_links, and sibling projections; and exposes Guardian ingest, document subgraphs, org spaces, and MCP tools — all without moving Memuron-specific behavior into core.

That boundary is intentional. If Guardian logic leaked into the engine, every future Artha product would inherit Memuron's opinions. If the ledger lived only in Memuron tables, you would lose replay, inspectability, and the artha CLI.

Why events before tables

The anti-pattern we see constantly: INSERT INTO memories ... with no durable history. Updates overwrite rows. Deletes vanish. Debugging a wrong agent answer means reconstructing git history from logs that were never written.

Artha's recipe is append event first, refresh projection second:

semantic_write(memory_arthaanu, event_type="memory.created", refresh=["memuron_memories"])

Product code gets read-after-write ergonomics. Operators get a ledger they can inspect with artha events, replay projections, and answer: what happened, which component did it, which sources were cited, can current state be rebuilt?

For regulated domains — finance, health, legal — that question is not academic.

One action, three surfaces

Product teams should not maintain parallel HTTP handlers, MCP tool lists, and CLI parsers by hand.

Artha's application framework binds one typed action to every surface:

@actions.action(
    name="memory.search",
    http=("POST", "/memories/search"),
    mcp=True,
    cli="memory search",
    scopes=["memory:read"],
)
def search(input: SearchInput, context: ActionContext) -> SearchOutput:
    ...

Memuron's agents call MCP. Integrations call REST. Operators use CLI. All three hit the same contract — important when memory is infrastructure, not a demo feature.

How this maps to Memuron

Fintellytics, Vitalink, EZ-ERP, and our other products are reference implementations proving Memuron works in production. Artha Engine is what lets us add the next product without forking the storage model.

The PostgreSQL moment, again

Fifteen years ago, document stores won demos; PostgreSQL won enterprises because relationships and integrity mattered.

Today's default agent memory is chunked RAG: embed, top-K, stuff context, forget. It works until you need multi-hop reasoning, temporal updates, provenance, or the ability to prove what the system knew when it answered.

Artha Engine is the substrate for that harder class of system. Memuron is how we ship it.

Next steps

• Use Memuron — memuron.com for the product: Guardian ingest, graph workbench, MCP for agents
• Explore the engine — Artha Engine lives in the Arthaanu monorepo (artha_engine/): artha doctor, artha events, projection replay, and the builder docs in docs/BUILDING_WITH_ARTHA_ENGINE.md
• Read the graph story — Memuron: institutional memory as a graph for how question-edge links and Guardian curation work in practice

If you are evaluating memory infrastructure for agents, ask vendors one question: can you rebuild current state from an append-only semantic log? If the answer is no, you are buying a cache — not memory.