I ve been thinking about this with agent harnesses. A lot of the work between LLM calls is just deciding what happens next: retry, switch tools, pick another model, or stop. Some of these decisions seem simple enough for a small model or even normal code. But getting one wrong can mess up the entire run. Would it make sense to use a small, fast model for these Type 1 decisions and save the bigger reasoning model for the hard stuff? Where would you draw the line? I d be interested in how people are handling this in their own setups.
Single agents are manageable. The moment agents start handing work to each other, failures stop being traceable. One bad output becomes the next agent s trusted input, and the break shows up far from where it started. If you ve got a multi-agent system running reliably in production, what made it work? Narrower tool scopes, strict handoff rules, better tracing, fewer agents?
Month a partner platform changed their API payload structure without telling anyone turning a regular user ID field into a nested object. That small change broke three days of data across our CRM and email marketing systems.
Of going through thousands of bad records in the database one by one we created a simple validation middleware between our webhook receiver and our internal processing queue. Every incoming payload now goes through a schema check before it reaches any business logic.
If a field does not match the schema we expect the middleware moves the payload to an error log table. Sends a message to our developer channel on Slack right away. This small change has saved us a lot of time that we would have spent fixing data
What error handling strategies do you use to keep your automated workflows safe, from API changes?
