TraptureIQ Guides Production agents
The demo works. Production is a different engineering problem.
Getting an agent to answer well is a prompt problem, and it is mostly solved by the framework. Keeping a fleet of them correct, affordable and debuggable is an operations problem, and almost nothing in the tooling landscape is shaped for it yet. These are the seven questions that arrive in roughly this order.
There is a gap between an agent that works in a notebook and an agent a business depends on, and it is not a quality gap. The demo agent and the production agent usually run the same prompt against the same model. What changes is that somebody now needs to answer questions about it, questions with numbers in them, asked by people who were not in the room when it was built.
Each of these is a measurement problem before it is an engineering one. You cannot fix the expensive branch of an agent graph without knowing which branch it is.
The seven, in the order they arrive
The demo worked. Nobody can say what it costs.
Why it happens. One question becomes many priced calls across sub-agents, and the invoice is a single number that arrives a month later.
What fixes it. Attribute spend per sub-agent, model, session and end user, from telemetry ADK already emits.
ADK agent costThe bill is double the estimate and the maths looks right.
Why it happens. Thinking tokens bill at output rates and never appear in the transcript. A measured four-call run spent 60% of its tokens there.
What fixes it. Measure cost per completed task rather than comparing published rates.
Token economicsIt answered confidently and it was wrong.
Why it happens. Nothing threw. The mistake was a routing or tool decision, one layer below where monitoring looks.
What fixes it. Read the right span layer, attribute errors to their origin, and follow the whole session rather than one turn.
ADK observabilityIt got slower and no code changed.
Why it happens. A ParallelAgent that degrades to serial returns the same answer at the same cost, three times slower, with no error.
What fixes it. Derive the graph from span timing and watch the concurrency ratio.
Agent topologyWe fixed that bug. It came back.
Why it happens. The eval suite reports a score nobody is required to act on, so regressions ship.
What fixes it. Turn the suite into a CI gate with an explicit threshold, and add every production bug as a case.
ADK evaluationChanging one sentence takes a release.
Why it happens. The prompt lives in source, so iteration and rollback both cost a full deploy.
What fixes it. Version prompts and parameters as configuration the agent resolves at runtime.
Prompt management“Tool call failed.” That is the whole error.
Why it happens. Four of the five ways an MCP call can fail happen before your tool code runs, and the agent improvises over the evidence.
What fixes it. Isolate reachability, auth, discovery and schema outside the agent loop.
MCP debuggingWhy the ADK answer is different
Most agent platforms answer these questions by asking you to install an SDK and wire it into your agent. That works, and it means the observability layer lives inside your process, on your critical path, in your dependency tree, and every agent you own has to be edited to be visible.
ADK removes the need. It already emits OpenTelemetry spans carrying token usage, hand-offs, tool calls and errors. The data exists; the only question is where it is sent. Which makes instrumenting a configuration change rather than a code change:
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://api.traptureiq.com/v1/traces" export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="https://api.traptureiq.com/v1/logs" export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=tiq_..."
Verified end to end against real Vertex AI Gemini calls on Cloud Run and on Agent Engine, deployed agent to deployed collector, correctly priced, with no edit to the agent in either case. Two boundaries worth stating plainly: this zero-code-change path is ADK-specific (other frameworks post to the ingest API and that is a code change), and adk run does not initialise OpenTelemetry at all, so it exports nothing.
A sensible order of operations
- Get traces and cost flowing. One configuration change, and it makes every later question answerable rather than theoretical.
- Declare your environment. Local versus deployed cannot be detected after the fact, set
OTEL_RESOURCE_ATTRIBUTES=deployment.environment=…on day one, or your load tests permanently pollute your production numbers. - Look at the graph before you optimise. The expensive branch is rarely the one people guess.
- Put an eval gate in CI, even a weak one. A 0.6 threshold that blocks a deploy beats a 0.9 nobody is required to read.
- Move prompts out of source. The moment iteration speed matters more than it did in week one.
Start anywhere
ADK agent cost
What a multi-agent run actually costs, and which branch spends it
Token economics
Why the thinking tokens nobody reads are the biggest line on the bill
ADK observability
The four layers a failure can hide in, and what each one answers
Agent topology
Recovering the agent graph nobody declared, and catching a serial ParallelAgent
ADK evaluation
Evals that gate a deploy instead of decorating a dashboard
Prompt management
Changing a prompt without shipping a release
MCP debugging
Why an MCP tool call fails, in the order it actually fails
ADK Changelog
Every google/adk-python release, annotated where it changes deployment behaviour
Questions people actually ask
What changes when an agent goes from prototype to production?
The questions stop being about answer quality and become operational: what does a conversation cost, which sub-agent spent it, why did this session fail without an error, did the last change regress anything, and how do I fix a prompt without a deploy. None of these are visible in a demo of a single happy path.
What is the first thing to instrument for a production ADK agent?
Cost and traces together, because ADK emits both on the same spans and both arrive from the same configuration. Cost gives you the number a budget holder asks for; traces give you the evidence for every other question that follows.
Do I need to change my agent code to get production telemetry from ADK?
No. ADK emits OpenTelemetry traces and logs from environment variables alone, so pointing the standard OTLP exporter at a collector requires no edit to agent.py. That is specific to ADK; other frameworks need an SDK or direct ingest.