When AI Mistakes Have Dollar Signs: Ramp's Case for Background Agents
Ramp's production-finance constraints produce the same architectural conclusions as joelclaw's Inngest-backed agent loops — durable async background execution over interactive chat
Ramp’s engineering blog routinely publishes substantial technical work, and their piece on building a background agent deserves attention in context: Ramp processes real corporate spend, which means their agent failures have dollar signs attached. When the stakes are that concrete, the architectural choices stop being preferences and start being requirements.
The background agent model — async, durable, observable workers rather than interactive chatbots — is the right primitive for automation that has consequences. A chatbot can mis-categorize an expense and you shrug. An automated agent mis-categorizing thousands of transactions at scale across thousands of companies is a different problem entirely. You need idempotency, retry semantics, human-in-the-loop pause points, and an audit trail that explains every decision. Interactive chat gives you none of that. Background execution gives you all of it.
This is the same pattern behind joelclaw’s Inngest-backed agent loops — each step is independently retried, the event log is the source of truth, and k8s worker pods handle execution without holding a user session open. The difference between Ramp’s implementation and a smaller personal setup is mostly scale and the specificity of the failure modes, not the underlying architecture. Durable workflow engines like Inngest, Temporal, and Restate all converge on the same answer: step-wise execution with memoization and observable state.
The signal worth filing: a company processing billions in transactions came to the same conclusion about agent execution that shows up in serious infrastructure projects — async durable workers, not chat. When production pressure and real money validate an architectural pattern, that’s worth paying attention to.
Key Ideas
- Chat is the wrong primitive for automation — interactive agents are great for exploration, terrible for reliable background execution with dollar costs attached
- Durability requirements emerge from consequence — idempotency, retry semantics, and audit trails aren’t nice-to-haves when agents touch financial systems
- Pause/resume/inspect semantics become first-class requirements when agents have real-world effects that can’t be easily undone
- Background execution decouples agent work from user sessions — a worker that runs for 10 minutes doesn’t need a browser tab open
- Human-in-the-loop at decision boundaries — the right architecture lets you pause at consequential moments, not just at the start or end
- Step-based execution as the shared primitive — Inngest steps, Temporal activities, and similar systems all solve the same durability problem
- Financial automation as the acid test for agent reliability — the constraints force correctness that less-consequential systems can skip