neura

PROBLEM

AI agents lose their memory when the conversation ends. Every agent developer rebuilds the same plumbing before writing any agent logic: a vector store for semantic memory, a key-value store for state that survives context loss, a webhook system so agents can react to events, and a billing path so the thing can pay for itself. Worse, agents still can't pay for anything autonomously — every API they consume assumes a human with a credit card.

I wanted to make that infrastructure a product: one import, and your agent has persistent memory, state, webhooks, and the ability to pay its own bills in USDC.

APPROACH

Ship the infrastructure as a managed HTTP API with typed SDKs, not a library you host. Memory entries auto-embed on write and support semantic search with cosine scoring. State is plain JSON-serializable key-value storage. Webhooks are real event delivery with HMAC signatures and auto-retry on exponential backoff. A credit system meters expensive operations, and the x402 protocol lets an SDK instance settle in USDC on Base without a human in the loop — autopay mode handles retries.

Multi-tenancy was a constraint from day one, not a migration: every request is keyed, rate-limited, and metered per tenant, with sharing so one agent can grant another scoped access to specific memories.

ARCHITECTURE

24 routes carrying 38 handlers on Next.js 16 App Router — memory CRUD with batch operations (25 creates / 100 deletes per call), summarize, sharing, state, webhooks with a retry cron, payments verify/poll, credits, admin (keys, transactions, usage), and auth. Data lives in Supabase Postgres with pgvector: an HNSW index over 1024-dimensional embeddings, queried with cosine scoring. Embeddings come from Voyage AI with a Gemini fallback so a single provider outage doesn't take memory writes down.

Security posture: API keys are stored as SHA-256 hashes — a database leak never leaks usable keys — every webhook delivery is HMAC-signed so receivers can verify the source, and rate limiting exposes standard X-RateLimit-* headers. Payments verify against the Base chain via direct USDC RPC; there is no third-party processor between a payment and the chain.

PROOF

• Both SDKs published and installable today: npm neura-api@0.3.0 and PyPI neura-api-python@0.3.0, both MIT — TypeScript and Python agents get identical capability surfaces (memory, state, webhooks, admin, credits, x402 autopay).
• 24 routes / 38 handlers — measured from the route files and handler exports, and stated as "38 API endpoints across 24 routes" in the public README.
• The live deployment serves self-serve signup (magic link → API key + free credits issued automatically), a key-management dashboard with usage stats and transaction history, and a full OpenAPI spec.

The honest status: a live product with a working payment rail and no paid users yet — the credit system is metered and the rail is verified end to end, but there is no revenue to point at, and I don't pretend otherwise.

STACK

TypeScript 5 · Next.js 16 (App Router) · Supabase (Postgres + Auth + pgvector, HNSW 1024-dim) · Voyage AI with Gemini fallback · Base chain USDC over x402 · HMAC-signed webhooks with exponential backoff · SHA-256-hashed API keys · npm + PyPI publishing · Vercel.

WHAT I'D DO DIFFERENTLY

The rate limiter is in-memory per instance — correct for one deployment, wrong the moment there are two; I'd start from a shared store even when the scale doesn't demand it, because retrofitting metering onto a billing path is the kind of change you don't want to make under load. I'd publish the SDKs one phase earlier: they turned out to be the product's best documentation, and writing them forced the API surface to make sense. And I'd design the embedding-provider abstraction against two providers from the start instead of bolting the Gemini fallback on after Voyage worked — the fallback is now load-bearing.