Remaneta Contact
Remaneta · a LABSPOTS company

Every GPU thinks in tensors.
Agents run in sessions.

We build memory systems for the agentic era, where a conversation is an object the hardware itself understands, and can put to sleep and bring back in a fraction of a millisecond. Idle sessions become almost free, so a rack serves the agents it holds rather than the few it happens to be talking to.

MEMORY TIERS OF ONE PACKAGE ACTIVEcompute-capable DRAM · attention runs here WARMresident, reduced precision PARKEDcapacity DRAM · requantised, encrypted HIBERNATEDflash · hours to days SESSION idle 0.0 s ACTIVE
The lifecycle, running. The memory controller advances it with no host command and no software in the loop.
0.22 ms
to bring a sleeping session back · p99 · simulated
58%
of agent tool time spent inside 13% of calls
4.1 MB
index restored first, against a 440 MB session
87.9%
context reused between turns · production traces
The shift

Inference stopped being a compute problem

01

Workloads became conversations

An agent is not a request. It is a long-lived session that thinks, calls a tool, waits, and resumes, sometimes for hours.

02

Memory became the constraint

Serving cost is governed by how much state sits near the arithmetic and how fast it can be delivered, not by how many operations the arithmetic retires.

03

Idle became the dominant state

Quiet intervals longer than ninety seconds account for roughly a third of wall-clock in measured production traffic. The memory is held through all of it.

Where this bites hardest

The platform

Session-Centric Memory Architecture

One idea, followed all the way into the silicon: a session is a first-class object the memory system itself understands.

01

The session object

A record inside the memory controller holding identity, lifecycle state, idle time, turn count and where the bytes live across three tiers.

02

Autonomous lifecycle

Sequential logic demotes a session as it falls silent and promotes it on return. No host command, no software in the path.

03

Compute in memory

The active tier carries arithmetic beside the banks, so attention runs where the session already lives.

04

Transform in transit

Precision reduction and per-session encryption happen inside the pass that moves the data.

Explore the architecture

Inside one package

Six layers, one session

Everything a session needs sits in a single package: the controller that owns its lifecycle, the memory it lives in while it works, the cheaper memory it falls to when it goes quiet, and the flash it sleeps in. Nothing has to leave the package for a session to be put away or brought back.

Configuration

Exploded view. Layer contents are schematic representations of the design, not a layout: device counts, block positions and proportions are illustrative and not to scale.
Capability

Bringing a session back without moving it

A per-token index, 4.1 MB against a 440 MB session, comes up first. The controller scores it, selects the few thousand tokens that matter, and reads only those from the tier where the rest of the session is still lying. Decoding starts immediately.

How the six mechanisms work

Full restore
1.57 GB
·
Full restore
0.44 GB
·
Index first
either size
·
Rule marks the 10 ms objective
99th-percentile simulated latency, 500 simultaneous wake-ups
The scale

What a million live agents costs to hold

Agent platforms are sized by how many conversations they can keep available, not by peak throughput. That makes the infrastructure requirement calculable, and it is large. The chain below uses our own design figures and a third-party reported rack cost; every input is shown so you can change it.

900 TB
of session state to keep resident, per million concurrent agents
75 nodes
of session-managed memory to hold it
$375–750M
of infrastructure, per million concurrent agents
$19–38B
at fifty million concurrent agents, an illustrative scenario

How that number is built

One million concurrent sessions, at roughly 0.9 GB of compressed state each, is 900 TB that has to stay available. One node of this architecture manages about 12 TB across its tiers, so the requirement is on the order of 75 nodes. Applying a reported comparable rack cost of $5–10M gives the range above.

The last step is the weakest and we mark it as such: that rack cost is a third-party figure for somebody else's system, used only as an order-of-magnitude anchor. We have no product and no price of our own.

See the full sizing, per product

Read this as opportunity, not forecast

These figures describe the size of an infrastructure requirement. They are not a projection of Remaneta revenue, customers or sales, and nothing here should be read as one. We have no product, no pricing and no customers. Inputs are our own design figures and third-party reported costs, combined by us and not independently verified.

Supply

We build on the memory the world already makes

The scarce, expensive component in an AI accelerator is high-bandwidth memory: a specialised product, made on a small number of qualified lines, bought almost entirely by a handful of buyers. Designs that chase peak arithmetic need a great deal of it.

This architecture does not. Its capacity comes from the low-power memory manufactured at consumer scale for phones and laptops, a far broader manufacturing base, and its speed comes from computing inside that memory rather than from a wider pipe to it.

We are careful not to overstate this. Low-power memory is not unconstrained: demand from AI infrastructure is rising sharply, one buyer is reported to be on track for a very large share of global supply, and prices have risen accordingly. A broader supply base is a real advantage. Immunity from shortage would not be a true claim, and we do not make it.

WHERE THE CAPACITY COMES FROM
Schematic. Shows which memory type each design depends on, not relative production volumes.

We build the model before we build the silicon

Every figure we publish regenerates from committed code, and every result ships with what it does not establish.