AITOPAI热报
PapersSelected

Google Paper: OO-Harness Specialist Harnesses Outperform One Global Agent Harness

rohanpaul_ai@rohanpaul_ai
Post
View the post
Why we picked it

The object-oriented structure explains why single-harness tuning keeps trading one task type's gains for another's losses, and shows a router can avoid that cost on out-of-distribution tasks. Teams building agentic pipelines can adopt the pattern directly: keep the base harness as fallback and route to specialists only when runs match known failure clusters. The AutomationBench comparison against Meta-Harness gives a concrete baseline for evaluating similar routing setups.

A Google paper introduces OO-Harness, an object-oriented method that evolves agent harnesses as code classes, with specialist harnesses inheriting from a parent and modifying only what their task cluster needs. A router reads a base run and selects a specialist or keeps the base result. On AutomationBench business workflows, OO-Harness scored 77.41% versus 61.62% for the base harness and 63.92% for Meta-Harness, a global method. On unfamiliar apps, it retained the base harness and held a 59.18% pass rate, while Meta-Harness's global harness dropped to 44.90%.

Original · rohanpaul_ai

New Google paper shows that agents score higher when each task gets a specialized harness from a shared family, not 1 global harness.

An agent harness is the prompts, tools and control code around a model. Most tuning methods evolve 1 global harness, though a fix for 1 task type can hurt another.

OO-Harness evolves harnesses as code classes, and each specialist inherits from a parent and changes only what its cluster needs. A router reads a normal base run and picks a specialist or keeps the base result.

On AutomationBench business workflows, it scored 77.41% versus 61.62% for the base harness and 63.92% for Meta-Harness, a global method. On unfamiliar apps, it kept the base harness and held 59.18% pass rate, while Meta-Harness's global harness fell to 44.90%.

For mixed workloads, keep the base harness as a fallback and route to specialists only when a run shows a known problem.

#Google#agents#OO-Harness#AutomationBench

Keep reading

Recent stories with the same tag or section
ProductsBuildersSelected02:54
vLLM-TorchTPU brings native PyTorch serving to Google TPUs

The practical effect is that vLLM's optimizations — prefix caching and speculative decoding — now apply to TPU hardware, giving teams a second accelerator option beyond NVIDIA GPUs for self-hosted inference. Organisations already locked into the PyTorch and vLLM stack can evaluate TPU economics without rewriting their serving code. It also signals Google's continued push to open TPU inference beyond JAX.

#vLLM#TPU#PyTorch#Google
官方账号vLLM@vllm_projectSource
ProductsBuildersSelected72°00:31
TorchTPU brings native PyTorch support for Google TPUs

PyTorch developers can now target TPU hardware through the same APIs they already use, reducing the migration cost that historically kept most teams on NVIDIA GPUs. Teams running training or inference pipelines with TorchTitan, vLLM, or SGLang can evaluate TPUs without rewriting code. The use of agents for kernel generation and sharding also hints at how optimization work itself may be automated.

#TorchTPU#PyTorch#Google#Meta
Event
官方账号PyTorch@PyTorch2 sourcesSource
How-toBuildersSelected02:27
NotebookLM Video Overview System Prompt Reveals Three-Stage Workflow

The three-stage structure — gather context, generate review cards, then produce video — is a reusable pattern for anyone building AI pipelines that turn documents into presentations. Developers can compare it with their own document-to-video or summarisation agents and borrow the intermediate review-card step as a quality gate. NotebookLM users gain a clearer picture of what the tool does with their sources.

#NotebookLM#Google#prompt engineering#video generation
宝玉的分享@宝玉Source
IndustryBuildersSelected08:50
First TPUv7 Submission Hits AgentX Benchmarks via vLLM

TPUv7 support reaching an agent benchmark stack signals that Google's accelerator line is becoming a practical serving target outside Google's own inference services. Teams evaluating inference hardware can now weigh TPU against GPU serving with real AgentX runs rather than vendor claims. The collaboration spans Google, Red Hat AI, and Inferact, showing the open-source serving ecosystem converging on TPU support.

#vLLM#TPU#AgentX#Google
官方账号vLLM@vllm_projectSource
PapersUS vs ChinaOfficialSelected00:43
Google Research Shows Geospatial Reasoning Agent for Spatial Analysis

The design choice here is to route spatial questions through specialised foundation models and explicit planning rather than relying on one general LLM, a pattern applicable to any domain where generic models underperform. Teams building analysis pipelines for climate, mapping or disaster response can study the architecture. It also signals Google is pushing agentic systems beyond text into geospatial data.

#Google Research#Geospatial Reasoning#agents#multimodal
官方一手Google Research@GoogleResearchSource
PapersBuildersSelected21:26
Google Publishes Agent Tools & Interoperability Whitepaper

The non-obvious takeaway is the paper's stance that expert agents should be collaborators, not tools — forcing a peer agent into a tool wrapper is like introducing a GOTO statement. Developers building multi-agent systems in production can use its protocol-by-protocol guidance to pick the right integration layer, from MCP tool calls to AP2-secured payments.

#Google#MCP#A2A#agents
shao__meng@shao__mengSource