Context curation and lazy prompting
Timestamp: [03:35]
Upfront harness investment pays off by allowing engineers to become lazy prompters. When the repository contains structured documentation, clear interfaces, and discoverable tools, you do not need to paste walls of text into a prompt box every morning
“I aspire to be an incredibly lazy prompter. If I have done the job to give the model the tools and context it needs to ground itself, I don’t need to write a long prompt. It figures it out.”
The model uses its harness to pull relevant context, allowing it to navigate large codebases and execute complex tasks without oversight.
Shifting left: engineering best practices as autonomous guardrails
Timestamp: [05:00]
When an agent fails, developers face a whole spectrum of interventions. The most common reflex is to fiddle with the prompt or retry, but that never scales across a team.
“The simplest, smooth-brain, stupidest intervention I can think of is literally just: try my prompt again without changing anything else. But shifting left means moving interventions earlier into the development lifecycle where they are cheapest and automated: from prompts, to repo docs, to linters, to tests, and all the way to upstream evals.”
Instead of hoping the model guesses right on the next turn, shifting left embeds standards directly into the environment. Linters, tests, and AGENTS.md files act as durable memory and enforcement of what you think good looks like, making sure the agent stays on the rails without needing constant hand-holding.
Leveraging established tools and determinism
Timestamp: [06:50]
Agents shine when they’re handed tools that already mirror patterns heavily represented in pre-training data. Pairing models with standard command-line interfaces moves reasoning into determinism, shifting the burden of context aggregation away from the model and onto reliable tools.
Ryan also shared an environmental design trick for context efficiency: structuring markdown files so link anchors sit directly beneath their corresponding prose blocks rather than inline. This prevents context clutter and mitigates “lost in the middle” retrieval issues. Because Ryan operates exclusively by reviewing end-state artifacts, keeping documentation readable allows him to easily inspect execution runs:
“I want to be able to look at the pull request and review it. If it made a bad decision, I need to know where it went off the rails so I can whack the agent on the head and make sure it does not make that same mistake again.”
Long horizons and expanding the agentic loop
Timestamp: [09:45]
The central challenge of harness engineering is ensuring that agents cohere over long time horizons. Because human organizations produce software through iterative refinement rather than single-shot prompts, agent workflows must mirror that cadence. Harness engineering uses tightly scoped, reviewable pull requests to narrow the agent’s state space. Stacking these high-confidence changes end-to-end allows supervisors to gradually expand the loop size, building trust until agents can autonomously execute large-scale initiatives, including entire language migrations
Curating agent teams like RPG stats
Timestamp: [11:58]
Rather than divvying up sprint tasks based on individual specialties, having a diverse team contribute to an agent turns it into a central producer of work that carries everyone’s strengths. Ryan compared leveling up an agent’s capabilities to building out a character sheet:
“[It’s like] building out the stats of your RPG character. I get a new person on the team who is a React architect and boom! The attention that they pay is able to bump out the stats in front-end architecture and performance.”
With that collective expertise baked into the environment, the agent can autonomously classify incoming work and activate the exact skills it needs on demand, operating as both a backend architect and a front-end specialist.
Accruing leverage in tools, not custom harnesses
Timestamp: [14:38]
For developers wondering whether to build their own custom agent harness, Ryan offered clear advice: don’t build one from scratch. Standard harnesses already provide the foundational primitives: file reading, grep search, and command execution. Over-scaffolding an agent with rigid, bespoke frameworks creates technical debt and leads to sunk-cost traps when frontier models advance.
“If you focus all of your efforts on improving quality on tools and context, you can freely adopt the newest models as they come out and you’ll be constantly accruing leverage into a bit of the system that will never become obsolete.”
Operating Google Cloud and eliminating capability overhang
Timestamp: [16:47]
Discussing his work at Google Cloud, Ryan outlined his motivation to eliminate capability overhang: the delta between what frontier AI models are theoretically capable of and how much useful work is currently extracted in production. Because the cloud functions as a massive, programmable surface, equipping agents with direct interfaces to Google Cloud lets them manage and deploy infrastructure effectively, turning raw model capability into tangible enterprise utility.
Continually updating your priors on AI
Timestamp: [18:13]
The speed of AI development requires engineers and teams to actively unlearn old limitations and constantly reassess what these models can achieve. “It’s very important to continually be updating what you think is possible with these lovely tools that we have,” Ryan urged. What broke six months ago often runs effortlessly on today’s frontier models. Rather than getting locked into rigid workflows, developers should build around the two highly extensible interfaces that will remain relevant across every model upgrade: tools and context.
“Agents will always need context in order to do that last mile adaptation into what you think good is. And as you can continue to… shift it to the left, in terms of increasingly capable tools which act as a form of memory and enforcement of what you think good looks like, you’ll continually be amazed as the models are able to do more and more interesting things for you over time.”
How To Build A Custom Harness
Next, Billy Jacobson started us off by showing how developers can customize their own agent harnesses for specific tasks.
Under the hood: Why build a custom harness?
Timestamp: [19:44]
Before jumping into code, Billy unpacked why developers should understand the mechanics of a harness rather than treating it like a black box. Recalling advice from an engineering mentor that “You can just use the framework, but a great engineer will really understand the framework”, Billy explained that building a harness yourself is the best way to debug what happens when an agent breaks. You can evaluate three core design decisions for every workflow:
-
Looping: How many iterations should the agent run, and what conditions trigger an exit state?
-
Tools: What specific tools should the agent access, and when and how should it invoke them?
-
Memory: How important is conversational and operational memory, and when should it be retrieved or compacted?
Linear Agent Harness: Deterministic Single-Pass Execution
Timestamp: [21:34]
Billy demonstrated a minimalist linear harness designed for deterministic workflows where looping is unnecessary. This pattern is ideal for targeted inspections, file transformations, or single-turn data analyses where you want a high level of determinism and need the agent to perform the exact same execution flow every single time.
Closed-Loop Agent Harness: Iterative Test-Driven Repair
Timestamp: [22:45]
When tasks demand active bug fixing and refactoring, a closed-loop harness provides the iterative reasoning required to reach a verified resolution.
In this demo, Billy showcased an agent that applies an automated code edit to address a failing requirement, and the harness executes the unit test suite against the updated codebase. If the tests fail, the runtime captures standard failure logs and detailed stack traces, feeding those error diagnostics directly back into the agent’s working memory. The process repeats continuously until all unit tests pass, backed by a five-iteration ceiling to prevent infinite loops and runaway execution costs.
Guardrail Harness with Google’s Agent Development Kit (ADK)
Timestamp: [23:25]
For developers who require custom behavior without rewriting core orchestration plumbing from scratch, Google’s Agent Development Kit (ADK) provides scaffolding with automated memory management and execution safeguards.
Billy walked through an example that leverages ADK’s native context compaction to summarize older conversational turns, preventing context window bloat during extended debugging runs. Custom interception hooks inspect and filter shell actions before execution, automatically stopping high-risk operations such as recursive file deletions, database drops, or unauthorized remote git pushes. This architecture gives teams fine-grained control over tool execution boundaries while avoiding the maintenance burden of bespoke harness frameworks.
The 3-Layer Agent Dev Stack: Gemini 3.8 Flash, Google Antigravity, and Google Skills
Timestamp: [25:27]
Next up, Smitha Kolan broke down why coding agents do not always require heavier reasoning models, emphasizing that high performance stems from balancing the three layers of the agent stack: Model, Harness, and Knowledge.
“Your coding agent doesn’t need a smarter model. It needs a better stack: model, harness, and knowledge. When all three click into place, everything changes.”
She then walked through the three tools she’s been loving recently, one for each layer of the stack.
Layer 1 | Model | Gemini 3.8 Flash: High-frequency agentic loops run between 20 and 60 sequential hops per task (inspecting files, updating functions, and executing unit tests). Because latency and API costs compound across iterations, a lightweight, responsive model like Gemini 3.8 Flash makes real-time agent loops practical without running up a massive bill.
Layer 2 | Harness | Google Antigravity with /boost: Default Antigravity handles standard navigation and component creation. On top of that, the /boost command spins up an orchestrator that coordinates specialized sub-agents in parallel and concludes with an independent audit pass before modifying files.
Layer 3 | Knowledge | Google Skills Repository: With over 19,000 GitHub stars and 100+ curated domain packages across Google Cloud, Firebase, Flutter, and Maps, this harness-agnostic repository injects precise domain context on demand, preventing agents from guessing cloud configurations
Your turn to build
Building effective coding agents requires moving past the reflex of simply swapping in larger models. As Ryan Lopopolo’s philosophy of harness engineering illustrates, true developer leverage is achieved by shifting best practices to the left and investing in rich tools, deterministic verifiers, and well-curated context that survive model upgrades. When combined with fast inference models, structured orchestration harnesses, and modular domain knowledge, agents evolve from conversational novelties into dependable, autonomous engineering partners.
Ready to put it into practice? Explore the tools and resources covered in this episode:
