My CloudOps agent answered a simple question in 8.5 seconds. After I switched off the services it did not need, the same question took 1.8 seconds.
I asked:
Is production healthy?
The Lambda that answers it took about a tenth of a second in the slow run. The rest was the model, working from far more context than the question needed.
This is the first part of Stage 5 in my AgentCore series: follow one question from the prompt to the Lambda and back, and read the evidence in a trace. The lab uses synthetic data, one Harness, one Gateway, one deployment status Lambda, and Amazon Nova Micro.
A Guess Before the Run
In the earlier stages I trusted the agent because I saw the tool result in the terminal. A terminal shows the answer. It does not show where the time went.
Before I ran anything, I wrote down a guess:
The model will be slower than the tool, because the Lambda returns a small result quickly.
The CLI Could Not Show Me the Trace
I tried the terminal first:
agentcore traces list
Error: No runtimes defined in agentcore.json
My agent is declared as a Harness, and these commands only look for Runtimes. The traces still exist, so I read them in the CloudWatch console under GenAI Observability.
One account setting has to be on first: CloudWatch Transaction Search. Without it, the spans arrive but you cannot search them as traces.
Run One: Every Service On
My Harness had three things switched on from earlier stages: the Gateway tool, the Code Interpreter tool and managed memory. The trace had 23 spans.
| Step | Time |
|---|---|
| The whole request | 8.5 s |
| Memory lookup | 228 ms |
| First model call, which chooses the health tool | 771 ms |
| The health tool call | 105 ms |
| Second model call, which writes the answer | 6.1 s |
The two model calls took about 6.9 seconds, roughly 81 percent of the request. The tool took about 1 percent. My guess was right.
What surprised me was the second model call. It wrote about 1,500 tokens for a question that needed a short status. The model had added a Python analysis of a deployment history CSV that I never asked for. Across the request it read 22,368 tokens and wrote 1,632.
Run Two: Only the Gateway Tool
I removed Code Interpreter and memory, then asked the same question. The trace had 11 spans.
| Every service on | Gateway tool only | |
|---|---|---|
| Whole request | 8.5 s | 1.8 s |
| Model calls | 6.9 s | 1.1 s |
| Health tool | 0.1 s | 0.4 s |
| Memory lookup | 0.23 s | none |
| Tokens read | 22,368 | 2,269 |
| Tokens written | 1,632 | 165 |
| Spans | 23 | 11 |
The answer was the plain health status: service, version, instance counts and no alarms. The model was still the larger share, about 62 percent, but the tool grew from about 1 percent to about 22 percent because everything around it shrank. The tool time moved between runs, and I do not read much into that.
Finding the Lambda in the Trace
I also wanted to see the Lambda's own log for the same request. It prints a request ID and how long it ran. I looked for that ID in the Gateway span, but it was not there.
What did match was the trace ID, printed on the next line. Remove the leading 1 and the dashes, and it is the same trace ID I saw in CloudWatch. That is how I linked the two.
The Lambda ran for about 17 milliseconds. The whole Gateway call took 104. The rest is most likely the Gateway and the network. The trace does not break that part out.
What This Shows
Switching off Code Interpreter and memory took the same question from 8.5 seconds to 1.8. The model still did most of the work, but the extra context was costing real time.
This is one question measured twice, so I am not calling it a benchmark. I removed both services together, so the next test is to switch them off one at a time and see which one mattered most.
Three habits I am keeping: write a guess before I look, read the trace before I trust the answer, and check what my agent carries that the question does not need.
What Comes Next
In the next part I break the agent on purpose. I will run twelve failure cases against the same question and use traces to check what the agent said each time.
Top comments (1)
Writing down the guess before running the trace is the discipline most people skip, it turns the trace into a verdict instead of a story. Dropping from 8.5s to 1.8s by switching off unused services shows how much of the latency was context the question never needed.