Cross-Model Agent
Collaboration in Herdr

The outcome, up front

The requirement & the silent roadblock

This was not a synthetic benchmark or a toy demo. It was an active production deliverable on our roadmap: we needed to connect Google's new Gemini app to our enterprise Partner Portal through a custom Model Context Protocol (MCP) server, allowing operators to orchestrate portal tools directly from Gemini.

The OAuth 2.0 PKCE handshake was configured, and we initiated live integration testing. An administrator initiated the connection from the Gemini application, which opened our portal's consent authorization modal. Everything looked correct. But the moment the admin clicked Approve, the modal vanished instantly.

Gemini remained disconnected. No tools synced, and no error message appeared on the screen.

Looking at the backend from a terminal, Kilo initially hypothesized that Google's relay endpoint required URL fragment parameters (#code=...) instead of query parameters. But without a browser window, Kilo was guessing in the dark. That is where our Herdr environment changed the entire dynamic.

Working in Herdr: Autonomous agents across harnesses

In our daily setup, we don't rely on a single monolithic assistant loaded with dozens of conflicting tools in one bloated context window. Instead, we work inside Herdr, a terminal multiplexer built for multi-agent pairing.

Herdr allows us to maintain specialized agents in separate terminal panes, each running the specific foundation model and tool harness tailored to its role:

Because these agents live in Herdr panes connected by an inter-pane bus (herdr agent prompt), they don't require human copy-pasting of logs. When Kilo hit this roadblock, it could directly task Hermes in the browser pane and wait for real telemetry before writing a line of code.

How the agents solved it, step by step

Round 1 — Debunking the server-side guess

Kilo initially suspected Google's relay endpoint was rejecting query-string parameters. Instead of blindly refactoring the backend, Kilo tasked Hermes via Herdr to inspect the browser during an approval click. Hermes attached to Chrome via CDP and returned immediate ground truth: the request never left the browser. Chrome had aborted the navigation locally before a single packet hit the wire. Kilo's fragment hypothesis was disproven in seconds.

Round 2 — Hermes catches the Next.js global CSP overwrite

Hermes inspected Chrome's security console log and extracted the actual error:

[Report Only / Blocked] Refused to send form data to 'https://oauth-redirect.googleusercontent.com'
Directive 'form-action' violated from Content-Security-Policy

Kilo investigated the repository. While app/api/oauth/authorize/route.ts attempted to set route-level CSP headers, we ran into a subtle Next.js architectural quirk: global headers defined in next.config.ts completely overwrite per-route headers. The global policy had allowlisted Claude and ChatGPT origins, but Google's OAuth relay had never been added.

Round 3 — The Chrome form-POST 302 abort trap

Kilo allowlisted Google's origin in next.config.ts, ran local tests, and deployed to our staging VPS. We re-tested with anticipation.

Yet Hermes reported failure again: still net::ERR_ABORTED.

Hermes ran a controlled experiment: pasting the minted authorization URL directly into the browser bar completed the OAuth handshake cleanly. But submitting through an HTML <form method="POST"> was being actively aborted by Chrome during the cross-origin 302 redirection. Chrome's modern navigation engine treats cross-origin 302 redirects following a form POST as hazardous and kills them outright.

Round 4 — Architectural pivot and catching the casing bug

With the root cause proven, Kilo eliminated the HTML form element entirely. Clicking "Approve" was refactored to execute a same-origin JavaScript fetch() request with Accept: application/json. The server responds with 200 OK { redirect: "..." }, and the browser navigates cleanly via window.location.assign().

Round 5 — Full staging verification & production pass

Hermes executed an autonomous one-click verification run on our staging environment: Consent Modal → same-origin fetch → location.assign → Google relay → Gemini auth_complete → Connected (32 actions enumerated).

With staging completely green, Kilo took an automated PostgreSQL snapshot (pre_gemini_mcp_promote.sql.gz), triggered the production deployment gate, and tasked Hermes with live production verification. Hermes confirmed the production pass live, verified all 32 tools synced, and automatically shut down Chrome's remote debugging socket.

Surgical code refactoring

1. Global Content Security Policy (next.config.ts)

headers: [
  {
    key: "Content-Security-Policy",
    value: [
      "default-src 'self';",
-     "form-action 'self' https://claude.ai https://chatgpt.com;",
+     "form-action 'self' https://claude.ai https://chatgpt.com https://oauth-redirect.googleusercontent.com;",
      "frame-ancestors 'none';"
    ].join(" ")
  }
]

2. Architecture Refactor: Form POST → Client Fetch (consent-page.ts)

// BEFORE: Native Form POST (Aborted by Chrome during 302 cross-origin redirect)
<form method="POST" action="/api/oauth/authorize">
  <input type="hidden" name="client_id" value="..." />
  <button type="submit" name="action" value="approve">Approve</button>
</form>

// AFTER: Dual-mode JSON response with client location.assign()
async function handleDecision(decision) {
  const res = await fetch('/api/oauth/authorize', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'Accept': 'application/json' },
    body: JSON.stringify({ decision, client_id: clientId, redirect_uri: redirectUri })
  });
  const { redirect } = await res.json();
  if (redirect) window.location.assign(redirect);
}

Lone agent vs. Herdr heterogeneous fleet