Portkey observes.
Runback re-executes.
Portkey is an AI gateway — unified routing across providers, with caching, fallbacks, guardrails, and observability on the request path. It's built for production reliability at the request layer, not for reconstructing or re-executing what an agent decided across a multi-step run.
| Capability | Portkey | Runback | Note |
|---|---|---|---|
| Multi-provider request routing, caching, fallbacks | ✓ | ✗ | Portkey speciality — not Runback's scope |
| Guardrails on requests/responses | ✓ | partial | Runback enforces policy on tool calls, not the gateway layer |
| Read and search traces | ✓ | ✓ | |
| Multi-step tool-call capture and causal links | partial | ✓ | Gateway sees the outer call, not the full agent loop |
| Re-execute any step from captured inputs | ✗ | ✓ | |
| CI release gate | ✗ | ✓ | |
| Signed, tamper-evident audit export | ✗ | ✓ | |
| Regulatory mappings (EU AI Act · CPS 230 · NIST) | ✗ | ✓ |
Most teams use both — Portkey for day-to-day trace browsing, Runback for incident replay, CI gating, and the compliance artifact. The two don't overlap until the moment an agent misbehaves in production and someone asks you to prove it.
Try the replay on a real incident.
No signup. Walk a failing production run step by step and see what the model saw.