When an Agent runs for days, where it gets stuck is usually not the model
Google Cloud's Agent 102 workshop has been organized into a 6-layer architecture. Shoopy's long-form piece on graph engineering discusses another issue: when a single-agent loop should be split apart, and after splitting, human attention becomes the new bottleneck.
The difference between an agent running for three minutes and running for three days is not in the model parameters. Run it for three minutes, and when the request ends and the process ends, nothing is left behind. Run it for three days, and it has to wait for you to approve a budget on Tuesday afternoon, resume from the same node after a server restart in the early hours of Wednesday, check the seat one more time before placing an order on Thursday, and avoid charging the money twice because of a retry.
Shoopy organized the content of the Google Cloud Agent 102 workshop into a 9-page summary, broken into 6 layers. He explained in a reply that this is not an official Google PDF, and the original session is on Annie Wang's YouTube channel.
The 6 layers are Trigger, Runner, State, Resumable Workflow, Human Gate, and Guards.
Layer one: Trigger. The model cannot set an alarm for itself. Only when the scheduler hits a /wake endpoint does the agent run again. This sounds like a truism, but many agent demos assume the model will remember to come back; in fact, it won't.
Layer two: Runner. adk web is a development tool, not a production environment. Your server has to own the runner, sessions, and storage itself.
Layer three: State. Put the session in a real database, put user preferences under user:, and put facts in memory. A restart must not lose anything.
Layer four: Resumable Workflow. Kill the server in the middle of a queue, and it resumes from the same node. Steps that have already completed are not rerun. This layer is the watershed between long-running agents and chatbots.
Layer five: Human Gate. The agent requests a budget, then stops and waits for a yes. This pause also has to survive restarts. A commenter asked whether pending approval is persisted, and Shoopy replied that it exists as an event in the session; with persistent sessions and resumability, after a restart the answer returns to the same node.
Layer six: Guards. Recheck the seat before buying, and use one idempotency key per order. A retry will not charge the money twice. A commenter said that any agent that spends money must not turn a retry into a double charge; Shoopy agreed: retry-safe or don't ship it.
Of these 6 layers, the easiest to skip are layers 5 and 6. They do not produce demo effects; they only keep you from being woken up by a bill at 3 a.m.
Shoopy also wrote a longer article called Graph Engineering. Its core judgment is: within a loop, an agent can plan, write code, test, and review, but as soon as the task gets complex, the context window fills up, reasoning degrades, and the human is back in the chair reading every diff.
His solution is to split the work among specialist nodes. One node classifies, one node fixes, one node reviews, and one node retries. Then use edges to route the work and state to pass information along. Nodes do things, edges decide the next step, and state is the shared data flowing along the edges. A loop is the minimal graph; graph engineering does not replace the loop—it sits on top of it.
But not every task is worth drawing a graph. Shoopy gave four questions: Will failures repeat? Do different failure types need different handling? Should the agent that writes a fix not approve the fix? Is the single-agent loop already the bottleneck? If any answer is no, keep using the loop.
When it actually comes to implementation, several details matter more than the architecture diagram. One node, one verb: the classifying node does not fix, and the fixing node does not review itself. Tool scopes should be narrowed: the reviewer cannot write files, and the fixer cannot merge PRs. Do not put hard constraints in the prompt. Prompts are suggestions; edges are code. Routing rules should be written in the edge logic, because a prompt may be ignored by round 47 of a long session.
Don't broadcast state either. Each node should get only the slice it needs. The classifier gets the raw logs; the fixer gets the classification result, the names of failing tests, and the most recent diff. If every node reads the full state, what you get is not a graph—it is a more bloated context window.
Gates are another underestimated part. Hard gates are tests, type checks, lint, and builds; if it passes, it passes. Soft gates are a second model review, stronger than no gate but weaker than tests. The human gate is the last step before merge or deploy. Karpathy's rule is very direct here: if a task is verifiable, it can be optimized. Cherny offered one data point: giving Claude an effective verification method usually improves final output quality by 2 to 3 times. Anthropic's multi-agent research also mentions that splitting agents into specialists with isolated contexts improved results by 90.2% over a single-agent baseline on an internal research benchmark.
Graph Engineering ends by discussing two kinds of debt. Understanding debt grows as the graph writes code for you; a quietly running system looks like progress, but the gap between what exists in the repository and what you truly understand is accruing interest. Cognitive surrender is more insidious: when the graph runs by itself, it is easy for people to stop forming judgments. The mitigation is not technical: read every diff, spot-check the gates, limit the graph to small, machine-verifiable tasks, and find someone to design the graph with.
At this point, the problem shifts from the model to the people.
Volodymyr Gutorov said in a reply that moving from a loop to a graph of specialists improved throughput, but it also added more nodes that stop and wait for a person. Watching 4 to 5 Claude Code sessions is itself a job. He built a desktop OLED device called Claude Mate to mark which session is done, waiting, or errored.
There are two versions of the device. The Arduino Nano version uses USB, a 128×32 monochrome OLED, and three buttons. The ESP32-S3 version is wireless, with a 172×320 color screen, a 14500 battery, four buttons, and it can show a live mirror of a session's terminal on the device. Both versions speak the same protocol. The screen shows only one session, and a letter strip at the bottom shows the status of the whole queue: E error, B waiting, W working, D done, I idle. An LED uses different rhythms to indicate the most severe unacknowledged alert, and pressing GO brings the corresponding terminal window to the front.
What it solves is not whether an agent can run, but where human attention should go once multiple agents run in parallel. A commenter said that graphs give you width, but the cost falls on people: once the planner, coder, and reviewer run in parallel, the work becomes judging which branch is stuck. Claude Mate compresses that into a small screen and a button.
The project is on GitHub under a non-commercial license. You can try it without hardware; running claude-mate in the terminal gives you the same interface.
Most teams cannot use graphs yet. First get a single loop working, persist state to the database, make retries idempotent, and stop to wait for a person where you should. If the loop is already the bottleneck, then split it by nodes, edges, state, and gates. The default configuration for a long-running agent is not complicated: give waiting to the scheduler, state to the database, recovery to the workflow, and money to the human gate and idempotency keys. What remains is reading diffs.
Reference links:
发布时间: 2026-10-27 22:48