How I built Relay: An AST-based latency auditor for Python AI agents

I kept running into the same problem building AI agents.
They were slow and I had no idea why.

No obvious errors, logs looked fine, but requests were taking
way longer than they should. Turns out the codebase was full
of async anti-patterns. Missing awaits, sequential LLM calls
that could've been parallel, blocking I/O hiding inside async
functions.

So I built Relay.

It uses AST analysis to scan your agent codebase and find
exactly these spots. Not just flagging them, it suggests
fixes too. And since it runs as an MCP server, it works
directly inside Claude Code. No log files, no context switching.

how it works

• scans your Python codebase statically
• finds async bottlenecks (missing awaits, unparallelized calls, etc)
• surfaces fixes inline in your editor

try it

pip install relay-arclat

or check it out here

built by Arclat, a studio making developer tools for AI agent teams.

Comments

[Mads Hansen]

Useful layer, especially if the findings are treated as hypotheses rather than automatic rewrites. For agent code, “can run concurrently” also depends on tool side effects, shared state, provider rate limits, and cancellation semantics—not only data dependencies visible in the AST. I’d make each recommendation include its evidence and confidence: resolved callable/type, blocking API matched, dependency path, expected concurrency gain, and why ordering appears unnecessary. Then validate high-confidence fixes with a trace showing wall time, queue time, provider latency, and event-loop lag before and after. Tests should cover partial failure and cancellation too: replacing sequential awaits with gather can make latency better while leaving orphaned writes or changing which exception becomes visible.

[Seven]

Static AST for agent latency is the right layer — runtime profilers miss the "looks fine in logs" class of bugs (missing await, sequential LLM calls that could gather, blocking I/O inside async).

MCP-in-editor is the distribution win. Curious whether you also flag intentional sequential chains (tool B needs tool A's output) vs true anti-patterns, so the suggestions don't push unsafe parallelization.