Live output · Managed Agents API (preview)

Tickets, allocated.

A real managed agent — agents.create → interactions.create — fetched the Gemini API forum by itself, triaged the most recent topics, and routed each to its owner per the AIS/API team structure. Each person's inbox below, as it would arrive in GChat.

Inboxes

Verified, not asserted

every run scored vs an independent forum fetch + a hand-labeled golden set (labels pending Ali's validation)

Dogfooding log · what building this taught us

Build & findings.

Built end-to-end through the public API (no GUI, deliberately) so every friction became data. Full step-by-step log in the repo (journal/PROCESS-LOG.md, E001→); highlights below.

Q&A — asked by the API team, answered here

live thread, 2026-08-05 · this page is the conversation medium

Q (Ali): "You seem to be using the old SDK (1.47.0) — curious why it didn't pick up the latest."A — you were right; corrected same-day (E022). Our venv used Python 3.9, and pip silently resolves the newest compatible version — 1.47.0 — with no signal that 2.x exists; even pip index versions reports 1.47.0 as "latest" on that interpreter. Re-tested on Python 3.13: google-genai 2.16.0 has agents + interactions. The durable finding: silent version-capping — client.agents just doesn't exist, nothing points at the Python version. Suggested fix: docs state "requires google-genai ≥ 2.x (Python ≥ 3.10+)"; SDK emits a version hint.

Q (Ali): "It does have max_output_tokens which does the same thing (as budget caps)."A — acknowledged and refined (E023). max_output_tokens caps output per response. But our measured spend is majority input+intermediate: run 2 = 132,549 in vs 12,189 out ($0.040 vs $0.030 on flash-lite) — so an output cap governs <50% of cost. And nothing caps cumulative spend: a daily trigger × uncapped runs is the real exposure. Sharpened ask: a per-agent / per-trigger spend ceiling, not a per-response token knob.

Q (Ali): "How did it build it — the skill, the docs, or just web search?"A — docs page + live probing; no pre-existing skill. Claude (Claude Code) built it from: (1) one fetch of the public docs (custom-agents + pricing pages); (2) SDK surface introspection (discovered the JS SDK's experimental agents/interactions/triggers/webhooks by listing client properties); (3) error-message archaeology — the API's 400s were the real documentation (snake_case, required environment, the whole trigger schema: schedule → time_zone → interaction); (4) web search only for background research, not for the build. No Managed-Agents skill existed to use — writing one from this journal would be the natural next artifact.

What we built

portable — recreate with any key: node agent/create_agent.mjs

1 · Agentais-forum-triage-dev on antigravity-preview-05-2026 (flash-lite for dev). Instructions: fetch the forum yourself → severity rubric (P0–P3) → routing table (8 areas, PM/TL/DevX from the team-structure doc) → strict ticket JSON.

2 · Runone directive per interaction ("fetch + triage the N most recent"); the agent does the work with its own tools (url_context / code_execution) in a fresh sandbox fork.

3 · Verifyevery run scored: reality check vs an independent fetch (anti-hallucination) + golden-set routing/severity accuracy + schema completeness. Cost logged per run; $10 hard cap enforced client-side.

4 · Delivertickets grouped per owner — this page (GChat simulated). Swap for a GChat webhook inside Google; nothing else changes.

Managed Agents API — the specs as lived

preview · docs at ai.google.dev/gemini-api/docs/custom-agents

Create

client.agents.create({ id, base_agent: "antigravity-preview-05-2026", agent_config: {type:"antigravity", model}, system_instruction })

fields are snake_case — camelCase → 400 (with a helpful "did you mean" suggestion). Models: 3.6-flash · 3.5-flash · 3.5-flash-lite; model is fixed per named agent.

Runclient.interactions.create({ agent, input, environment: "remote" })environment is required (not obvious from the SDK). Each interaction forks the base environment — every run starts clean. Multi-turn via previous_interaction_id.

Toolscode_execution · google_search · url_context (+ mcp_server · function · file_search)default toolkit; our agent uses them to fetch Discourse JSON itself.

Usagetotal_input_tokens · total_output_tokens · total_tokens (+ per-modality, cached, tool, thought)present on every interaction response — under names the docs don't yet list. Billing = standard token rates incl. agentic-loop intermediates; environment compute free in preview.

Limitsno versioning · no rollback · no subagent nesting · ≤1000 agentswe git-version the agent definition ourselves.

What we learned

headline findings from the journal — each is a DevX or builder-GUI requirement

Silent SDK version-capping (corrected by Ali, same day).The Python SDK ≥2.x does have the agents surface. But on Python 3.9, pip silently installs 1.47.0 — the newest compatible — and client.agents simply doesn't exist: no error, no hint that the interpreter is the cap. Even pip index versions reports 1.47.0 as "latest" there. DevX fix: docs state "requires google-genai ≥ 2.x (Python ≥ 3.10+)"; SDK emits a version hint. Original wrong framing preserved in the log (E009 → corrected E022) — the correction loop working is itself a finding.

The agent must do the work — the builder just configures.Our first design pre-fetched the forum and spoon-fed the agent. Wrong: the agent fetches with its own tools; the builder's fetch becomes the verifier's independent ground truth. A builder GUI should default to agent-side data acquisition.

Cost is real but invisible — and only half-cappable.Usage fields exist per interaction but nothing surfaces them. max_output_tokens exists (Ali's point) but measured spend is majority input+intermediate (132,549 in vs 12,189 out on run 2), and nothing caps cumulative spend per agent or per trigger — a daily trigger × uncapped runs is the real exposure. Ask: a per-agent/per-trigger spend ceiling.

Small API frictions, excellent error messages.snake_case-only params, required environment, key onboarding with zero validation feedback (3 attempts). Each error message suggested its own fix — the best DevX moment of the build.

Triage quality is high even on the smallest model.flash-lite: 10/10 real topics, 89% routing accuracy, 9/9 severity — with sensible P1 calls ($13,946 billing dispute → Billing PM, 5-hour 503 → Platform). The golden-set labels now await Ali's corrections — that loop is the eval flywheel.

The full log

every step · challenge · GUI implication — auto-synced from journal/PROCESS-LOG.md

The agent, inspectable

System.

Everything about this agent: status, the exact configuration it runs with, every run and its cost, and how to recreate it in your own project with your own key.

Status

what is done · what is next

Agent configuration

System instruction — AGENTS.md (verbatim, what the agent actually runs on)

Routing table — 8 areas · PM / TL / DevX (from the team-structure doc)

Schedule

native triggers API — discovered via error-message archaeology

Runs

every interaction, measured — usage fields from the API response

Run it yourself

portable — your key, your project, same agent

# 1. get the repo (agent definition + scripts + verifier + journal)
# 2. your key from aistudio.google.com/apikey:
echo "GEMINI_API_KEY=AIza..." > .env
npm install                      # @google/genai ≥ 2.15 (JS SDK — Python SDK lacks the agents surface)
node agent/create_agent.mjs      # creates the agent in YOUR project (flash-lite dev)
node agent/run_triage.mjs --n 10 # agent fetches the forum itself + triages; cost logged per run
node agent/eval_triage.mjs       # verifier: reality check + golden-set accuracy
node webapp/build_data.mjs       # refresh this page from your latest run
# inside Google: swap this page for a GChat webhook — the ticket JSON is the contract