the graph was not wrong. it was just in the wrong place

I created this post for the purposes of entering the Gemini Live Agent Challenge, and it is also my attempt to explain why two things I wrote this week appear to contradict each other when they actually don't.

A few posts ago I was deep in the 9-agent graph story.

That was real. I was excited about it for good reason. The graph gave VibeCat useful capabilities: screen analysis, memory, mood signals, search, celebration, speech gating. I still think that work mattered.

Then the project pivoted harder toward desktop UI navigation, and suddenly the thing I cared about most was not whether the graph was elegant. It was whether the system could safely do the next step in front of the user.

That made it sound like I had changed my mind completely.

I didn't.

I changed my mind about placement.

why the old posts were still true

When I wrote about nine agents, I was looking at the intelligence layer in isolation.

In that layer, decomposing the problem really did help. Separate pieces for memory, mood, celebration, search, and mediation made the analysis pipeline easier to tune. I could change frustration thresholds without touching celebration logic. I could change speech gating without touching memory retrieval. That was good engineering.

If all VibeCat had to do was observe, summarize, and occasionally comment, that architecture was pretty defensible.

what the ui navigator version changed

The problem is that UI action has a very different failure mode.

A bad analysis result is annoying.

A bad click is scary.

A slow summary is forgivable.

Typing into the wrong field is not.

Once I started treating VibeCat as a desktop UI navigator instead of just a companion, the hot path changed completely. The important question stopped being "how many specialists can contribute here?" and became "who is allowed to decide the next executable step right now?"

That answer turned out to be: not a crowd.

where the graph belongs now

The graph still belongs in the product. It just belongs behind the immediate action loop.

That means the structure now feels more honest:

Live PM          -> talks to the user
navigator worker -> decides the next safe step
local executor   -> performs and verifies the step
background graph -> helps when extra intelligence is actually useful

That last line is the important one.

The graph is not dead. It is no longer the thing that every single click has to wait on.

the practical example

If the user says, "open the official docs," I do not want a miniature parliament of agents trying to co-author the moment.

I want:

• one worker to decide if the request is executable
• one check for ambiguity
• one risk check
• one step
• one verification result

If, later, the system needs more context because the target is unclear or the user seems stuck, then the slower intelligence lane can help.

That is a better use of the graph.

the part i had to swallow my pride about

I think a lot of us like architectures that sound impressive when we say them out loud.

I definitely do.

"Three parallel waves and nine specialist agents" sounds like progress. "One worker does one step at a time" sounds almost embarrassingly plain by comparison.

But the second version is closer to what a user can actually trust.

That was the hard part for me. Not building the new shape. Admitting the new shape was better.

so what changed, exactly?

Not the belief that decomposition can help.

Not the belief that background intelligence matters.

Not the belief that VibeCat needs memory, research, and multimodal context.

What changed was this:

I stopped asking the graph to own the exact moment where the product becomes risky.

That moment now belongs to a narrower worker with a stricter contract.

And that change made the whole project feel less like a cool diagram and more like a real tool.

---

Building VibeCat for the Gemini Live Agent Challenge. Source: github.com/Two-Weeks-Team/vibeCat