EVERY ROUTE RIGHT, BOTH RUNS
The routes did not move.
All four alerts took the correct route, and the same route in both runs. The route is chosen by rules in code, so it cannot change when the model's wording does.
FLAGSHIP · AGENT WORKFLOWS ON GOOGLE ADK
Agents that get context by rule, not by guess.
We design and build agent workflows on Google's Agent Development Kit. The context each step needs is fetched by bounded, deterministic code — not chosen by the model. The agent at that step works with exactly what it was given, and its output moves to the next layer. Every step can be tested on its own, and none of it is locked to a single model.
HOW THE WORKFLOW RUNS
Fetch. Reason. Hand on.
A common way agents break in production is context: the model fetched the wrong thing, or too much of it, or decided on its own what it needed. This pattern takes that decision away from the model and gives it to code.
01 · BOUNDED FETCH
Code fetches the context, not the model.
Each step declares what it needs. A bounded script retrieves exactly that — from your APIs, databases or documents — and writes it into the workflow's state. No model decides what data it gets to see.
02 · AGENT NODE
The agent works with what it was given.
The agent at that step reasons over the context it was handed and nothing else. Its reach is set by the fetch that came before it, not by what its prompt talks it into.
03 · NEXT LAYER
Output moves forward along explicit edges.
ADK runs a workflow as a graph: each step is a node, and the edges between them are declared in code. Each result carries forward in shared state to the next layer.
04 · DECISION POINTS
Where the flow branches, the branch is explicit.
Branching lives in code you can read and test. Where a judgement is genuinely uncertain, it goes to a person rather than being guessed.
PROOF · WE BUILT ONE FIRST
Own your agent orchestration instead of renting it.
Context from every vendor you run, your rules in code, built entirely on open-source components — Google's ADK and open models — and delivered into your own repository. To show that rather than claim it, we built one: cross-vendor alert triage, running on ADK and Gemma 4 on a single machine, with no cloud account and no spend.
FETCH · CODE · IN PARALLEL
- Service catalogOwner, on-call, tier
- DeploysWhat shipped recently
- Incident managementWhat is already open
- Issue trackerWhat is already known
ASSESS · MODEL
Likely causeReads only what was fetched, and cites every source by reference
CHECK & ROUTE · CODE
Citation check, then rulesCited a source it was never given? A human takes it. Otherwise the rules pick the route.
ROUTE
- Attach to open incident
- Page the owner
- Open a ticket
- Notify on-call
- Hold for a human
| Alert | Route · both runs | Why, in code | Model's evidence | Seconds · run 1, 2 |
|---|---|---|---|---|
| checkout-api5xx error rate 7.4% | Page the owner | Tier-1, deployed 22 minutes before the alert | Same both runs | 36.5 · 32.0 |
| payments-workerp95 job latency 41s | Attach to open incident | An incident was already open | Varied | 44.9 · 88.9 |
| docs-sitep95 page load 3.8s | Open a ticket | Tier-3 at warning severity | Same both runs | 19.7 · 18.5 |
| search-indexerIndex queue backlog 12,400 | Notify on-call | No rule matched | Varied | 36.7 · 36.7 |
THE MODEL EARNED ITS PLACE
It connected two vendors' records.
On checkout-api it tied a deploy that cut the payment-token cache lifetime from 300 to 30 seconds to an open ticket reporting the token cache hit rate had dropped — the cross-vendor connection a person would otherwise make by hand.
AND IT WAS NOT ALWAYS RIGHT
Which is why it never chooses the route.
In one run it left an open incident out of its evidence; in another it said a deploy made about nine hours earlier happened "shortly before" the alert. A code check stops the model citing a source it was never given; it cannot catch a wrong statement about one it was. So the model's assessment travels with the alert as advice.
LATENCY IS THE WEAK POINT
18 to 89 seconds per alert.
Acceptable for a triage note, too slow for anything that has to act in real time. The decision step is swappable and receives only typed facts, so a faster decision engine can be measured against this baseline without touching the rest of the workflow.
The code is private and available on request — along with a walk-through of how the same workflow reads from your own systems instead of reference data.
Book a call →WHY GOOGLE ADK
A kit built for exactly this shape.
ADK is Google's framework to build, evaluate and deploy agents. Everything below is from Google's documentation or the ADK release we build on, not our marketing.
Optimized for Gemini, and documented to work with Claude, OpenAI, Gemma and open models through Ollama, vLLM and LiteLLM. Models plug in through one interface, so the workflow is not tied to a single provider.
Workflows are graphs: steps are nodes, edges and routes are declared in code, independent fetches run in parallel, and each step can carry its own retries and timeout — orchestration that does not depend on a model's choices.
Python, TypeScript, Go, Java and Kotlin. The build fits the stack your team already maintains.
Deploys to Cloud Run, Google Kubernetes Engine, or Google's managed Agent Runtime.
Multi-turn evaluation datasets, run locally from the command line or a dev UI, so a change to a prompt or a model is tested before it ships.
Logging, metrics and traces are part of the kit, and MCP tools are supported natively — so every tool call can be recorded if you need an evidence trail.
WHAT YOU GET
A build you own, and the means to change it safely.
Scoped on the call to the workflow you actually need. Delivered into your repository and your cloud, with nothing that stops working when the engagement ends.
01
Workflow design
The steps, the context each step is allowed to see, where the flow branches, and who reviews the calls a machine should not make alone.
02
A working build
An ADK workflow in your repository, deployed to your Google Cloud project. Code you own, on infrastructure you control.
03
An evaluation suite
ADK evaluation datasets for the paths that matter, so the next change is measured rather than hoped about.
04
Observability
Logging, metrics and traces wired in from the start. MCP tool calls recorded with Witness if you want a tamper-evident record.
05
Handover
A runbook and a readout with the team that will run it after we leave.
WHO IT'S FOR
Teams past the demo.
For engineering, platform and product leaders who have seen what an agent can do and now need it to do the same thing reliably.
YOU ARE BUILDING
Agents that touch real systems, and they need to behave the same way on the hundredth run as on the first.
YOU HAVE
A prototype that works in a demo and loses the plot in production — usually because the model is choosing its own context.
YOU WANT
A build your security and platform teams can review line by line, rather than a black box with a prompt inside.
ALREADY RUNNING AGENTS?
Start with the evidence.
If agents are already acting in your estate, an Agent Flight Check first shows what they actually do — and gives the new build a baseline to measure itself against.
See the Agent Flight Check →SCOPED ON THE CALL · YOUR REPO · YOUR CLOUD
Tell us the workflow.
Thirty minutes to walk through what the agent needs to do, what it should be allowed to see, and whether ADK is the right foundation for it. If it isn't, we'll say so on the call.