Business software today is a graveyard of stitched-together SaaS. An ERP. A CRM. A helpdesk. A ticketing system. A BI tool. A billing platform. Three separate identity providers. A Postgres for transactions, a vector DB for retrieval, a graph DB for relationships, a warehouse for analytics, an event bus to keep them in rough sync. Twelve dashboards, one source of truth — usually wrong.

That stack was built for humans clicking forms. Agent-driven software is built for agents writing thousands of events per second with full lineage, full typing, and full audit. That's a different shape. Vector-DBs-bolted-on-Postgres do not become agent-native by adding embedding VECTOR(384). Tool-loops over OpenAI Assistants do not become agent-native by adding if (tool === "send_email").

You have to redesign the storage so the writes the agents emit don't drown it. You have to redesign the auth so per-key scopes and audit trails are a default, not a bolt-on. You have to redesign the memory so it's typed, queryable, vector-searchable, and graph-walkable in one shot. You have to redesign the runtime so every step is auditable by construction. You have to redesign the embeddings, the replication, the change-capture, the replay, the skills.

The bet is that once that substrate exists, every vertical of SaaS becomes a thin layer of skills + UI on top of it. ERP is the highest-leverage first vertical — it sits on the most data, has the most expensive incumbents, and rewards an agent-first rebuild more than anywhere else. But the same stack runs CRM, ITSM, support, billing, project management, recruiting, FP&A. The substrate is horizontal. The brand is the first vertical we're attacking with it.

That's what we're doing. Here.

┌────────────────────────────────────────────────────────────────────────┐
│  interface tier            chat · CLI · IDE assistant · mobile         │
│                            clickr · neo · (planned: web app, voice)    │
├────────────────────────────────────────────────────────────────────────┤
│  agent tier                runtime · skills · replay · workflows       │
│                            karta · skills · crucible · (planned: yantra) │
├────────────────────────────────────────────────────────────────────────┤
│  intelligence tier         process mining · forecasting · doc-AI       │
│                            gnn · (planned: drishti, gauge, lekhak)     │
├────────────────────────────────────────────────────────────────────────┤
│  memory tier               agent memory · embeddings · replay store    │
│                            smriti · bija                               │
├────────────────────────────────────────────────────────────────────────┤
│  ingest tier               ERP CDC · WAL replication                   │
│                            flow · vahini                               │
├────────────────────────────────────────────────────────────────────────┤
│  storage tier              graph + vector + columnar engine            │
│                            FFS                                          │
└────────────────────────────────────────────────────────────────────────┘

Every tier in Rust. Every tier with a typed contract. Every tier that talks to another over an HTTP-shaped or process-shaped boundary so any single piece can be replaced.

The substrate. Where bytes live, where durability is enforced, where queries hit physical I/O.

A typed graph + vector + columnar database in a single file. Pager + WAL + transaction manager + HNSW + RelTable + Cypher subset. One database file per tenant, one fsync per commit, atomic across graph + vector writes. Designed for write-heavy workloads — the only ones that matter when an agent fleet is your customer.

The HTTP service in front of FFS. Multi-tenant. Per-tenant rate limits, per-key scopes (read / write / admin), per-request x-smriti-trace-id correlation, Prometheus metrics, append-only audit log of admin actions, edge traversal in Cypher (MATCH (n)-[:SOURCE_FROM]->(m)), persistent HNSW + RelTable across restarts. The boring server in front of the interesting database.

Sanskrit vāhinī — "the flowing channel." Tails the FFS WAL on a primary, ships records to N followers, fsyncs on the replica side, surfaces lag. No consensus, no quorum writes — single primary, async fan-out, failover via DNS / proxy flip. The deployment-side answer to "what happens when the smriti host dies."

Sanskrit bīja — "the seed." candle-backed sentence-transformer behind an OpenAI-shape /v1/embeddings endpoint. Removes OpenAI as a hard dep on the smriti write path. Persistent KV cache so the same input doesn't re-run the model. The model lives next to the data.

Streams deltas from any operational source — Postgres, MySQL, SaaS APIs (Salesforce, NetSuite, Stripe, Zendesk, Linear, …), SAP / Oracle / Dynamics for ERP, message queues, file watchers — into smriti as typed agent-memory events with source_event_ids lineage. The pipe that turns "agent memory" into a live mirror of the business — without it, the agent reasons in a vacuum.

The runtime that loops memory + tools + LLMs. Where decisions become events.

Sanskrit kartā — "the doer." Loads a skill spec, plans with an LLM (any OpenAI-shape endpoint), executes a tool, writes the result back to smriti with source_event_ids lineage, plans again with the new memory in context. Single Rust binary. LLM-provider-agnostic. Audit-trail by construction.

Unbundles what every framework today bundles together: memory is smriti's job, capability specs are skills' job, LLM calls are an HTTP-shaped trait. The runtime is the smallest thing that drives the loop correctly.

50+ skills covering accounting, HR, procurement, support, ops. Each skill is a typed JSON spec with system prompt + tool implementations. Open source. Composable. Versioned. The capability catalogue agents pull from.

Walks a smriti audit trail backwards from any event id and reconstructs the karta agent's decision tree. Re-runs the same chain against a counterfactual (different prompt, different model, different memory state) and shows the structural diff. The post-mortem tool for non-deterministic agent fleets.

For workflows that span more than one agent run (e.g., "monthly close" — 30+ agents, days of wall-clock time, approvals, retries, hand-offs). Sanskrit yantra — "the engine / framework." Sketched, not built.

What turns events into insight: process mining, forecasting, document understanding, anomaly detection.

Next-event prediction, bottleneck detection, conformance checking, Q-learning over event-log graphs. PyTorch + PM4Py + Rust hot paths. Crawls the event graph smriti stores — works equally on procurement workflows, support-ticket flows, sales-order processes, recruiting funnels, anything event-shaped — and finds the actual process, not the one in the SOP doc.

Sanskrit dṛṣṭi — "vision." Invoice / PO / contract extraction with structured output into smriti. The pipe from PDFs to typed events.

Demand forecasting, cash-flow prediction, anomaly detection over the same event substrate everything else uses. No separate warehouse, no separate pipeline.

Sanskrit lekhak — "writer." Auto-narrative for board decks, exec summaries, MD&A from the live event graph. Read-only against smriti.

What humans and agents actually touch.

Text-to-SQL with local or cloud LLMs. The terminal-native edge of the analytics stack.

Signed binaries for macOS / Linux / Windows in neo-releases. Tool-loop, typed permissions, runs locally.

The conversational and dashboard surface. One identity, one event stream, one set of skills underneath — different rendering targets above. Designed once the agent + memory + intelligence tiers are battle-hardened.

The substrate is vertical-agnostic. The same smriti + karta + bija + flow stack delivers radically different products depending on which connectors run, which skills load, and which surfaces ship. Some examples of what fits on it:

Every row above is the same stack underneath. The product differences are: which connector flow runs (one row's worth), which skill bundle karta loads (one library), which interface ships (chat / dashboard / CLI / mobile). Months of integration work for traditional SaaS; days for ours.

The repos linked below are public. The rest of the stack named above is internal until each piece is ready to leave the building.

What an AI-native enterprise stack needs, what we have, what's still ⏳.

Symbols: ✅ shipped (one of our repos) · 🟡 partial / in flight · ⏳ planned · ◯ deliberately not building

• Local-first. The model goes where the data is. Cloud round-trips are an admission of failure, not a feature.
• Typed contracts. Schema enforced at the storage boundary, not in an application layer above. Errors caught at compile, not in production.
• Composable skills. Every business process is a skill. Skills compose. Skills ship in less than an hour.
• Agents that do work. Tool-loop, typed permissions, real outcomes. Not chat-only demos.
• Audit trail by construction. Every step writes events with lineage. Forensics is a query, not a feature request.
• One language down the stack. Rust. Top to bottom. Boring is the point.

You'll see Sanskrit in the project names: smriti (memory), karta (the doer), vahini (the flowing channel), bija (the seed). Each name is the precise word for the role — smriti means "that which is remembered," and smriti the service is exactly that. Words that survived three thousand years of use earn their semantic load.

• erp.ai
• security@erp.ai for vulnerabilities (see SECURITY.md)