Debug a slow API in an AI application: measure before changing infrastructure

A worked example: where the task becomes difficult

A fictional dashboard takes eight seconds to load a small summary. The handler fetches full records, calls a model and then aggregates data that could have been computed earlier. Another instance is delayed only during startup. Give the agent timestamps and payload sizes from controlled requests so it can identify actual work instead of attributing every delay to a slow database.

Decisions to make before implementation

Choose a latency target tied to the user task and specify percentile or distribution rather than only an average. Track payload volume alongside duration. Instrument stages with request references but avoid logging full personal records. Consider caching only when freshness and access boundaries allow it. A cached account summary must not be reused across identities because the route path is the same.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Measure several controlled requests, including cold and warm behavior.
• Add narrow timing spans around the actual work stages.
• Reduce redundant work or returned fields at the supported bottleneck.
• Compare latency and correctness using the same workload after the change.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Measure the dashboard summary endpoint by stage using redacted request references. Keep its approved result contract unchanged. Identify redundant queries, payload size and external waits. Apply one supported optimization, compare the same workload and report timings and error behavior. Do not cache private results across users or add unlimited retries.

Failure modes that an attractive preview can hide

A faster response that returns incomplete totals is not an optimization. Keep the result contract fixed during comparison. Parallelizing every call can overload a downstream service or violate ordering. Unbounded retries can amplify latency and usage. Record failures and limit retries according to the operation’s safety rather than treating delay as permission to repeat a write.

Technical references: Chrome: console features reference

Acceptance checks and the evidence to retain

Provide before/after measurements, workload assumptions, changed stage and correctness checks. State whether measurements were local, staging or production.

Specific answers

Common questions