How Knoxx Foods Built the Operational Foundations for AI
How Knoxx Foods built the operational foundations that make AI actually useful.
Stop Troubleshooting your Zaps Manually. Like an Animal.
An autonomous system that uses Notion Workers and a Claude agent to automatically detect, investigate, and fix bugs in Zapier workflows.
The Problem
Every Zapier user knows the feeling. You get an email about a failed run. You click through to the dashboard, open the run history, and start clicking step by step to figure out what went wrong.
The error message is usually something like "Step exhausted all retry attempts." It tells you something failed, but not why. The actual cause is buried deeper in the run's operation journal, which you have to dig out manually.
If you run dozens of Zaps (and at workFlowers, we run a lot), this adds up. You could spend twenty minutes on a single error before you've even written a fix.
The Idea
I've been pushing Zapier and Notion together in ways I wouldn't have imagined a few months ago. My latest creation: a Claude agent running in Notion fixes bugs in my Zapier workflows, on its own, in the background.
When a Zap errors out, a Notion Worker catches it, pulls the error data, and logs a ticket in a Notion database. It dedupes, so I don't get flooded with multiple tickets for the same underlying issue.
Then the Claude agent takes over. It reads the error, digs through the run history, checks the code in GitHub, compares workflow versions, and figures out what went wrong. If the bug's already been fixed, it says so. If not, it writes the fix, opens a pull request, and pings me to review.
Once I approve, it publishes the change directly to Zapier.
The Architecture
The system has three parts. I can't share the full build details yet (more on that below), but here's what I can show.
1. A Notion Worker catches every failure
When a Zapier workflow errors out, a Notion Worker pulls in the error data: the error message, the failing step, the workflow ID, the run ID. It creates a ticket in a dedicated error triage database.
It's smart enough to dedupe. Instead of creating a new ticket for every failed run, it groups failures by error signature and stamps an occurrence count. Five runs failing the same way get one ticket with "Occurrences: 5", not five tickets.
2. A “Zapier OS” database holds everything the agent needs
The triage database is part of a larger system I call my Zapier OS. It's a set of linked Notion databases that track every Zap, every run, and every error ticket.
- Each Zap record carries metadata like the apps used, and the number of steps in the workflow, and a link to the code in Github, along with detailed documentation of how it works
- Each run record carries its status, duration, operations, and error output (if any)
- Each triage ticket links back to the Zap and to every run that hit the same error
This means the agent doesn't need to go hunting for context. It opens a ticket and immediately sees which Zap failed, which runs share the error, where the code lives, and what version was running when things broke.
3. A custom agent investigates and proposes fixes
When I'm ready to triage a ticket, I set its status to "Ready for Claude". That triggers the agent, and this is where things really get fun.
The Claude agent reads the error message, then follows the links. It uses Zapier MCP connections to pull the full run journal for each failed run, which is where the actual cause lives.
It then checks the GitHub repository where the Zapier SDK workflow code is managed. It compares the version that was running when the error occurred against the version that's live now, to see if the bug has already been fixed.
Then it classifies the error. Is it a code defect? A data condition the code should handle but doesn't? A configuration problem outside the code? Transient infrastructure noise? The classification matters, because only the first one warrants a code change.
If the bug is already fixed, it says so and hands the ticket back. If not, it rewrites the code, opens a pull request, and updates the ticket status to "Ready for human review", which sends me a notification.
The Real Bug
I set up the triage system to test it on a bug I thought I'd already fixed. The error was a StepExhaustedError in a step called "update-contact-record". Five runs had failed with the same signature.
I triggered the agent expecting it to confirm the fix was already live. Instead, it dug into the run journals and found two distinct root causes hiding behind one error message.
The first was a configuration problem: the wrong Notion connection was bound to the Zap, so every write failed because the target database wasn't shared with that connection. That one I had already fixed.
The second was something I hadn't noticed. Three of the five failures were on test contacts that had been archived in Notion between the time the webhook fired and the time the write step executed. The Notion API rejects writes to archived pages with a hard error, and the Zap's retry loop burned through five attempts on each one before giving up. The fix was a guard: catch the archived-page error and skip gracefully instead of retrying.
The agent wrote the fix, opened a pull request, and left a detailed explanation of both root causes in the ticket. I reviewed the PR, approved it, and told the agent to publish the new version to Zapier.
It found and fixed a bug I'd missed, while I got on with my day.
The video below shows the whole thing running end to end:
The Safety Design
The agent can investigate and propose, but it cannot publish to Zapier without explicit human approval.
The status flow keeps a person at every critical decision point. A ticket starts as
Untriaged. When I set it to Ready for Claude, the agent runs. When it's done, it sets the status to Ready for human review and I get a notification. I review the PR, and only if I'm happy with it do I tell the agent, in the conversation, to go ahead and publish.The agent opens PRs as drafts. It explains its reasoning in the ticket body: what the journal said, which classification it reached, what it changed, and what it didn't verify. It's accurate over reassuring; if the root cause is uncertain, it says so.
What This Enables
When your workflows are managed as Zapier SDK code in GitHub, and your error triage is an agent that reads the code, writes fixes, and opens PRs, workflow maintenance stops being a repetitive chore.
The agent does the tedious work of reading run journals, comparing versions, classifying errors, and writing boilerplate fixes, so you can focus on deciding whether to ship.
What's Next
The build relies on some new enhancements to the Zapier SDK, which is still in beta, so I can't share the full technical walkthrough yet. A future post will cover the implementation details: how the Notion Worker is set up, how the agent's instructions are structured, how the Zapier MCP connections are wired, and how the publish-to-production flow works.
If you've been curious about trying Notion, you can start a free trial here: https://www.work.flowers/notion-builders.
Referral link; we earn a small commission if you sign up.
If you're spending more time troubleshooting Zaps than building them, get in touch!
Related Posts
What I Learned Optimising a Multi-Turn AI Agent (the Hard Way)
Lessons from building multi-turn AI agents across Zapier Agents, Notion Custom Agents, and Relevance AI — covering context window management, system prompt bloat, sub-agent trade-offs, and context rot.
Notion Custom Agents vs Zapier Agents: Which AI Agent Platform Should You Use?
Notion Custom Agents and Zapier Agents take fundamentally different approaches to AI automation. Here's where each one wins — and where it falls short.