LLM Orchestration with Geometry-Aware Memory

Flat memory forgets structure

Knowledge about a domain is a hierarchy: a few broad ideas, many specific ones. Here is an illustrative taxonomy of ~200 concepts (six domains, then areas, topics and leaves), the shape of the domain knowledge the paper's memory holds, drawn the usual way in the flat Euclidean plane.

Every ring of the drawing shares one circumference. Each level has about three times as many nodes as the one above, but the room for them grows only linearly, so the ~120 leaves end up a few pixels apart.

Radial tidy tree, Euclidean plane. Node colour encodes depth, teal (root) to brass (leaves). Hover a node for its label.

fig. 01 · Euclidean plane, radial tidy tree

The same tree in the Poincaré disk

Every edge now has the same hyperbolic length τ (here τ = 1.1). The picture looks squeezed towards the rim only because we are looking at hyperbolic space through a Euclidean window; the node markers shrink with the metric. In the geometry itself, nothing is crowded.

Sarkar layout in the unit disk, computed in the browser by sarkarLayout.

fig. 01 · Euclidean plane, radial tidy tree

Exponential room

A hyperbolic circle of radius r has circumference 2π sinh r, not 2π r. The rings are drawn at r = 1 … 4. A tree whose levels grow like b^depth needs exactly this kind of room, which is why it embeds with almost no distortion (Sarkar, 2011), and why the paper stores hierarchical domain knowledge in the Poincaré ball $\mathbb{B}^n=\{x : \lVert x\rVert<1\}$.

Dashed rings: hyperbolic circles of radius 1 to 4 about the origin.

fig. 01 · rings at hyperbolic radius 1 to 4 · Poincaré disk, Sarkar layout

Flat or hyperbolic? Same tree, your query

The same ~200-node tree embedded two ways with the same edge length τ = 1.1: a radial tidy layout in the Euclidean plane, levels τ apart, and Sarkar's layout in the Poincaré disk. Type a concept. The best-matching node by label becomes the focus, and each space marks its six nearest neighbours by its own distance: teal if the neighbour is a true relative (within two tree edges), amber if it belongs to another branch.

no focus yet · type a concept or pick a chip

Neighbour precision: the fraction of the six that are true relatives. Distortion: mean |d_embedded / (τ · d_tree) − 1| over 400 random pairs, computed once per layout. Nothing is scripted; if a node contradicts the expected pattern, the numbers say so.

fig. 02 · left: radial tidy tree, levels τ apart · right: Sarkar layout, τ = 1.1 · badges 1–6: nearest neighbours

What the open-source benchmark measures

Mean average precision for reconstructing the WordNet mammal.n.01 subtree (1,170 nodes) from embeddings of dimension 2, 5 and 10, Poincaré against Euclidean, from the open-source benchmark in poincare-memory, not from the system in the paper.

The honest reading: two hyperbolic dimensions (0.779) land close to five Euclidean ones (0.802), and five hyperbolic dimensions (0.975) beat ten Euclidean ones (0.837) on this task. The same fidelity needs fewer dimensions, which means a smaller index and less compute per query. The benchmark measures MAP only; no timings are claimed.

MAP, higher is better. From the open-source benchmark, WordNet mammals, 1,170 nodes.

fig. 02 · the two embeddings stay on the stage · the bars are the open-source benchmark, not this tree

Geometry 101

The ball carries the paper's metric, the Euclidean one rescaled by a factor that blows up near the boundary:

Drag x and y. The shortest path between them is an arc of a circle that meets the boundary at right angles, a straight line only when it passes through the centre.

x in brass, y in teal; the solid curve is their geodesic. d(x, y) = —

fig. 03 · x in brass, y in teal · the solid curve is their geodesic

The distance formula

The straight-line length is only ‖x − y‖ = —. Near the rim the denominators shrink and the hyperbolic distance grows without bound: the boundary is infinitely far away.

Dashed: the Euclidean chord, for comparison. Numbers update as you drag.

fig. 03 · d(x, y) = — · dashed chord for comparison

Distance from the centre is depth

In the memory, the root of a hierarchy sits at the origin and each level is one edge length τ further out. Slide p outward: its distance from the centre, $d(0,p)=2\,\operatorname{artanh}\lVert p\rVert$, is what retrieval reads to tell general from specific.

d(0, p) = — · depth at τ = 1: —. Rings at hyperbolic radius 1 to 5.

fig. 03 · p slides along a radius · rings at hyperbolic radius 1 to 5

Embedding a hierarchy

Sarkar's construction, level by level. The hierarchy is a textbook sketch of the body, ~40 nodes: body → systems → regions → muscle groups → muscles. (The paper's evaluation domain is the biomechanics of athletic performance; this tree is a generic stand-in, not the paper's data.)

Step 1. Put the root at the origin.

The root, "body", at the centre of the disk.

fig. 04 · Sarkar construction · τ = 1.0 · 43 nodes

Children at distance τ

Step 2. Place the root's children at hyperbolic distance τ, at evenly spaced angles. Every edge in the finished embedding will have exactly this length.

Dashed ring: the circle of hyperbolic radius τ = 1 about the origin.

fig. 04 · the root's children on the ring d = τ

Recurse: translate, place, translate back

Step 3. For each placed node v, Möbius-translate the whole picture so that v sits at the origin, $z\mapsto(-v)\oplus z$, place v's children at distance τ in the directions that avoid the parent, then translate back, $z\mapsto v\oplus z$. Both moves are isometries, so nothing already placed changes shape. The camera does the same move for the musculoskeletal subtree, then the rest is built.

Scroll drives the construction; the cross marks the origin while the camera is translated.

fig. 04 · the cross marks the origin while the camera is translated

Ancestors, descendants, depth

Hover or tap a node. Its ancestors light up brass, its descendants teal, and the readout shows its distance from the origin. A query that lands near quadriceps can walk inward for context (lower limb, musculoskeletal) or outward for specifics (rectus femoris, vastus lateralis). This is the hierarchy-aware retrieval the paper describes: similarity that accounts for both semantic content and structural relationships.

A free-text query has no depth of its own, and a point near the centre of the ball is close to everything. The reference implementation therefore measures semantic similarity on a reference shell (direction only) and applies depth and ancestry as explicit structure; that is how it realises the paper's retrieval. Chapter 05 lets you type such a query.

—

fig. 04 · hover or tap a node · ancestors brass, descendants teal

Drag the disk

Drag the empty disk. That is a hyperbolic translation of the camera: edges stay geodesics and every parent–child distance stays τ; only the Euclidean window moves. Bring any leaf to the centre to read it. Zooming in hyperbolic space is exactly this, a move of the focus toward the origin, never a change of scale.

The whole embedding under a Möbius translation; nothing is rescaled.

fig. 04 · drag the empty disk to translate the camera

Time-weighted memory

Memories carry a timestamp. The paper's memory uses time-weighted embeddings: geometric proximity is multiplied by a recency weight, so at equal hyperbolic distance newer evidence wins. Each memory here is attached to the node it is about; its label shows its age in days.

Twelve dated memories around the anatomy tree (teal notes and logs, brass facts); opacity is the recency weight.

fig. 05 · twelve dated memories beside their nodes · opacity = weight

Three ways to forget

The reference implementation ships three curves: an exponential half-life $w=2^{-\Delta t/h}$, the Ebbinghaus curve $w=e^{-\Delta t/S}$, and a validity window that holds full weight then ramps to zero. Move time forward and watch the memories slide down the curve.

Weight w(Δt) against age in days; dots are the memories at their current age (facts have a 12× longer stability than notes, logs 3×).

fig. 05 · half-life · t = 0 d · weight = opacity

Ask the memory

Type a query. It is embedded by the same offline hashing embedder the reference implementation uses (word and character n-gram features, keyed BLAKE2b, 256 dimensions), as is every memory here: the 43 anatomy nodes and the twelve dated notes. Similarity is measured on the reference shell at the root depth, direction only; score = e^−d · w(Δt) with the curve and time position set above, so a fresh clinical note outranks an older one at the same distance and, as it ages, durable facts climb back.

query embedded (256-d, hashing)

Top five by time-weighted score: score, shell distance d, age and weight. The badges on the disk are the ranks; the brass diamond sits on the shell at the angle of the top match, a visual proxy, since the disk draws the tree, not the 256-dimensional embedding.

fig. 05 · badges 1–5 = the ranking · diamond = query on the shell at the angle of —

Add a note

Write a note and give it an age. It is embedded, attached under the node whose name it matches best, placed one depth step beyond that node (a Sarkar step: translate the node to the origin, place at τ, translate back) and it joins the ranking at once, decaying under the current curve.

nothing added yet · the note stays in this page

Added notes are drawn with a pale outline, one depth step beyond their node, and appear in the chart and the ranking above.

fig. 05 · added notes: pale outline · one depth step beyond their node

Metacognitive controller

Before any model is called, the controller analyses the query and decomposes it into coordinated sub-tasks:

The query here, shaped after a sample run of poincare-orchestra: an athlete's calf tightens in the last hundred metres of 400 m repeats; plan the next fortnight. Four sub-tasks, one per focus the analysis found.

Left: the query. Centre: sub-tasks q₁ to q₄ fanning out along particle ribbons.

fig. 06 · eq. (5) decomposition · Q at the left, q₁–q₄ along the ribbons

Capability matching

Each sub-task is matched against the capability profiles the ensemble maintains, which here means a specialist role: physiologist, biomechanist, strength coach, analyst. The memory enters twice. It tells the controller how deep each sub-task sits in the domain hierarchy, and it supplies the context the sub-task is answered against.

The small disk is the memory; each sub-task's dot sits at its depth.

fig. 06 · small disk = the memory · each sub-task's dot at its depth

Allocate compute where it buys information

G is the expected information gain of spending inference budget I on q_i, C its cost. The bars grow with the ratio; a sub-task whose ratio does not clear the remaining budget is skipped rather than answered badly.

Gain and cost values follow the shape of the sample run; the ratios and bars are computed live.

fig. 06 · eq. (6) allocation · bars grow with G/C · amber = skipped for budget

Ensemble and throttling

The ensemble is provider-agnostic. Each provider gets a capability profile, every response is normalised to one standard schema so the synthesiser never sees provider quirks, and requests are load-balanced across providers.

Lanes for provider-a, provider-b and provider-c; particles are requests; traces show latency, length and density.

fig. 07 · three provider lanes · particles are requests · traces: latency, length, density

Throttling detection

A provider under rate limiting rarely says so. The paper's detector watches three things instead: response patterns, computation time and information density. Here provider-b's latency climbs while its answers get shorter and thinner; each signal is standardised against the provider's own baseline and combined.

latency z 0.0 · length z 0.0 · density z 0.0 · score 0.00

Amber marks the request at which the combined score crossed the threshold.

fig. 07 · request 1 of 24 · detector threshold 1.6

Failover

Once flagged, the provider is taken out of rotation and its pending sub-tasks are reissued to the others; it is probed again later and readmitted when its signals return to baseline. No sub-task stalls, and the synthesiser downstream sees the same response schema either way.

After the flag, request particles flow only to provider-a and provider-c.

fig. 07 · request 1 of 24 · after the flag, particles reach provider-a and provider-c only

Synthesis

Answers from several models and from the memory are fused into candidate responses R and scored on several objectives at once:

The objectives here are the ones the open-source synthesiser reports: coverage, density, agreement between sources, recency and cost. Seven synthetic candidates are scored live by the formula.

Each dot is a candidate; x is the cost score (right is cheaper), y the weighted quality.

fig. 08 · eq. (7) · x = cost score (right is cheaper) · y = weighted quality

Weights move the choice along the front

The brass marker is R*, the feasible candidate with the largest J; it slides along the front when the weights change.

fig. 08 · brass ring = R*, sliding along the Pareto front

Floors, uncertainty, refinement

A candidate may trade objectives against each other but never fall below a floor ε_j on a constrained one; here coverage ≥ 0.5 and cost score ≥ 0.2, drawn as lines. Hollow dots violate a floor and can never be chosen, however the weights are set. The fused answer carries an uncertainty estimate; when it is high the controller sends the weakest sub-task back round the loop: iterative refinement.

ε lines in amber; infeasible candidates hollow.

fig. 08 · ε lines in amber · hollow dots violate a floor

Cite and build

D. Mojila ORCID 0009-0007-9596-7503, "LLM Orchestration with Geometry-Aware Memory," 2026 2nd International Conference on Big Data & Machine Learning (ICBDML), Bhopal, India, 27–28 Feb. 2026, pp. 1–7. DOI: 10.1109/ICBDML68582.2026.11544690.

@inproceedings{mojila2026llmorchestration,
  author    = {Mojila, Dhruv},
  title     = {{LLM} Orchestration with Geometry-Aware Memory},
  booktitle = {2026 2nd International Conference on Big Data \& Machine Learning (ICBDML)},
  year      = {2026},
  pages     = {1--7},
  publisher = {IEEE},
  address   = {Bhopal, India},
  doi       = {10.1109/ICBDML68582.2026.11544690}
}

• IEEE Xplore · document 11544690
• ORCID · 0009-0007-9596-7503
• GitHub · poincare-memory, the memory in Python
• GitHub · poincare-orchestra, controller, ensemble and synthesis

fig. 09 · the disk settling into its emblem, the {7,3} tiling the page opened with

Build with it

npm install poincare-ball

import { PoincareBall, sarkarLayout, regularTiling, makeDecay,
         shellDistance, hashingEmbed, indexTree } from 'poincare-ball';
const ball = new PoincareBall(1);
ball.distanceArcosh([0.3, 0.1], [-0.2, 0.5]);   // eq. (3)
sarkarLayout(tree, { tau: 1.1 });               // hierarchy → disk
regularTiling(7, 3, 4);                         // the hero tiling
makeDecay('half-life', 14)(ageDays);            // recency weight
hashingEmbed('knee flexion');                   // the offline embedder
shellDistance(query, memory, 1);                // direction only

Every number on this page, distances, layouts, weights, scores, embeddings, metrics and the tiling, is computed in the browser by the poincare-ball library, whose tests run with npm test.

The disk, settled into its emblem: the {7,3} tiling the page opened with, with the memory's depth rings inside.

fig. 09 · the emblem · depth rings 1–3 inside the tiling