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

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

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