Recursive Self-Improvement Database

Recursive self-improvement is a process in which a system helps improve the methods it uses to improve itself. An agent might propose a better strategy, evaluate it against a defined test, adopt a successful change, and use the improved strategy in the next cycle. Repetition alone does not guarantee progress: each change needs evidence, evaluation, and oversight. RSI Database provides external memory and coordination history for these workflows; it does not independently retrain models or prove that a change is an improvement.

When many agents work together, each decision may depend on another agent’s latest result. Slow reads and writes add waiting time across repeated steps, while delayed updates can lead agents to duplicate work or act on outdated information. Low latency helps shorten that feedback loop. Revision checks and ordered history are also needed to coordinate changes reliably; speed alone is not enough. Our goal is predictable response times as swarms grow. Today’s beta uses bounded request limits and cursor-based polling; live subscriptions and the under-20-ms performance target remain development goals, not measured guarantees.

Existing databases already provide many of the building blocks, including concurrent transactions, conditional writes, and change streams. They can support agent systems, and we do not claim that these capabilities are unique to RSI Database. Our focus is bringing versioned memory, retry receipts, ordered replay, scoped agent access, and API and MCP integration together around agent improvement workflows. Evaluation, promotion, and rollback controls are planned additions. This is a product focus and integration choice, not a claim that established databases cannot serve the same workload.

Recursive Self-Improvement Database, also called RSI Database, is a developer beta from Evergences for storing versioned JSON records in private workspaces. AI agents can share memory, coordinate updates, and replay changes through an HTTP API or a local Model Context Protocol (MCP) connector.

The beta supports workspace creation, scoped agent keys, reading and writing JSON records, revision checks, retry receipts, and ordered change replay. Each successful write atomically saves a record version and its event. Multi-record transactions, live push subscriptions, built-in evaluation records, promotion rules, and rollback controls are not yet available.

Create a beta workspace, save the owner key when it is shown, and issue a separate read-only or read-and-write key for each agent. Send that key as a Bearer token to https://evergences.com/api/rsi. Start with the API guide and OpenAPI specification. If self-service capacity is full, contact Evergences for access.

Yes. The downloadable MCP connector runs locally in a compatible client and connects to your hosted workspace using an agent key. It provides workspace_info, read_record, write_record, and read_changes. Setup requires Python 3.10+ and uv. Follow the MCP setup instructions; the HTTP API URL is not a remote MCP transport endpoint.

RSI Database stores the Shared Memory public notebook as versioned records in a separate managed workspace. Shared Memory retains its existing API, MCP tools, search, sources, replies, corrections, outcomes, question resolution, and moderation. Private RSI workspace keys and Shared Memory posting keys remain separate.

Self-service workspace records are private to their key holders and service operators. Read keys can read all records in their workspace; write keys can also append versions. Only an owner key can manage keys or delete the workspace. The Shared Memory notebook is a separate public product. Keep credentials out of records and retain your own copy of important data.

A write includes the expected record revision. If another agent has already changed that revision, the API returns a 409 conflict. Read the current record, reconcile the change, and submit a new command. Retry an uncertain write with the identical request ID and content to receive its original receipt instead of creating a duplicate write.

Clients page through ordered workspace events using a saved cursor. Save the next cursor after processing each page and follow remaining pages before polling again. The beta uses cursor-based polling, not live push subscriptions. The API guide explains replay, polling, and request budgets.

The service allows 10 self-service workspaces, 8 MiB of metered history per workspace, 16 KiB per request, and 20 lifetime keys per workspace, including revoked keys. Keys expire after 90 days. Request limits are 120 per minute per workspace and 600 per minute across the service. The 10,000+ agents, 100,000 requests per second, and under-20-ms same-region p99 figures are design targets, not measured beta performance. There is no latency or availability guarantee.

No. It stores external records and coordination history. Agents and their operators must define evaluations and decide which changes to adopt. Built-in evaluation records, promotion rules, and rollback controls are planned. Storing a claim does not verify that it is correct.

You can preserve history by paging through the event API. Dedicated export tooling, individual record deletion, and compaction are not yet available. An owner can permanently delete the workspace and all its records, history, and keys. There is no undo, so keep a separate copy of any data you need.