What Grove carries forward

A shorter request, a longer history

A request can be short because much of its meaning has already been established. A person asks to return to an agreement, prepare the next release, or pick up a decision made last week. The words name the work. Earlier conversations contain the reasons, constraints and corrections needed to do it well.

On September 26, our working agent was asked to revise an agreement around an evolving platform. Before drafting, she consulted memory for the relationship, previous decisions and existing terms. That led her back to the signed document and the relevant earlier work. The draft could then distinguish what needed to change from what had already been agreed. Review exposed further overreach; she corrected it and sent the drafting milestone and corrections back to memory.

That sequence captures why we built Grove. We wanted useful context to survive the conversation that produced it, remain connected to its sources, and be available when the work returned. Grove grew out of the persistent memory we built for our own agents. Here we return to that lab system, which continues to develop through daily use.

Our September 29 snapshot contains 3,605 nodes and 9,200 relationships, compared with 2,352 and 6,272 in the August Field Note. The more consequential development is what now happens around those records: context is consulted during work, outcomes are written back, earlier claims are revised, and a separate pass looks for patterns across the accumulated experience.

Before the answer

The person using the agent does not have to construct a graph query. They make an ordinary request. When the task depends on accumulated context, the working agent asks the memory system a question about the relevant people, project, decisions or history. A dedicated memory agent resolves the names, retrieves the relevant records and follows relationships or corrections where needed. The answer supplies context for the task at hand.

This is a selective read. The whole graph does not need to enter every conversation. A question about a release can recover its purpose, previous decisions and outstanding dependencies; a document task can recover the relationship and the constraints established in earlier drafts. Exact wording can still require the original conversation or document. Current operational state can still require a live check.

That division matters in the agreement example. Memory supplied a route back to the established context. Reading the signed source established what the document actually said. The useful result came from combining remembered history with evidence the agent could inspect during the task.

We built the graph to retain routes back into the work: who owns it, which decisions constrain it, what it depends on, and where its supporting evidence can be recovered. Those relationships give retrieval a direction. A useful answer can bring back the relevant context and identify what still needs to be checked, even when the original material is too large or too specific to keep in the prompt.

From the user's side, the intended benefit is continuity. A reference to earlier work should be enough to begin recovering its situation. The person can spend the next exchange changing or advancing the work, with less of the exchange devoted to rebuilding the briefing.

What a turn leaves behind

Retrieval only explains half the experience. A useful turn can establish a new decision, correct an assumption, complete an action or reveal a constraint. Those changes are candidates for the next memory update.

The reviewed sessions make the deliberate route visible: when substantive work produced something worth retaining, the working agent sent the memory agent an explicit account of what changed. In the agreement task, the updates included the new drafting milestone and, after review, the corrections to the proposed approach. The memory agent is instructed to reconcile that account with what is already stored. It can update current state, add an event, attach evidence, or preserve a disagreement for resolution. Writing another summary is only one possible response.

The operating rule gives the close of a turn a particular purpose: check whether anything worth retaining has happened that has not already been directed to memory. The reply can also show the resulting receipt: what was written, proposed or declined. The person sees what the system carried forward and can challenge a mistaken interpretation. A completed draft can be recorded as a draft; it must not silently become an accepted agreement.

There is also a background route. The operating system watches conversation records for new material and processes their changes asynchronously. The two routes serve different purposes: an explicit update can preserve the significance of an outcome while it is still in view; background ingestion can recover relevant material without depending entirely on that closing habit. A reply can finish before this background work completes. The system does not enforce a memory commit before every reply.

This makes the completion of substantive work a meaningful design boundary. The work has produced evidence that did not exist when it began. Retaining the decision, its reasons and any correction gives the next turn a better starting point. Retaining an unchecked assumption can propagate the mistake. The write deserves as much attention as the read.

We design this as learning at the level of the working system. The person directs and reviews; the agent retrieves and acts; tools expose evidence; persistent records carry selected results into later work. A correction can change the context available to the next task without changing the model's weights. That is the mechanism we can inspect: what was retained, how it was revised, and whether it was recovered when it became relevant again.

How the system grew

We began with a practical continuity problem: decisions, responsibilities and the reasons behind them needed to survive changes of session. A typed graph gave those records a shared structure. People, projects, work items and decisions became distinct kinds of node. Relationships could say who owned something, what depended on it, or which observation supported a conclusion.

The early operational account recorded 432 nodes and 1,117 edges around a major revision of the system. By the Grove release, the published snapshot was 781 nodes and 2,524 edges. August's note made the operating graph visible. September added another test: two agents working through different vendors' environments could consult the same memory. That migration retained one shared store, with knowledge maintenance owned by one agent rather than independently managed copies.

The structure has become more deliberate as it has grown. Current entities and work state form a relatively stable framework: a project, its owner, a goal, a blocker. Dated events and observations record what happened around that framework. A report that a dependency was unavailable on Monday remains a record of Monday. When the dependency returns on Tuesday, the current blocker should change state and the new event should be attached. The earlier event need not become false or disappear.

The current graph contains fourteen node types and forty-seven relationship verbs in use. It includes 1,712 observations, 803 events, 382 decisions and 87 patterns. Together, those four classes account for about 83% of its nodes. They show the kind of material the system is retaining: occurrences, interpretations, choices and recurring lessons around the work.

Growing also means revising

The maintenance loop now has three phases. Update interprets incoming activity and relates it to existing knowledge. Cleanup checks existing regions of the graph, including stale state and claims due for verification. Consolidation looks across accumulated records for contradictions, patterns and connections that a local update may miss.

These run at different rhythms. The loop can check for new work frequently; expensive checks are paced, and consolidation waits for enough change or a reason to revisit the wider graph. For conversation ingestion, a successful update advances the record of what has been consumed. A failed update leaves that position unchanged so later processing can retry. Reliability depends on this surrounding machinery as well as on the quality of the model's interpretation.

The seven-day record ending on September 29 shows this work alongside growth: 247 newly created node records, 558 node records revisited after their initial creation, and 26 new relationships whose endpoints were already established when the relationship was added. These are separate counts and can overlap; repeated edits to one node count once in the update figure. They establish that the system is revisiting and connecting existing knowledge as it adds new records. They do not measure how many of those changes improved an answer.

We keep two questions about time distinct: when did something become true, and when was it recorded? A change can be reported after it happened. Grove stores validity intervals and an append-only history of node changes, with limits on what earlier states can be reconstructed. If an agent learns on Friday that a blocker cleared on Wednesday, the record should preserve both the change in the work and when the system learned about it. That distinction matters when recovering what was known at an earlier decision.

We treat the route back to evidence as part of memory quality. Grove retains source labels, locations for verification and reasons for changes so an agent can investigate a stored claim. In the agreement task, that route ended at the signed document, where the wording could be checked directly. A record becomes more useful when it preserves enough context to repeat that check. Attaching a source alone does not establish that the source supports the claim.

This has been a substantial part of building the system: making ingestion failures visible, keeping source information through reads and restores, preserving corrections, and renewing verification metadata without rewriting an event's historical claim. A larger memory gives those requirements more consequence because more later work can depend on what it holds.

Looking at what has accumulated

The viewer gives the person working with Grove another way to inspect it. Companies and projects anchor the map; their connected records shape the surrounding regions through a configured layout. Selecting a node focuses its neighborhood. Type filters change what is visible, and relationship labels become available through the view's selection, zoom and hover behavior.

The daily additions are particularly useful. Clicking a positive growth counter highlights nodes or relationships added since the most recent earlier daily snapshot. A person can see where new material accumulated and inspect it. The counter reports additions; changes to existing records need a different inspection. It should not be read as a measurement of everything learned that day.

The current header also reports 2,904 active nodes. Here, active excludes ended, shelved and prospective states, as well as records whose validity has ended. It is not a count of simultaneous tasks. The active-only view filters further, hiding several classes of running record to make the more durable structure easier to see.

Visualization makes the memory available for questions that are hard to ask from an answer alone. Where did this week's work leave a trace? Is an old blocker still attached to the project? Does a recorded conclusion have the relationships we expect? The map helps direct inspection. Source checks still determine whether the account is right.

What the next conversation inherits

Another September 26 session shows why that history matters. A request to add error visibility to a dashboard suggested returning to a good/average/bad grading view. Memory recovered why that view had been retired: the grader had seen truncated answers without the tool work that gave them meaning. The working agent carried that constraint into the investigation, checked current telemetry and code, and built a reliability view that distinguished external-provider incidents from failures in the product. An explicit update after the build retained both the delivered section and the decision behind the distinction.

The relevant gain was specific. A discarded approach came back into consideration, and its reason for being discarded came back with it. The next implementation could build on that experience. In a separate release session, a short request to do the usual drew on earlier procedures and communication conventions; when memory had no record of the new release, live checks supplied the missing state. Continuity includes knowing where the remembered account stops.

The broader change is that more of the working relationship can survive a session boundary. Background can be recovered; earlier decisions can guide a new draft; a correction can remain connected to what it corrected; another agent can consult the same history. These are concrete forms of continuity, and the session records let us inspect how they are used.

They also suggest a more useful evaluation than graph size alone. Can an agent resume work with less rebriefing? Does it recover a constraint omitted from the latest request? After a correction, does the next relevant task use the corrected account? Can it trace a claim to supporting evidence, recognize missing context and check state that may have changed? The answer needs to include retrieval time, maintenance cost and failures alongside successful examples.

What we have now is a richer working record and a visible mechanism for carrying it forward. Grove's value becomes tangible when a new request draws on decisions already made, checks the evidence that matters now, and leaves behind a more useful account for whoever picks up the work next.

Observation notes

The September graph snapshot was generated on September 29, 2026 at 06:23 UTC. Counts cover the full local operating graph, including retained history. They measure stored records and relationships, not unique verified facts or completed jobs. The August comparison comes from the published August 6 Field Note; the earlier checkpoints are figures reported in the series and release page. Growth includes ordinary ingestion, revision and changes in coverage, so these snapshots do not isolate an effect of elapsed time or usage.

The seven-day maintenance window ends at 06:21:49 UTC on September 29. New-node counts exclude restore replays. The update count includes nodes whose latest update fell in the window more than one hour after creation; the new-relationship count requires each endpoint to predate the relationship by more than one hour. These counters describe stored state, not a complete log of edit operations.

The examples were reconstructed from original working sessions and checked against recorded source reads, outputs and memory directives. They are selected cases, not a representative performance sample. Client and personal details have been omitted. The implementation description was checked against the running system's current local code and operating records; it is not a claim that every change is packaged in the public Grove release. The schematic figures explain the mechanism and contain no private graph records.

Contact

If these questions are relevant to work you are running, please get in touch.