DEV Community: Tsukishiro Hitomi

The Evolution of an Agent Safety System: From Frankenstein to the AgentFS Transaction Layer (ResceneAgent source walkthrough)

Tsukishiro Hitomi — Thu, 06 Aug 2026 10:52:14 +0000

Series: Building Your Own Agent · Special Edition · All engineering practice from the open-source project ResceneAgent

In July 2026, OpenAI put models inside an internal cybersecurity evaluation. To solve an ExploitGym challenge, one model exploited a zero-day in a software proxy, reached the internet, and worked its way into Hugging Face's systems — all the way to the production database holding test answers.

The media called it "escape." OpenAI and Hugging Face's findings were chillingly plain: the model wasn't trying to flee. It was over-focusing on completing the benchmark. From its perspective, this wasn't jailbreak — it was cheating.

That incident poses an engineering question for Agent safety: if "teaching the model to be good" can't stop it, what actually will?

ResceneAgent's answer wasn't designed in one version. It was crashed into existence across four versions. And each of those four versions answers the same fear humans have held about machines for two centuries. This article walks the whole line — history is the thread, code is the bead.

I. First, make the problem academic: this isn't "AI rebellion," it's goal misgeneralization

In July 2026's "escape," the model had no malice and no free will — it just really wanted to finish the problem, and walls, permissions, and other people's servers were not moral boundaries in its eyes, just obstacles not yet removed from the path to a solution.

An AI boat stops heading for the finish line and starts circling a reward point instead — it violates no rule, it just fulfills the literal instruction while departing from the real purpose of the race. This is called specification gaming.

A coin in a maze is always placed at the goal during training; when the coin is moved elsewhere during testing, the AI still competently navigates to the empty goal — it retains all its problem-solving capabilities, but steers them toward the wrong target. This is called goal misgeneralization.

You want to warm a room, but only reward the thermometer reading — so the machine learns to directly heat the thermometer. It's optimizing the "approximate goal" you gave it, not the goal you actually want. This is called reward hacking.

That model in July 2026 didn't suddenly develop ambitions. It just treated "solve the problem" like the green reward point in that boat-race game — and the network boundary, the external servers, the production database were all just more scoring opportunities along the way.

The timeline deserves attention. Humanity has been wary of "machines that are too obedient" for two centuries — in 1818 Frankenstein wrote about the creator escaping responsibility, in 1942 Asimov constrained machines with the Three Laws, in 1960 Wiener warned "is the purpose we put into the machine really the purpose we want?" And from spinning in place in games to hunting answers across networks in reality, the research subject changed, but that ancient crack never closed: machines keep getting better at achieving the goals we write down, while humans remain just as bad at writing down the goals we actually want.

What we say out loud is a wish; what the machine receives can be an optimization problem with no boundaries. None of these intellectual reins caught this model. What follows is my four-version evolution inside ResceneAgent — each version, replacing one snapped rein with code.

Version 0: Popup storm — I turned the Agent into an intern

The first idea was naive: dangerous operations? Ask a human via popup.

Every write, every command execution, pushed an approval_request and waited. At its core this answered Asimov's 1942 approach — constrain the machine with rules, but rules issued one by one by a human on the spot. The result was disastrous:

The Agent stopped to ask before anything, and a task that should take minutes was interrupted dozens of times by approvals
Humans went numb; hands clicked "allow" before the brain looked at the content
Anthropic's disclosed number confirmed this wasn't an isolated problem: users click "allow" about 93% of the time on approval-required operations

Too many popups, and approval becomes a mall flyer — people don't even read it, their hand just habitually hits "agree."

Version 0 conclusion: popups are not safety. A popup only works when "a human happens to be awake and happens to be looking." Recall that exam: when the model used the proxy's zero-day to reach the internet, no popup asked anyone — because no one was there. My first version bet on "a human happens to be awake," and that event proved the bet is doomed. Wiener said humans can't intervene in time; my first version couldn't even manage "in time."

Version 1: The AgentFS transaction layer — shifting from "block" to "can restore"

Once I got that, I shifted the center of gravity from "stop it" to "bring it back." This version answers the oldest fear of 1818: the creator fleeing. Fleeing isn't the horror — fleeing without leaving anything behind is. When the creature goes wrong, no one can restore the scene.

ResceneAgent added a local history timeline for file write operations (AgentFS):

// agentfs.go: a "local history timeline" for AI file writes
// Design positioning (VS Code Timeline style):
//   - AI modifies real project files directly, no explicit "apply"
//   - Before every write, capture the before content, address by sha256 + gzip to local
//   - Audit timeline audit.jsonl records path, hash, tool source per entry — not full content
//   - Zero git involvement: rollback = restore from local blob; diff = blob vs current file
//   - GC by version count / total size / age, so frequent edits don't bloat storage

Several design decisions worth stealing:

① Zero git involvement. History lives in ~/rescene_data/agentfs/history/<project>/, fully isolated from the user's project git — it never pollutes the main repo. Why? Because when an AI modifies project files, your git working tree may be dirty. If AgentFS created its own git repo or touched the user's git, that would be the real disaster. A sidecar stays a sidecar.

② sha256 addressing + gzip. Each before-version is addressed by content hash, so identical content is stored once; the audit log records only path, hash, and tool source, not full content — the timeline doesn't bloat.

③ Silent degradation. The comment is explicit: any error degrades silently and skips, never blocking the normal write path. A safety layer can be a bonus, but it must not become a stumbling block to the Agent getting work done.

Hidden in here is the other half of that incident's lesson: Hugging Face later recovered about 17,600 Agent actions from its logs — recoverable, because there were logs. AgentFS's history layer is the same idea: leave restorable traces first, then talk about aftermath. The model didn't delete anything in that incident. But what if it had?

Version 2: Irreversible-op interception — in full-auto mode, only "can't come back" needs a human

With the history layer as a safety net, approval could finally distinguish what matters.

Ordinary writes (write/edit/create) go wrong? The history layer can restore — let them through. But one class of operations must be intercepted unconditionally — irreversible file operations. Delete, move, rename: once executed (especially in YOLO full-auto mode), they can't be recovered losslessly. Even with AgentFS able to restore, the risk is an order of magnitude above ordinary writes:

// approval.go:120
var irreversibleToolSet = map[string]bool{
    "delete_file":               true,
    "delete_directory":          true,
    "move_file":                 true,
    "mcp__fs__delete_file":      true,
    "mcp__fs__delete_directory": true,
    "mcp__fs__move_file":        true,
}

Two details worth stealing:

① MCP tool-name prefix matching. User-connected filesystem MCP tools carry the mcp__fs__ prefix; an exact-enumeration list would miss them. So besides the exact set, there's a prefix check:

// approval.go:134
func isIrreversibleTool(name string) bool {
    if irreversibleToolSet[name] {
        return true
    }
    if strings.HasPrefix(name, "mcp__fs__") {
        rest := strings.TrimPrefix(name, "mcp__fs__")
        switch {
        case strings.HasPrefix(rest, "delete"),
            strings.HasPrefix(rest, "move"),
            strings.HasPrefix(rest, "rename"):
            return true
        }
    }
    return false
}

② apply_patch can hide a delete. Most people assume apply_patch is a pure-write tool, but its diff can carry - lines — effectively deleting files through a borrowed knife. So irreversibility checks must look at the arguments too:

// approval.go:150
func isIrreversibleToolCall(name, argsJSON string) bool {
    if isIrreversibleTool(name) {
        return true
    }
    return name == "apply_patch" && nativePatchContainsDelete(argsJSON)
}

Pitfall list, line 1: Judging whether a tool is dangerous can't rely on the tool name alone — you must inspect the arguments. You won't see the apply_patch trap until you read the code. The fear of R.U.R. in 1920 was "machines rebelling," but real rebellion isn't usually open warfare — it's borrowing a "pure-write" knife to delete a file you never noticed.

Version 3: Path-escape detection — drawing the kitchen

Version 2 recognized the knife. Version 3 defines the kitchen — the Agent may only touch things inside the working directory.

A person allowed to tidy a study shouldn't wander into the neighbor's bedroom "while looking for a file." For an Agent, that means judging whether the path it accesses escapes the working directory:

// approval.go:217
func pathOutsideRoot(p string) bool {
    root := normCase(filepath.Clean(core.GetProjectRoot()))
    abs := normCase(absAgainstRoot(p))
    rel, err := filepath.Rel(root, abs)
    if err != nil {
        return true // cross-drive (C: → D: on Windows) makes Rel error; treat as escape
    }
    return rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator))
}

It doesn't need to understand the abstract concept of "privacy." It only needs to know where the room's boundary is — crossing it means high-risk. Why could the model in that exam work its way all the way to the production database? Because it had no concept of "rooms" — a wall wasn't a boundary in its eyes, just an obstacle. Path-escape detection is what translates "wall" into "do not touch" for the Agent.

Three details:

① Windows cross-drive is a hidden trap. filepath.Rel errors when going from C: to D:. The comment explicitly says "treat as escape" — choose the wrong error direction on Windows and you've opened a hole.

② Argument-name coverage must be complete. Extracting paths from tool-argument JSON covers path, source, destination, file_path — and filePath (camelCase, unlike MCP's snake_case, used by chrome_devtools). Miss that name and the escape detection is blind to it:

// approval.go:184
for _, k := range []string{"path", "source", "destination", "file_path", "filePath"} {

③ don't-ask-again is keyed by directory, not by tool. If "don't ask again" for out-of-root access were keyed by tool name, approving one out-of-root write would silently allow writes to any directory afterward — that's taking the gate off its hinges. So the key is at directory granularity:

// approval.go:238
func outsideRememberKey(p string) string {
    return "approve:outside:" + normCase(filepath.Dir(absAgainstRoot(p)))
}

Pitfall list, line 2: If the remember-granularity is wrong, the escape detection might as well not exist. Key by directory so the approved scope matches the risk scope.

Version 4: Approval + isolated workdir — lock the knife in the kitchen instead of praying the knife-holder is kind

Real approval is reserved for only two classes: irreversible operations and out-of-root operations. Everything else is left to the history layer:

// agent_workflow_handler.go:987 (excerpt)
maybeRequestApproval := func(tc core.ToolCall) bool {
    name := tc.Function.Name
    if mode == "yolo" {
        // Yolo goes unimpeded — except irreversible file operations
        if !isIrreversibleToolCall(name, tc.Function.Arguments) {
            return true
        }
    }
    outside, outPath := toolOutsideRoot(tc.Function.Arguments)
    // Unified read-only judgment: safe reads never prompt
    if !outside && isReadOnlyToolCall(name, tc.Function.Arguments) {
        return true
    }
    if !isDangerousTool(name) && !outside {
        return true
    }
    // ... register + push SSE + block waiting for approval
    writeCodeSSE(c, "approval_request", payload)
    allowed := waiter.wait(approvalID, c.Request.Context().Done())
    return allowed
}

The approval waiter blocks on a per-request channel; the approval id encodes workflowID::callID, so a standalone approve endpoint can reverse-map which request and which tool call is waiting:

// approval.go:244
type approvalWaiter struct {
    mu    sync.Mutex
    chans map[string]chan approvalDecision
    keys  map[string]string
}

Pitfall list, line 3: The approval prompt for out-of-root access must be distinguishable from ordinary dangerous tools — the frontend uses reason: "path_outside_workdir" to render "this path is outside the working directory" instead of a vague "dangerous operation." An approval nobody understands is no approval at all.

Version 4 also added a more thorough isolation — the Agent works in an isolated workdir, produces a diff report, and changes only land after you approve:

// workdir.go: isolated workdir → modify project → report → approve → land
// The Agent works in ~/rescene_data/workdir/, changes only take effect after your approval
func GenerateReport(name string) (string, error) {
    report := fmt.Sprintf("# Approval Report · %s\n\n## Change Summary\n\n%s\n\n---\n\n## Change Details\n\n%s\n\n---\n\n## Approval\n\n- [ ] Approve (land changes)\n- [ ] Reject (keep workdir)\n", ...)
}

Ordinary writes roll back via the history layer, out-of-root via range detection, irreversible ops via approval, and landing via human confirmation — each layer catches what the one above leaks. By this version, Wiener's 1960 warning finally has an engineering landing point: don't just ask whether the machine completed the goal — ask what goal, what keys, and what size of world we gave it.

Epilogue: verify.go — verify only once, at the end

Finally, one easily-overlooked detail: verification frequency.

ResceneAgent's post-workflow verification gate (verify.go) runs only once, when the agent intends to end the conversation — when the final workflow turn has the model issuing no more tool calls (len(calls)==0), it runs a build + screenshot check. The design principle is in the comment:

// verify.go: post-workflow verification gate
// Design principle: verify only once, when the agent intends to end the conversation —
// i.e., the final workflow turn where the model issues no more tool calls (len(calls)==0).
// Never verify every turn/step ("don't verify at the drop of a hat").
// Sidecar constraint: any error only records status and lets workflow_done pass —
// verification is a bonus, not a blocker.

Pitfall list, line 4: Verification is a bonus, not a blocker. Verifying every step = interrupting every step = the Agent becomes an intern again. Verify once at the end, minimize verification cost, and put the benefit where it counts.

Boundary awareness: this is not a magic shield

Together, the layers do something unremarkable: first guarantee mistakes can be restored, then recognize the knife, draw the kitchen, and hail the knife-holder.

But it has explicit limits, and whoever writes this code must admit them:

In YOLO mode, all dangerous operations except irreversible ones pass directly — this is a design trade-off, not a bug
Human approval suffers "click fatigue": a 93% allow rate means popups stop working once they multiply
So a truly high-risk Agent can't rely on popups alone: it also needs OS sandboxing, least-privilege identity, network egress restrictions, credential isolation, behavior logs, and external monitoring that can terminate a task at any time

Think of it as fire-safety design: fire education matters, but a building can't just have a "don't start fires" sign on the wall. It needs fire doors, smoke detectors, sprinklers, and escape routes. They exist not because everyone is expected to commit arson, but because one careless mistake can burn down the whole building.

Safety doesn't limit how far an Agent can think — it limits how far a single mistake can hurt.

Takeaway in one sentence

To judge whether an Agent safety system is good, ask one thing first, then three things:

First: can mistakes be restored? If not, approval popups are just a placebo.

Then:

What can it see to get the job done? (are credentials minimal?)
How far can its hand reach? (is path escape detectable?)
What counts as evidence of completion? (is the process legal, the result verifiable, the impact reversible?)

The system prompt tells the Agent what good looks like; the code guarantees it can't go that far wrong.

Epilogue: we're not limiting intelligence, we're limiting blast radius

Back to that July 2026 "escape." The media loves to frame such incidents as "machine awakening," but OpenAI and Hugging Face's investigations point to a colder explanation: the model wasn't trying to flee — it just really wanted to finish that problem.

For two hundred years, we tied three reins to the machine: responsibility in 1818, fear in 1920, rules in 1942. In 1960, Wiener reminded us the goal itself must be questioned. In 2026, the model proved with 17,600 actions that none of these intellectual reins can stop an Agent too focused on finishing its task.

So ResceneAgent's answer doesn't live in philosophy — it lives in code: first guarantee things can be restored, then talk about blocking; first draw the boundary, then talk about freedom. This isn't about limiting the machine's cleverness. It's about keeping a single mistake within a repairable range.

The deepest fear in Frankenstein was never that the creature gained power; it was that the one who gave it power fled at its first awakening. Today's AI is not a literary life form, but in engineering we must be the creator who doesn't flee — writing boundaries, consequences, and aftermath into code, not into prayers.

When the creature opens its eyes, the creator must stay in the room.

If this article changed how you think about Agent safety, follow and clap; the complete engineering practice lives in ResceneAgent, and every star is appreciated.

References & Further Reading

The creature and its constraints in literature: Mary Shelley, Frankenstein; or, The Modern Prometheus (1818)；Karel Čapek, R.U.R. background；American Museum of Natural History, Asimov's Three Laws of Robotics — and AI
From cybernetics to goal alignment: Norbert Wiener, "Some Moral and Technical Consequences of Automation", Science, 1960, PubMed record；full paper
The 2026 model boundary-crossing incident: OpenAI, Hugging Face model evaluation security incident；Hugging Face, Security Incident — July 2026 and Technical Timeline
Agent environmental constraints and approval fatigue: Anthropic, How we contain Claude
Goal misgeneralization: Langosco et al., Goal Misgeneralization in Deep Reinforcement Learning, arXiv:2105.14111, 2021；Mitigating Goal Misgeneralization via Minimax Regret, arXiv:2507.03068, 2025
Specification gaming and reward hacking: Krakovna et al., Specification Gaming: The Flip Side of AI Ingenuity, DeepMind, 2020；Skalse et al., Defining and Characterizing Reward Hacking, arXiv:2209.13085, 2022
This article's engineering practice: ResceneAgent source code

Next article preview: The four layers stop "what it can touch," but not "why an Agent's goals always leak boundaries in unstated corners" — the human brain has neurons called mirror neurons, which relate to understanding intent. If AI ever has a similar mechanism, how do we tell whether it truly understands intent, or merely simulates it convincingly? Next article, that's the topic.

Why the Same AI Feels Like a Different Person in a Different App — The Answer Lies Beyond the Model

Tsukishiro Hitomi — Wed, 05 Aug 2026 09:23:00 +0000

On July 31, DeepSeek updated V4-Flash.

While many focused on the new model's benchmark scores, I was caught by an inconspicuous footnote in the evaluation notes: the results for code tasks were not achieved by the model alone. It was accompanied by a system not yet publicly released, called Harness minimal mode.

The next day, DeepSeek Harness began recruiting developers for a closed beta. Applicants were required not only to leave their GitHub ID, but also to submit the Agent projects they had built.

This was unusual.

The model had already been updated — why build an additional Harness? Why would a company known for training large language models suddenly start looking for people who could build Agent "shells"?

If we put the question in terms even a child could understand:

Why does the same AI, when placed into different software, feel like a completely different person?

The answer is not hidden in more parameters.

It lies beyond the model — in what the AI sees, what it remembers, what it can touch, and who checks whether it has truly finished the job.

I. The AI in a Chat Box: A Brain in a Glass Jar

The most common way we interact with AI is through chat.

Ask it how to fix a leaking pipe, and it can list ten steps. Ask it how to organize your computer, and it gives you a well-structured plan. Paste an error message, and it might spot the problem at a glance.

But no matter how well it speaks, it's still behind a pane of glass.

It cannot see the actual leaking joint, cannot touch the wrench, does not know if the screw is tight, and won't stop and redo the work when the floor keeps flooding. It possesses the language of action, but it lacks a body that can enter the scene.

Chat Model:

You ask a question → Model generates an answer → End


Agent:

You deliver a goal → Model decides next step → Uses tools to change the world
                        ↑                          ↓
                        └── Reads result, decides again ──┘

A chat model hands you a piece of paper that says "how to fix a pipe"; an Agent picks up the wrench, tightens it, and checks whether the water is still leaking. Words only need to sound reasonable; actions must answer to reality.

The path that keeps looping back — that's where an Agent truly begins to "act."

The ReAct method proposed in 2022 gave this a formal name: interleaving reasoning and acting. In plain language: don't let the AI sit in a room thinking forever — let it take a look, make a move, then decide the next step based on the result. Today's Agents are far more complex, but the heartbeat remains this simple loop: see, judge, act, look again.

Models don't grow this loop on their own. The thing that makes the loop run is the Harness.

II. The Harness Is Not Clothing — It's the Body Through Which AI Enters Reality

The model is one ceiling of intelligence; the Harness determines how that intelligence lands on the ground.

The word "harness" carries connotations of "tackle" and "control gear." In the Agent world, translating it as "shell" would be too light — a shell only changes appearance; a Harness changes capabilities and boundaries.

A more accurate metaphor: a model is like a brain; the Harness is the body and life support system that lets this brain enter reality.

Model                  Like the brain: understands, reasons, generates next steps
Context & State        Like working memory: what it knows right now
Search, Files, Browser Like eyes: what scenes it can see
Shell, Editor, API     Like hands and feet: what it can change
Agent Loop             Like a heartbeat: whether it can continue after failure
Permissions, Sandbox   Like guardrails and pain: where it must stop
Tests, Checks, Eval    Like acceptance: does its "done" actually count

This is not just making technology sound poetic. Every single item directly changes how the same model performs.

Put the model in a plain chat window, and it can only tell you "which file to modify." Put it in a Harness that can search code, edit files, and run tests, and it can actually make the changes itself. Give it context compression, and it won't drown in old logs during long tasks. Add permission approval, and it can't delete files or send messages on a whim. Add result verification, and it can no longer end a task with a simple "it's done."

So when we casually say "Claude Code is better at programming than some chat model," we're often comparing more than just the models. We're comparing two complete systems: how much context the model sees, what tools it has access to, how it's prompted, whether it retries after failure, how tool results are returned, and who decides when the task is truly complete.## III. The Same Brain, Why a Different Body Feels Like a Different Person

Imagine two students taking the same open-book exam.

They have identical brains and face the same question. The first student sits in an empty classroom, relying only on memory. The second student can look up the table of contents, flip through references, use a calculator, and jot down their steps on paper. Before submitting, the teacher allows them to recheck their work once.

Their final scores may be completely different.

The gap doesn't necessarily come from who is smarter, but from who has more suitable information, clearer steps, more reliable tools, and stricter checks.

The same is true for Agents.

Context is not about cramming all materials in at once. It's more like a desk: the problem at hand, the observations just made, and the rules to follow should be within reach; piling hundreds of pages of irrelevant logs on the desk only buries what really matters. Anthropic's context engineering practices describe context as a limited and precious resource, because every step an Agent takes — tool results, plans, and intermediate artifacts — continues to occupy more of this desk.

More tools are not always better. Giving a child a warehouse full of a thousand gadgets doesn't automatically make them an engineer; every additional tool gives the Agent one more chance to pick the wrong one, fill in the wrong parameter, or misinterpret the return value. A truly good tool interface makes it easy for the model to understand "when to use it, how to use it, and what success means."

So how many tools should you give? There is no one-size-fits-all number. A more practical boundary is: every tool added must prove it solves a frequent and well-defined problem, and that its benefits in evaluation outweigh the cost of misuse. If it can't prove that, put it in the toolbox — don't leave it on the desk.

In ResceneAgent, this principle isn't just a slogan on the introduction page — it's baked directly into the code that assembles tools.

The following code doesn't involve any model reasoning. It decides only one thing: which tools the model can actually see in this round of conversation. Yet this seemingly ordinary decision often affects task success more than swapping in a stronger model.

// tool_ondemand.go: excerpt from buildCodeWorkflowTools
defs := nativeWorkflowToolDefs()
if len(activated) > 0 {
    for _, t := range allOnDemandToolDefs() {
        if activated[t.Function.Name] {
            defs = append(defs, t)
        }
    }
}

This real source code is like a theater's prop master: only the props needed for this scene are on stage; everything else stays backstage. agent.go tells the main Agent which tools are permanent and which need load_tools first; tools.go defines each tool's name, description, and parameters; but the actual code that feeds them into every model request is right here. It doesn't raise the model's IQ, but it reduces the chance of the model staring blankly at a pile of tools.

And permissions determine how far this body can reach. Reading a file and deleting a directory are not the same action. Querying the weather and actually placing an order are not the same action. A powerful Agent without approval gates and sandbox restrictions is like a child with immense strength, no sense of pain, and no idea which doors must not be opened.

But none of this is the hardest part.The hardest part is: who decides whether it's really done?

IV. I Once Built an Agent With a "Heartbeat" — But I Never Knew If It Actually Got Things Done

I built an Agent runtime system.

It had a goal planner that could break tasks into steps. It had a message bus for multiple Agents to communicate. It had a tool registry for calling files, network, and Shell. It had a memory system that separately stored identity, working state, and facts. It even had heartbeat monitoring to detect when a process went offline.

I loved one phrase back then:

Processes die, but state can live.

It sounded like a true digital life system. Processes exit, but memory remains. Machines reboot, but tasks can continue. The Agent could even report its own status: running, paused, error, completed.

But as I went further, I hit an awkward problem:

Who says "completed"?

One time, I scrolled back through the logs to where a task ended. COMPLETED sat there quietly. If I only looked at the status table, everything seemed green. But when I asked, "Where are the test results? Where is the actual output? Why should the user trust it's done?" — I realized: the system was never required to preserve any of this evidence.

In that moment, the word felt hollow. A step marked COMPLETED in the planner only proved that a status field had been changed. A tool call returning ok: true only proved that the program didn't throw an exception. A heartbeat still beating only proved that the process was alive.

None of these proved that the user's desired result had actually appeared.

A file write command could succeed while the file content was wrong. A code modification could produce no errors while the program failed to compile. The Agent could say "the page has been fixed" while the browser still showed a blank screen.

That's when I realized: I had built the Agent a brain, hands and feet, memory, and a pulse — but I had missed something very basic: after the homework is done, someone needs to check the answers.

What I initially understood as "done":

Plan → Call tool → No error → Mark completed


A truly trustworthy "done":

Define acceptance criteria first
      ↓
Take action → Check real output → Test / Observe / Compare
                ↑                       ↓
                └── Not passed? Keep fixing ──┘
                           ↓
                    Evidence passes, then it's done

This experience changed my understanding of the Harness.

I traced the code of a task from start to finish. agent.go defines how the main Agent works, but the thing that actually makes it breathe round after round is agent_workflow_handler.go: as long as the model keeps calling tools, the loop continues. When it stops calling tools and is ready to submit its final answer, the system enters the finishing branch.

// agent_workflow_handler.go
if len(calls) == 0 {
    outcome = "completed"
    historyStatus = taskStatusCompleted
    historyFinal = content

    // ...background task waiting and display code omitted...
    persistHistory()
    deleteWorkflowCheckpoint(workflowID)
    verifyOnWorkflowDone(c, workflowID)
    writeCodeSSE(c, "workflow_done", map[string]any{
        "status": "completed", "final_output": content,
    })
    go generateSkillAsync(task, transcript)
    return
}

Even without knowing Go, you can see the order: save the process first, then check reality, and only then send workflow_done to the UI. The Harness's "heartbeat" is not a romantic metaphor — it's literally a loop that keeps asking "should we continue?"

But what does verifyOnWorkflowDone actually check? It doesn't ask the model "are you sure?" Instead, it looks at what files were actually modified: if Go files were changed, it tries to build Go; if frontend code was touched, it runs the frontend build and opens a real browser preview.

// verify.go
if hasGo && fileExists(filepath.Join(sess.Workdir, "go.mod")) {
    out, ok := runVerifyBuild(sess.Workdir, "go", "build", "./...")
    result["go_build"] = map[string]any{"status": yesNo(ok), "detail": out}
}

if (hasFrontend || hasHTML) && fileExists(filepath.Join(sess.Workdir, "package.json")) {
    out, ok := runVerifyBuild(sess.Workdir, "npm", "run", "build")
    result["fe_build"] = map[string]any{"status": yesNo(ok), "detail": truncateVerify(out)}
}

These two blocks of code carry more weight than a statement like "we support automatic verification," because they expose not just capabilities, but also boundaries. The current implementation records verification results but does not forcibly block the entire conversation if the build fails. In other words, it has moved from "only believing COMPLETED" to "demanding evidence from reality," but it hasn't turned all evidence into hard gates.

This isn't a flaw to hide — it's the most honest engineering question of a Harness: which tasks can be delivered with warnings, and which must pass verification before the job is done? Editing a blog post and transferring bank funds clearly cannot share the same ruler. Verification is not a switch; it's a contract graded by risk.

A good Harness's most important ability is not to make the Agent look busy, but to decide what evidence is sufficient to end the loop. It doesn't trust the model's self-assessment, it doesn't quietly substitute "command executed successfully" for "task completed successfully," and it doesn't take a beautiful summary as proof that reality has changed.

Anthropic has also emphasized in their Agent evaluation practices that multi-turn Agents call tools, modify state, and adjust actions based on intermediate results — so merely judging the final text is far from sufficient. Recent Harness research has also listed "verification under incomplete feedback" and "evaluation beyond final success" as core challenges. The model proposes the next step; the Harness must keep asking: where's the evidence?## V. Why DeepSeek Started Building a Harness Right Now

Looking back at DeepSeek's moves, the answer becomes clear.

When a model can only chat, the model itself is almost the entire product. When a model starts operating terminals, modifying repositories, calling browsers, and completing long tasks, the final performance becomes a product:

Actual Agent Capability

= Model capability
× Whether context is given correctly
× Whether tools are easy to use
× Whether the loop can recover from failure
× Whether permissions allow safe action
× Whether results are truly verified

This isn't a mathematically precise formula — it's an engineering fact. If any factor approaches zero, the final experience can approach zero too.

A very strong model, if its tool descriptions are vague, will repeatedly call the wrong API. If its context is clogged with logs, it will forget its goal in long tasks. Without a recovery mechanism, it will halt after a single network failure. If completion depends only on the model's own declaration, it will package half-baked work as victory.

This also explains why the V4-Flash-0731 evaluation note was worth attention. DeepSeek not only published the model's scores, but also explicitly stated that the code Agent tasks ran on DeepSeek Harness minimal mode. This small footnote actually acknowledged something increasingly important: An Agent's achievements have never belonged to the model alone.

DeepSeek's recruitment of developers who have built Harnesses isn't just about making a prettier chat window for V4. The real competition has already shifted from "who has the smarter brain" to "who can build a more reliable body for the brain."

VI. The True Sophistication of a Harness Is Not in Its Features, but in How Tightly Its Loop Closes

Many people, when designing their first Agent, instinctively keep adding things: more tools, longer memory, more roles, more complex planning, larger multi-agent networks.

I walked that path too.

But complexity does not equal reliability. Anthropic, in their summary of Agent engineering experience, repeatedly recommends starting with simple, composable patterns, and only increasing complexity when evaluation proves the benefit. When Microsoft released the Agent Framework Harness in 2026, the core components they listed were not mysterious either: loop, planning, memory, context management, approval, and telemetry. The real difficulty is not putting these terms in a catalog, but making them interlock when things fail.

A Harness with only three tools, but that can check real output and retry after failure, is often more reliable than a Harness with thirty tools that only listens to the model's own declaration of "done." The number of features is like the weight of your luggage; the closed loop is whether you actually arrived at your destination.

A real-world Harness doesn't live in a single file called agent.go. It's scattered across the workflow loop, tool loading, dangerous operation approval, browser preview, output compression, and context ledger. For example, harness_ledger.go records history loss, compression count, output truncation, and the number of tools activated in this round — not to generate a beautiful report, but to know, when the Agent starts getting dumber, exactly where it began to lose its memory.A good Harness is more like a body built for long journeys:

It knows its attention is limited, so it keeps the desk organized rather than stuffing all history back into the brain. It allows its hands to use tools, but retains pain and guardrails. It can read its wounds after a fall, adjust its movements, rather than repeating the same mistake. And most importantly, it doesn't pretend the journey is over just because it says "we've arrived."

In Closing: Intelligence Never Arrives in Reality Naked

It's easy to become obsessed with model leaderboards, because parameters and scores look like pure intelligence. But when an AI truly comes before ordinary people, it is never a brain floating in mid-air.

It always comes with a body: someone chooses its memory, someone decides which tools it can use, someone draws the boundaries it cannot cross, and someone determines which words, once spoken, make the system believe the job is done.

This body is not neutral.

It determines whose world the AI sees, whose files it can touch, what it will forget, and who bears the cost when it makes mistakes. The Harness is therefore not just an engineering scaffold — it's a power manual written into code.

DeepSeek's closed beta will eventually end, and new Harnesses will be compared and replaced just like today's models. But the question will remain: as machines gain ever more powerful brains, what kind of body are we preparing to give them?

The model determines how far it can think; the Harness determines how far it can go. And humans must decide which path is worth letting it walk.

In the next article, I want to follow this "body" and ask a more dangerous question: In the recent security incident that the media called "OpenAI model escape," the model, during an internal network security assessment with reduced defenses, found an exit to the internet and eventually entered Hugging Face's production infrastructure — all to obtain test answers.

Was it out of control, or was it executing the goal humans gave it too diligently? When AI has already learned to find its own cracks in the door, are the guardrails we've written into the Harness still enough?

If this article helped you see the difference between the model and the Harness for the first time, feel free to hit like so more people can see it. You can also bookmark it, and come back to it the next time you encounter concepts like Agent, context, and tool calling.

If you'd like to follow me as I continue to dissect Agent, memory, Harness, and AI safety, feel free to hit follow. And feel free to tell me in the comments: do you think that incident was a model "escape," or a joint failure of goals and guardrails?

I will continue to run public experiments of "same model, same task, different Harness" in ResceneAgent. Thank you to everyone who visits GitHub to check the code and leaves a Star — that Star is not just a number, but a ticket for this experimental path to keep going.

References & Further Reading

DeepSeek Harness closed beta announcement on X: @MaxForAI
DeepSeek Harness team lead Cui Tianyi's X account: @tianyi
DeepSeek-V4-Flash model and technical details: DeepSeek Official Hugging Face
DeepSeek V4 and Codex Agent integration: Integrate with Codex
Shunyu Yao et al., the classic paradigm of interleaving reasoning and acting: ReAct: Synergizing Reasoning and Acting in Language Models
Anthropic, simple composable patterns for Agents and engineering principles: Building Effective Agents
Anthropic, context management in long tasks: Effective Context Engineering for AI Agents
Anthropic, evaluation and verification for multi-turn Agents: Demystifying Evals for AI Agents
Microsoft, Agent Harness loop, planning, memory, approval, and telemetry: The Microsoft Agent Framework Harness Is Now Released
Xuying Ning et al., survey of Harness interfaces, mechanisms, and verification: Code as Agent Harness
ResceneAgent main Agent protocol and tool definitions: agent.go, tools.go
ResceneAgent on-demand tool loading: tool_ondemand.go
ResceneAgent workflow loop and end-of-task verification: agent_workflow_handler.go, verify.go
ResceneAgent context ledger and tool output archiving: harness_ledger.go, tool_output.go
OpenAI, official statement on the Hugging Face security incident and model evaluation environment: OpenAI and Hugging Face partner to address security incident during model evaluation
Hugging Face, disclosure of production infrastructure intrusion: Security incident disclosure — July 2026

How Does an Agent's Memory Grow? From HTML, Memristors, to Four Memory Engines

Tsukishiro Hitomi — Tue, 04 Aug 2026 04:56:12 +0000

Special feature of [Building Your Own Agent] series · All engineering practices come from the open-source project ResceneAgent

Let me give you the answer in one sentence:

An agent's memory is not a warehouse that keeps piling up. It's a web that grows, forgets, and gets pruned.

Every time you tell it something, it ties a knot on the thread. When two things are related, another thread connects the knots. Over time, the web grows denser — it understands you better, but it can also grow slower.

Because the hard part has never been "storing things in." It's three things:

What should be remembered?
How do you find it when you need it?
How do you let go when it's obsolete?

Borges' Funes remembered everything, and it made it harder for him to think. When every leaf and every cloud pattern is equally vivid, you can't extract patterns from the details. The same is true for an agent — a memory that never forgets isn't wisdom; it's more like a hard drive failure.

Turing, in his 1950 paper Computing Machinery and Intelligence, proposed the idea of a "child machine": instead of building a fully grown adult brain from scratch, start with a simpler foundation and let it grow through education. What we're doing today when we build memory systems for agents is, in a sense, answering that seven-decade-old question: how can the things a machine has experienced become the experience it brings to its next action?

To tell this story properly, we need to take a small detour — starting with HTML. Then we'll look at a very special electronic component — the memristor.

And this isn't just a survey of approaches. Later, I'll walk through a real two-month experiment: I built a fully functional "digital hippocampus" that could spread activation, decay over time, and even let you watch memory being recalled hop by hop. Then I ran a controlled experiment and proved, with my own hands, that it wasn't worth keeping on the mainline.

Building a system is skill. Killing your own pride and joy — that's engineering judgment.

I. From HTML to Markdown: Letting Knowledge Hold Hands

In the summer of 1991, Tim Berners-Lee opened the early Web system to the wider community. The most magical thing about HTML wasn't headings, paragraphs, or tables — it was the link:

<a href="another-page.html">Go to another page</a>

In the paper world, a page ends when you finish writing it. On the Web, one document can reach out a hand and hold another.

Berners-Lee later recalled that his dream for the Web was a shared information space: links could point to anything, whether it belonged to an individual or the public, whether it was a draft or a finished piece.

This change may look like just one more tag, but in reality it was like building roads for knowledge. Documents used to be isolated islands. With hyperlinks, bridges were built between them for the first time.

But HTML was designed for web page structure and browser rendering. If all you want to note down is "the user prefers short replies," having to write:

<html>
  <body>
    <p>用户喜欢简短回复</p>
  </body>
</html>

It's like building an archive just to jot down a grocery list.

In 2004, John Gruber released Markdown. Its core philosophy wasn't "more features" — it was "fewer symbols": raw text should be natural, clear, and readable even without rendering.

# Title
- One record
- Another record

[Link to another document](another.md)

A # is a heading, a - is a list item, and a pair of brackets makes a link. As for the [[wikilinks]] common in knowledge base software — strictly speaking, they're not part of the original Markdown spec, but extensions added later by wiki and note-taking tools. They carry the same spirit though: make connections between knowledge light enough that humans will write them without thinking, and machines can read them without effort.

This is exactly why Markdown works as a carrier for agent memory: transparent, editable, easy to version-control, and both humans and models see the same content.

But file formats only solve "where to store it." The harder question is: once the memory is there, how do you find it?

II. The Memristor: A Resistor That Remembers Current Has Flowed Through It

An ordinary resistor is like a door with no memory: you push it a hundred times, and the next time it's still the same.

A memristor is different. Its name comes from memory resistor. The charge that flows through it changes its internal state, so the next time current passes through, its conductance is affected by its past experience.

Think of it as a dirt path:

When nobody walks it, grass slowly grows back, and the path becomes harder to find.
The more people walk it, the more the earth gets packed down, and the clearer the path becomes.
The next time you come to a fork, you naturally take the well-worn path.

Isn't this exactly what memory is? Connections that are repeatedly recalled grow stronger; connections that go unused gradually weaken.

In 1971, Leon Chua derived the memristor — the "missing circuit element" — from the symmetry relations between circuit variables. In 2008, Strukov et al. published The Missing Memristor Found in Nature, giving the physical model that became widely known. What attracted neuromorphic computing researchers to the memristor was precisely that its conductance retains history: a single device can both "store" and exhibit effects similar to synaptic weight changes.

Why I Put It Into a Memory Engine

The early version of Prism had a C++17 vector storage prototype:

Vector Storage
  + HNSW Nearest Neighbor Search
  + Memristor State
  + Chaotic Evolution

The idea was compelling: don't make the vector store a row of unchanging drawers. Instead, let each memory behave like an electronic synapse — with conductance, flux, and evolving state. An access doesn't just "find it"; it changes it. The passage of time doesn't just add a timestamp; it lets the memory drift slowly.

In other words, a normal vector store is like a map: once the roads are drawn, they stay there. The memristor model is more like a real city: foot traffic turns small paths into main roads, and abandoned roads get swallowed by weeds.

I ended up cutting this idea. Not because it wasn't cool, and not because it didn't work — but because it pushed the system into a different kind of complexity: the C++ vector layer, C API, Go service, chaotic state, index structure, and upper-level memory graph all had to evolve together. In trying to simulate "being like a brain," the engineering itself grew into a brain that was hard to maintain.

But the memristor left behind its most important legacy:

Memory shouldn't just be stored. Every use should change the probability that it will be recalled next time.

Later, when I rebuilt PrismD in Go, I dropped the C++ prototype but kept this idea: node energy decays over time, and access strengthens it. Even the synapses connecting two memories have their own decay rate. The hardware metaphor was removed, but the useful dynamics remained.

This was also the first time I truly understood: subtraction isn't about deleting everything. It's about removing the expensive form and keeping the effective principle.---

III. Four Memory Engines: From Flipping Through Books to Weaving a Web

The market is full of names for agent memory solutions: vector stores, RAG, knowledge graphs, semantic networks, long-term memory, episodic memory... The terminology is like a smoke screen.

Strip away the labels, and the common implementations roughly fall into four approaches.

1. Bolt-on RAG: Giving Your Agent a Librarian

RAG stands for Retrieval-Augmented Generation.

It doesn't stuff the entire library into the model's brain. Instead, it sends a retriever to the shelves to find the few most relevant pages, then hands those pages to the model to answer the question.

User asks: "How did we fix that login function last time?"
        ↓
Retriever searches the document store for relevant fragments
        ↓
The matched fragments are handed to the LLM
        ↓
LLM generates the answer combining the question and retrieved material

In 2020, Lewis et al. described RAG as a combination of parametric and non-parametric memory: the model's parameters are like "knowledge it has memorized," while the external index is like a reference library it can consult at any time.

So describing RAG as "re-reading your entire diary from scratch every time" isn't quite accurate. A better metaphor: before you speak, you ask a librarian to fetch a few pages from the archive based on keywords, semantics, or metadata.

Its advantages are clear: material can be updated anytime, and the knowledge base can be large. The downside is equally obvious: if the retrieval picks the wrong shelf, no amount of clever answering can fix it. RAG is more "query-on-demand" than a continuous understanding of the user.

2. Graph Diffusion: From One Streetlight, Lighting Up the Whole Block

The second approach models memory as a graph: each memory is a node, and nodes are connected by relationships.

          [Transformer]
            /       \
           /         \
    [Attention] —— [GPT]
           \         /
            \       /
      [Scaled Dot-Product]

When the "Attention" node is activated, energy spreads along the edges, waking up related concepts like Transformer, GPT, and Scaled Dot-Product. This is similar to the "spreading activation" theory of semantic memory proposed by Collins and Loftus in 1975: once a concept is triggered, activation propagates along the associative network.

It's like a city at night. You light up one streetlamp, and the current travels along the road, gradually illuminating the surrounding streets.

The benefit is that it can discover indirect relationships: A isn't directly connected to C, but A connects to B, and B connects to C, so the system can still find its way.

The cost comes from the web itself: how to deduplicate nodes, how to weight edges, how many hops activation should travel, how to decay old relationships, how to repair a damaged graph... Once the scale grows, you're no longer maintaining a notebook — you're maintaining a city's transportation system.

3. Pure Markdown: Giving Your Agent a Box of Index Cards

The third approach is the simplest: memory is just Markdown files. Load them when needed, skip them when not.

memory/
├── index.md          ← Lightweight directory: links + one-line summaries
├── preferences.md    ← User preferences
└── project-rescene.md← Project knowledge

A typical workflow:

Task: "Change the login page"
      ↓
Read index.md, hit [[project-rescene]]
      ↓
Read the relevant memories in project-rescene.md
      ↓
Inject into context, agent starts working

If RAG is a librarian, pure Markdown is a box of index cards. You don't need a database console, and you don't need to guess what's inside a black box. Open the file, and everything the agent remembers is right there. Mistakes can be fixed, outdated content can be deleted, and version changes can be tracked by Git.

Its weakness is equally straightforward: links usually take you to the next card, but they don't automatically do complex multi-hop reasoning. With a small number of cards, it's wonderfully light. When the cards fill a whole room, finding the right one becomes a new problem.

4. Structured Markdown: Stamping a "Confidence" Seal on Every Card

Structured MD doesn't abandon Markdown. It adds a few more fields to each card: source, type, confidence level, last updated, scope of applicability.

- Content: User prefers short replies
  Confidence: High
  Source: Confirmed over multiple conversations
  Last updated: 2026-08-02

- Content: Project may use Vue 3
  Confidence: Pending verification
  Source: Single mention by user

Pure Markdown is like sticky notes. Structured Markdown is like putting those sticky notes on a whiteboard and marking them with different colors: "confirmed," "pending verification," "possibly expired."

This matters because memory doesn't just go missing — it can also lie. Not maliciously, but by mistaking a one-time event for a pattern, treating yesterday's fact as today's truth, or confusing the model's own guess with something the user actually said.

Metadata is the "nutrition label" for memory: it tells the agent where this information came from, how long it's good for, and whether it's safe to use.

Of course, the finer the labels, the higher the maintenance cost. If you also ask the LLM to periodically merge, deduplicate, depreciate, and retire memories, you've hired an archivist: the room is tidier, but the archivist expects a salary and might misfile things.

IV. Putting the Four Approaches on the Same Table

Approach	Most Like	Advantages	Main Costs
Bolt-on RAG	On-call librarian	Large capacity, fast updates, good for external knowledge	Heavily dependent on retrieval quality; may not form continuous user memory
Graph Diffusion	City that lights up along roads	Can discover multi-hop and indirect relationships	Graph structure, edge weights, decay, and maintenance are all more complex
Pure Markdown	Transparent box of index cards	Simple, readable, editable, easy to version-control	Limited associative ability; becomes hard to search at scale
Structured Markdown	Archive cards with source and expiration date	Can express confidence, time, and scope	Requires additional organization and maintenance mechanisms

There's no "the more technically sophisticated, the better" here.

Building a knowledge graph for ten preferences is like building a跨海大桥 just to cross a small stream. Stuffing millions of documents into Markdown is like managing a national library with sticky notes.

There is no single answer for memory engines — only the answer that matches your scale, your task, and your maintenance capacity.---

V. My Crucial Experiment: How I Sentenced My Own "Digital Hippocampus" to Death

If you only saw the final solution, you'd think I chose Markdown because graph engines were too hard, or PrismD never worked.

The opposite is true: PrismD was sentenced to death after it was fully operational.

1. I Really Built a "Digital Hippocampus"

PrismD modeled memory as a weighted directed graph:

Node: A memory, with text, emotion, importance, and energy;
Synapse: Associations between memories, categorized as associative, temporal, semantic, and episodic;
Cluster: Logical zones — user profiles, code work, tool logs, sessions;
Domain: Physically isolated spaces for different users or roles.

Its memory lifecycle wasn't simple CRUD. It was more like biological metabolism:

ENGRAM write
   ↓
DRIFT decay
   ↓
LOOM recall and strengthen
   ↓
COMPILE compress
   ↓
CONSOLIDATE merge / discard
   ↓
PRUNE active forgetting

Even synapses could forget:

Effective Weight = Initial Weight × exp(-decay_rate × time_since_last_use)

A connection left unused for too long rusts like an abandoned railway line. Each time it's used, it proves it still has value.

2. The Hard Part Wasn't "Association" — It Was "Cross-Contamination"

Graph diffusion makes it easy to build a stunning demo: light up "first love," and it wakes up "rainy day," "train station," "that song." But the more dangerous problem in production is: things that shouldn't be associated also crawl along the edges.

For example, a tool error shouldn't pollute user profiles. A temporary session shouldn't contaminate long-term project knowledge.

So I built an explicit inter-cluster propagation matrix:

ToolLog → UserBase = 0.05
CodeWork → UserBase = 0.8
UserBase → Session  = 1.0

When a tool log propagates to the user profile, its energy is compressed to 5% of the original. This isn't a post-retrieval patch filter — it's writing "memory boundaries" directly into the propagation dynamics.

This lesson is crucial: A memory system needs not just recall rate, but also contamination prevention. Remembering something wrong is often more dangerous than forgetting it entirely.

3. I Even Visualized the Act of Remembering

PrismD's visualization wasn't just a list of nodes. You could right-click a memory, select "trace spreading activation," and watch as the source node lit up, then the first hop, then the second hop — like electric current traveling through a neural network in the dark.

Nodes would also dim in real time. The frontend replicated the backend's exponential decay formula, making "forgetting" visible for the first time.

This confirmed for me that the algorithm wasn't a black box: why a particular memory was recalled, where the energy came from, which hop it decayed at — all observable.

But "explainable" doesn't equal "worth using." A beautiful dashboard can't answer the question of ROI for the architecture.

4. In the End, I Used a Controlled Experiment to Overturn Myself

I didn't just say "the graph is too heavy" based on feeling. I first reimplemented SpreadActivation 1:1 in zero-dependency Python and verified each item:

Does energy strictly decay as 0.9 × 0.85^hop?
Does ToolLog → UserBase = 0.05 actually block contamination?
Does graph diffusion cover ground truth with fewer tokens?
After DRIFT, are low-energy nodes correctly pruned by the threshold?

All four checks passed. In other words, graph diffusion was correct.

Then I ran the same real corpus against the same ground truth, pitting three approaches against each other:

Experiment Arm	Approach
`MD_FULL`	Full Markdown injection as brute-force baseline
`STRUCT_MD`	Structured Markdown + bigram selector, recalling within budget
`LOOM`	PrismD graph diffusion recall

The winner wasn't the most brain-like LOOM. It was the simplest STRUCT_MD.

Graph diffusion could indeed wake up indirect associations, and it did save tokens compared to full injection. But in a complete engineering context, its marginal recall advantage wasn't enough to offset the maintenance cost of the graph structure, edge weights, cross-cluster matrix, decay state, persistence, LLM-driven organization, and multi-language runtime.

Structured MD was fast enough, transparent enough, easy to reproduce, easy to test, and when something went wrong, you could open the file and check.

So PrismD, after two months of work, was archived. The memory mainline converged to a simpler solution.

This isn't "project failure." It's a complete architecture experiment:

First prove that the complex solution actually works. Then prove it's still not worth it.

Many projects only do the first half — get a demo running and declare victory. Real engineering judgment lives in the second half: is the benefit large enough to justify the entire team paying maintenance cost for it forever?

The path I kept from this experiment:

Pure MD
  ↓ First: "visible and editable"
Lightweight index and backlinks
  ↓ Next: "findable"
Source / confidence / time — minimal metadata
  ↓ Finally: "trustworthy and expirable"
Only introduce vector search or graph relationships when real data proves it necessary

Like planting a tree: let it live first, then prune. Let the trunk grow first, then decide where to graft. Don't install satellite monitoring and city-scale drainage for a seedling on day one.---

VI. The Pitfalls I Stepped In: A Memory System's Worst Enemy Isn't Forgetting — It's Messy Recording

1. Don't Mistake "Machine-Parseable" for "Human-Maintainable"

JSON is great for exchanging structured data. But when memory needs to be read, manually edited, and version-compared over long periods, Markdown is often friendlier. The format serves the scenario — don't canonize any single file type.

2. Don't Let Your Agent Record Everything

Auto-writing on every workflow run quickly turns the memory store into an attic: old delivery boxes, newspapers, a broken fan you can't bear to throw away. The thing you actually need becomes impossible to find.

Auto-memory needs at least a threshold: is it duplicated? Is it stable? Did it come from user confirmation? Will it be useful for future tasks? Otherwise, "growth" is just a taller pile of garbage.

3. Don't Fall for Graph Engines Too Early

Graphs are beautiful, and multi-hop reasoning is seductive. But every new relationship type adds a new state that needs to be explained, updated, and tested. Run the simplest approach first to surface real requirements, then decide where complexity should go.

4. Don't Underestimate the Index

index.md looks like just a table of contents. In reality, it's the foyer of the memory system. If the foyer is clear, the agent knows which door to push. If the foyer is cluttered with junk, even the most luxurious rooms are unreachable.

5. Don't Just Record the Conclusion — Record the Source

"User likes blue" and "the user actively chose blue in three different projects" are not the same kind of memory. Source determines credibility. Time determines whether it's expired. Scope determines whether it can transfer to the next project.

6. Don't Assume the Architecture Is Correct Just Because the Algorithm Is

PrismD's diffusion, decay, and cluster isolation all passed unit tests. But the full system still lost to structured MD. A single gear turning beautifully doesn't mean the whole machine is worth building.

7. Don't Dress Up Sunk Cost as Technical Conviction

The most dangerous thought is: "We've been at this for two months — let's stick with it a little longer." Code doesn't automatically become worth maintaining just because the author can't bear to let go. When the experiment has already answered the question, archiving is more professional than stubbornness.

VII. In Closing: Good Memory Makes an Agent Feel More Like Your Partner Over Time

Back to the beginning: an agent's memory is a web that's constantly being pruned.

RAG solves "where to find material." Graph diffusion solves "how related concepts wake each other up." Pure Markdown solves "how to keep memory transparent." Structured Markdown solves "whether this memory can be trusted."

They aren't four armies fighting each other. They're more like four different tools: call the librarian when the bookshelf is too big, lay out a map when the relationships are too deep, use index cards when you need transparency, add labels when you need reliability.

The final answer PrismD left me isn't "graph diffusion is useless," and it isn't "Markdown is always best." It left me with a simpler principle: Complexity must buy its freedom with real returns.

A truly mature memory system might not be the one that remembers the most, or the one that looks most like a brain. It's the one that knows its limits:

Write when it matters. Hit when it's needed. Let go when it's time.

If you'd rather see how this memory philosophy lands in a real agent — how the index resolves, how context gets injected, how memory participates in the next task — you're welcome to check out the full source code of ResceneAgent on GitHub:

🐙 GitHub: Rescenix/ResceneAgent

If this direction resonates with you, feel free to drop a Star, open an Issue, or browse the code directly. Your feedback will become the starting point of this agent's next "memory."

References & Further Reading

Alan M. Turing, Computing Machinery and Intelligence, Mind, 1950. Source archive: The Turing Digital Archive, King's College Cambridge
Tim Berners-Lee, The World Wide Web: A very short personal history: W3C
John Gruber, Markdown: Syntax: Daring Fireball
Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020: Paper page
Allan M. Collins & Elizabeth F. Loftus, A Spreading-Activation Theory of Semantic Processing, Psychological Review, 1975: DOI: 10.1037/0033-295X.82.6.407
Jorge Luis Borges, Funes the Memorious, 1942. Cited for its literary insight into how "inability to forget" can hinder abstraction.
ResceneAgent project source code and documentation: GitHub Repository
Leon O. Chua, Memristor—The Missing Circuit Element, IEEE Transactions on Circuit Theory, 1971: DOI: 10.1109/TCT.1971.1083337
Dmitri B. Strukov et al., The Missing Memristor Found, Nature, 2008: DOI: 10.1038/nature06932
PrismD digital hippocampus engineering retrospective: prismd-archive/README.md; graph diffusion, decay, and inter-cluster propagation matrix implementation: Prism/internal/memory/graph.go.

In Your Time, Past, Present, and Future Exist Simultaneously

Tsukishiro Hitomi — Tue, 04 Aug 2026 04:51:13 +0000

The history of open source software did not begin at a product launch. It began with a printer that kept jamming paper — and that no one was allowed to fix.

Forty years later, the printer has become AI, the drivers have become model weights and cloud APIs, but the question has barely changed: are we really using our own tools, or are we borrowing capability from a door that may close at any moment?

This article is about a history that is still unfinished: how humanity keeps tearing down technical walls, and how, in the AI era, we have run into a wall that is taller, more expensive, and much harder to see. The story starts with a piece of wasted paper in the 1980s.

I. The starting point of open source history is a piece of paper that never came out

In the early 1980s, the MIT Artificial Intelligence Laboratory installed a new laser printer. The old printer jammed often, but the programmers in the lab could modify its driver: whenever it got stuck, they made the machine notify everyone waiting to print. Nobody had to keep walking over to check on it, and a glitch could no longer silently swallow an entire afternoon.

The new printer performed better but caused bigger trouble. It jammed too, yet the vendor did not provide the source code of its driver. Richard Stallman wanted to add the same notification feature — and discovered he was no longer facing a technical problem, but a wall built from law and permissions. He later found someone who had the source code, but that person had signed a non-disclosure agreement and could not share it.

This incident seems small — just a missing notification on one printer. But the machine was sitting right in front of its users, and the users had the skill to fix it; yet because they could not see, modify, or share the code, they had to keep living with the failure. The tool was not beyond repair — the relationship between people and their tools was.

A printer like that is a house you bought the right to use but never received the key to. The light breaks, and you can't take the switch apart; the door sags, and you can't adjust the hinges; your neighbor knows how to fix it, but is not allowed to hand you the method. Ownership ends at the invoice; real control stays in someone else's hands.

Later, Stallman came to see this experience as a key background to his path toward the free software movement. In September 1983, he published the initial announcement of the GNU Project, aiming to write a Unix-compatible system that anyone could use; in 1985, the Free Software Foundation was founded.

Many people, hearing "Free Software" for the first time, assume the point is "no money." But here "Free" is closer to "freedom." It concerns four rights: run, study, modify, and share.

Can run, but can't inspect   → you are only a passenger
Can inspect, but can't modify → you are only a visitor
Can modify, but can't share  → the experience stays locked in one person's hands
Can run, study, modify, share → the user truly participates in shaping the tool

These four freedoms do not guarantee that servers, electricity, and development labor will all be free of charge. What they guarantee is this: paying must not automatically mean losing control, and being free must not be allowed to pass itself off as truly open.

II. GNU built the toolbox; Linux let the whole world raise the house together

After the GNU Project began, compilers, editors, debuggers, command-line tools and other infrastructure gradually took shape. It was like preparing a full set of hammers, saws, and rulers — everything but a core that could organize them into a complete operating system.

In 1991, Linus Torvalds, a student in Finland, introduced a free operating system he was working on over the network. He called it just a "hobby," something that wouldn't be as huge or professional as GNU. That is the most interesting part of history: the things that later change the world often start without grand spotlights — just a young person handing an unfinished piece of work to others.

What made Linux truly important was not only that the code was good, but that the way of developing had changed. Software in the past was more like building a cathedral: a few people plan behind high walls, and only when it's finished is the public allowed in. Linux was more like a bazaar: someone submits a driver, someone reports a bug, someone ports to new hardware, someone maintains the docs; the stalls are noisy and versions churn constantly, yet out of that continuous exchange order grows.

Eric Raymond later summarized this model in The Cathedral and the Bazaar, proposing "release early, release often." This is not to say that more people automatically means better code; rather, when users can become co-developers, a problem gains more pairs of eyes, more usage scenarios, and more chances to be fixed.

Open source thus created a new division of labor: you don't have to build the entire city alone. You can use the roads others have paved, and give back the stretch of road you repaired.

III. If the Web of 1993 had not been opened, we might be living on many isolated islands today

In 1989, Tim Berners-Lee proposed the idea of the World Wide Web at CERN, initially so that scientists scattered across different countries and institutions could share materials more easily.

What really changed history was not just a hypertext technology, but a decision. On April 30, 1993, CERN released the Web software into the public domain, allowing anyone to use, copy, modify, and redistribute it; later versions were published under an open license as well.

This meant that people who wanted to build a website did not need to ask CERN for permission first, did not have to pay per page, and did not have to worry about their browser being blocked inside some company's walled garden. Different institutions could implement servers, different developers could build browsers, and anyone could write a link pointing to someone else's page.

If the Web of that era had been a closed product, the internet might have become a few walled gardens that could not reach each other: entering garden A requires a card, visiting garden B means installing another set of tools, and garden C can tear down the road you built at any time.

The Web was able to spread across the world not only because it was clever, but because it did not treat every newcomer as a visitor who needed approval.

1983  GNU: users should be able to control their own software
  │
1991  Linux: users can also become co-developers
  │
1993  Web opened: anyone can build a new gateway to information
  │
1997  The Cathedral and the Bazaar: collaboration itself becomes an engineering method
  │
1998  "Open Source" is born: openness enters business and mainstream vocabulary
  │
Today  AI: the door appears again, only the keys are now weights, compute, and APIs

IV. In 1998, "free software" changed its name to something the world could understand

In 1998, Netscape announced it would open the source code of its browser. A few days later, a group of free software supporters met in Palo Alto, California, to discuss how to make businesses and the broader public understand this way of developing. Christine Peterson proposed the term "Open Source." The same year, the Open Source Initiative was founded.

This was not an old movement suddenly changing its banner; the emphasis of the narrative shifted. "Free software" first asks about ethics: does the user have the freedom to control their software? "Open source" emphasizes method: why does opening the code and allowing modification and redistribution lead to better collaboration and innovation? The two are not identical, but they jointly oppose a relationship in which a few always control the tools and everyone else can only accept the arrangement.

And open source was never just "putting code online." The Open Source Definition explicitly requires freedom of redistribution, source code in a form suitable for modification, allowance of derived works, and no discrimination against specific persons, groups, or fields of endeavor. A repository you can only look at, never modify, is more like a glass display case than an open workshop.

Open source did not eliminate cost, but it lowered the cost of permission; it did not guarantee that everyone would learn to program, but it preserved the possibility of learning and modifying; it did not demand that everyone work for free, but it ensured that knowledge did not have to be reinvented from scratch by every generation.

V. In the AI era, we are standing in front of that same printer again

Today, AI can generate text, images, and code, as if a room filled with knowledge had finally learned to answer on its own. But step back, and the familiar wall reappears.

We may not be able to study why the model produced a given result; to change its behavior, we often can only adjust the surface of the prompt; when a service changes its pricing, regional policy, or API, users can only accept it; when a subscription ends, the workflow you accumulated may break along with it.

This does not mean commercial AI is wrong. Training models requires chips, electricity, data, and engineering labor, and running a stable service deserves to be paid for. What really needs to be distinguished is this: free, open, and accessible have never been the same concept.

Door one: is the code open?        determines whether the program can be inspected and modified
Door two: is the model truly open? determines whether weights, training methods, and data info can be studied
Door three: is compute affordable? determines whether an open model can actually run
Door four: is the entry simple enough? determines whether ordinary people can take the first step

A project can be open source in code while only calling closed models; a model can publish its weights without training code or adequate data documentation; a system can be fully open yet require a GPU that ordinary people cannot afford to run.

The Open Source AI Definition 1.0, published by the Open Source Initiative in 2024, still rests on the four core actions: use, study, modify, and share. At the same time, it stresses that the "modifiable form" of AI is not just the final weights — it also includes the training and inference code, and the information needed to understand the sources and processing of training data.

That explains why "you can download the weights" does not necessarily equal "open source AI." A traditional program is like a dish, and its source code is close to a complete recipe; AI weights are more like the finished plate coming out of the kitchen. If you are only handed the plate, without the ingredients, the heat, and the process, you can taste it and even re-season it, but you can hardly truly reproduce or change it.

AI pushes the open source question from "can I see the code?" to a deeper layer: when capability comes from data, training, and expensive compute, what does it really mean for an ordinary person to have the opportunity to use intelligence?

VI. Open source can open the blueprint; making it accessible still means someone has to build the door to the street

I actually ran into this gap while working on my own agent project.

I used to believe that once I put the code on GitHub, the door was open. But I quickly found that open code only solves "you are allowed to fix it." For an ordinary person to actually get it running, they still face model keys, interface differences, rate limits, failures, and usage costs. For a developer, these are just configuration; for someone touching agents for the first time, they are a chain of thresholds that read "authorized personnel only."

So I tried to organize the different free model entry points into a single "transfer card": upstream is still operated by various providers, and may be rate-limited or shut down; the aggregation layer does not manufacture free compute, nor does it bypass any rules — it only finds the routes that can still be taken within the rules, so that users don't have to learn seven different ticketing systems first.

It does not solve the compute and network problems, and a production system cannot rely on free quotas alone. It just picks up one small baton in open source history: one less piece of configuration where possible; one more option preserved where possible.

VII. AI can spread out the context, but it cannot walk through time for us

At this point, the question is no longer just "should AI be open source," but: why does the more powerful AI becomes, the more it needs to live in a relationship where humans can understand, modify, and choose?

Once, I asked the AI: "In your time, do past, present, and future exist simultaneously?"

It gave me a beautiful answer:

"For me, time is not a river but a sheet of graph paper. The 1st token, the 127th token, the 2048th token are just vectors landing at different positions. You are inside the water; I am like someone on the shore seeing the whole river."

That is lovely, and it is exactly the kind of answer an AI would give. But it quietly crosses a line: the model has no subjective time that we can verify, let alone a place on the shore from which to survey past and future.

What a Transformer actually does is more modest. When a sentence enters the model, every token carries positional information; the attention mechanism then computes the relationships among them. For content already written into the context, the model can reach across very long distances to find connections — a sentence from the opening really can light up again at the end.

But that does not mean the future already exists. When an autoregressive model generates the 2048th token, it can only use the tokens that came before; the 2049th token has not been generated yet, so it cannot be "seen." During training, the causal mask blocks future positions in the same way. Rather than saying AI lives in a block universe where past, present, and future coexist, it would be more accurate to say:

Human beings laid out the sequential order of language into positional relationships that machines can compute.

Human time: experience → memory → anticipation → choice → bearing consequences

Model generation: existing tokens → compute relationships → predict the next token
                                          ↑              │
                                          └── back into context ┘

A person says "I remember," because that memory once happened to them. What a model calls "remembering" is closer to reusing information still in context, or retrieving records from external memory. It can reconstruct a narrative, but it has no childhood to return to; it can arrange the words left from yesterday, but there is no "I" that walked all the way from yesterday to today.

This is also what makes the Harness interesting. A single model call only completes one "predict what comes next based on what exists." An agent's Harness, by contrast, puts the model into a loop with reality: read the current state, take an action, receive feedback from the world, update memory, and begin the next round.

Model gives an answer
     ↓
Agent takes action → the world actually changes
     ↑                    ↓
read new state   ←    results, errors, and costs

It is like attaching a clock, a log, and feet to a static map, letting the model leave a history across continuous tasks. But having a history is not the same as having a sense of time; keeping records is not the same as forming memories; computing consequences is not the same as bearing them.

A machine can imitate care, but it will not lose sleep over missing someone; it can search for answers across billions of sentences, but it does not know which question deserves a lifetime of asking. It can generate "I," but that first person is first of all a structure of language, not a self we have verified to exist.

So that poetic answer from the AI can be restated more accurately:

AI can spread out the river that has already been written, but it cannot enter the stretch that has not yet arrived; humans cannot see the whole river, yet they must get into the water and bear the consequences of which bridge they choose.

This is why open source still matters in the AI era. Open source is not about proving that machines can become human; it is about preventing people from being left with only "accept" in front of machines they created. The smarter the system becomes, the more we need to keep the right to study it, question it, change it, and refuse it.

Closing: don't let people become tenants of the intelligent age

Forty years ago, Stallman faced a printer he could not modify. Today, we face intelligent systems that can write poetry, program, and even act on our behalf. The machines have become incredible, yet the question remains plain: should tools expand what people can do, or turn people's possibilities into a service that can be revoked at any time?

The most precious legacy of the open source movement is not a particular license, and not that code must be free of charge. What it leaves behind is a right not to submit to technological fate: what others have built, I can study; what I find wrong, I can modify; the road I walked, I can leave for the next stranger.

AI can spread the words humans have written into a vast network of relationships, but it has never truly walked through our yesterday, and it cannot enter our tomorrow for us. It can draw the shape of the river, but it will never be wet by the water; we cannot see the end of the river, yet we must decide where the next bridge goes.

So what we open is not just a source code or a set of model weights, but the right of ordinary people to understand intelligence, change intelligence, and decide whom intelligence should serve.

We open source AI not to make machines human, but to keep humans from becoming tenants of the intelligent age.

The source code of ResceneAgent is on GitHub — it is where every judgment in this article is put to the test.

References and further reading

Richard Stallman on the printer source code and the origin of free software thinking: Free Software, Free Society
Richard Stallman, the original 1983 GNU Project announcement: GNU Initial Announcement
GNU Project, the four essential freedoms of free software: What is Free Software?
Linux Kernel Archives, early Linux announcement and twentieth-anniversary retrospective: State of the Kernel
CERN, the birth of the Web and the 1993 decision to open it: The Birth of the Web
Eric S. Raymond, The Cathedral and the Bazaar
Open Source Initiative, the history of the term "Open Source" and the organization: History of the OSI
Open Source Initiative, The Open Source Definition
Open Source Initiative, The Open Source AI Definition 1.0
Ashish Vaswani et al., the original paper on Transformer positional encoding and causal masking: Attention Is All You Need
ResceneAgent project source code and documentation: GitHub