Chapter 7

The Being That Uses Memory

Chapter 6 ended with the observation that memory does not move on its own; someone has to read it. This book calls that someone the Agent.

1. An Agent is shaped by what it reads

Even with the same model, behavior changes with what the model is given to read. An Agent that sees only the present question and an Agent that also sees past decisions and records of failure look at the same problem differently.

So defining an Agent as a model is not enough. We also have to say what memory it reads, which tools it may use, which rules it follows, and what it must not do.

An agent is what it reads.

Chapter 3 said that context conditions the answer. For an Agent, that context is the condition of its actions.

2. What it means to give an Agent memory

Handing an LLM one tool that searches the graph does not make it an Agent with memory. What matters is that the Agent's work itself is tied to memory.

If the Agent reads the present situation, finds the relevant Concepts, checks past Decisions, avoids approaches that already failed, and proposes new memory when needed, then the graph is more than a knowledge store. It is the Agent's working context.

The Agent is not a consumer standing outside the graph. It reads memory and, in turn, acts on memory.

3. An Agent can itself be in the graph

Think of an Agent only as a prompt or a bundle of code and it becomes hard to change roles or connect several Agents. So in Vinc, a Role is a node.

The Agent stops being a bare executor and becomes a graph node that carries a contract. Part of the orchestration then surfaces outside the code. Who is responsible for what, what they must read, what they must not do, and under what conditions the work moves on can all be read from the graph.

4. An Agent's node is not a fixed manual

That an Agent is a node does not mean its content is frozen. Real work keeps changing.

A role begins simply and a new problem appears during the work. Another Agent passes on new information, the Agent discovers its own failure, a person changes the priorities. So the memory tied to the Agent's state and role has to be able to change too.

The important distinction is that a node's identity and a node's content are not the same thing. The Agent continues as the same Agent while what it knows, and the state of what it is doing, change.

These values change over time. But the change must not be an arbitrary overwrite. What changed, and why, must be traceable. Only then do we remember not just the Agent's present state but the path that led to it.

So the graph is not a static organization chart declaring roles. It is a living structure that carries the state of work in progress and what has been learned along the way.

5. Conversation between Agents, and workflow, become memory

When several Agents cooperate, what one discovers changes how another acts. A Design Agent finds a constraint during implementation and passes it to an Implementation Agent, and the conditions of the next task change. A Verification Agent finds a new cause of failure, and the Agents after it avoid the same mistake.

What matters here is not the conversation but how the graph's meaning changes because of it. When an important discovery is promoted into memory, it becomes the next Agent's context. One Agent's experience becomes another Agent's memory.

The same goes for the order of work. A sequence of Design, Implementation, Verification and Delivery could be hard-coded into orchestration. Expressed in the graph, the relationships between Agents are themselves remembered. Who hands results to whom, on what condition the work moves on, and which role depends on which can be read from the graph.

Workflow is a relationship too.

6. One failure becomes memory for the next task

An Agent can make mistakes while it works. What matters is that the failure does not disappear into a log.

If the cause of the failure is worked out and kept as memory that applies to a particular role or task, the next Agent can read it.

One failure becomes a constraint on the next task. Past failure changes present behavior, and present experience changes future Agents. This is the moment the graph goes beyond storage and becomes a structure that keeps the traces of learning.

7. Providing memory and enforcing action are different things

There is an important limit here. Recording an Agent's role and rules in the graph does not mean the graph physically blocks every action.

The graph can give a contract, a reading list, recorded prohibitions and a workflow. None of that, by itself, enforces every prohibition automatically.

So Vinc's graph is neither a scheduler nor an executor. It is a structure of memory that describes the context in which an Agent should act. The Agent reads it and acts, and control of permissions and execution is handled, where needed, by separate systems.

8. The Agent is both user and producer of memory

At first the Agent looks like something that takes memory out of the graph. But the flow runs the other way as well.

The Agent reads memory from the graph, judges on the strength of it, does the work, and along the way produces new facts, failures and decisions. Those are recorded back into the graph.

The Agent is a user of memory and, at the same time, a producer of new memory.

One problem remains. If an Agent reads memory and acts on it, what happens when that memory is wrong?

That is the next chapter.

Continue with Chapter 8, Can We Trust Memory?.