In my previous post, I shared how agentic loops can eliminate rework in customer operations. Today, I’m pulling back the curtain on the actual implementation.
For the small business client I mentioned, the goal was clear: automate sub-$50 refunds so their team could stop acting as human routers and start adding real value. But automation isn’t just about speed, it’s about reliability. If the system breaks, it needs to be easy to fix without digging through code logs.
Here is the A-to-Z process and the tool stack we used to build a “hands-off” system that still keeps Accounting happy.
The “Stateful” Philosophy
Most automation fails because it’s linear. If Step 3 crashes, the whole process dies. To make this hands-off, we built a Stateful Orchestration model.
Instead of just “running” a task, the system maintains a status for every single request (e.g.,
NEW, VERIFIED, REFUND_PROCESSED, FAILED). If something stops, it stays in that state until it’s fixed or retried. This turns a fragile script into a resilient worker.The Tech Stack
We avoided expensive enterprise suites in favor of a modular “Lego block” approach:
- The Orchestrator (The Manager): n8n
- Why: It manages the flow between tools. If an API call fails, n8n doesn’t crash; it updates the status and waits for a retry signal.
- The Brain (LLM): OpenAI GPT-4o
- Why: It excels at reading messy customer emails and extracting structured data like Order IDs and refund amounts.
- The Memory (The Ledger): Airtable
- Why: It acts as the single source of truth. Every refund request gets a row here. If a human needs to intervene, they just update a cell in Airtable, and the system picks it back up. We initially considered using MySQL as the backend DB and hosting the DB on their server and build a front-end for their team to access the data — but that would have entailed more effort, and the client wanted to use the fastest route possible. We will re-evaluate MySQL and a custom front-end at a future time.
- The Reporter: Looker Studio (now called DataStudio)
- Why: It connects directly to Airtable to generate daily PDF/CSV reports for Accounting, ensuring total transparency.
The A-to-Z Process Flow
1. Ingestion & State Creation (Observe)
When a customer emails
support@company.com with “refund,” n8n detects the keyword and creates a new record in Airtable with the status NEW_REQUEST. This ensures no request is ever lost, even if the AI is busy.2. The Verification Loop (Reason & Reflect)
The agent pulls the
NEW_REQUEST record. It uses OpenAI to extract the Order ID and Amount, then checks the CRM.- If successful: It updates the Airtable status to
VERIFIED. - If it fails (e.g., API timeout): It updates the status to
RETRY_PENDINGand automatically tries again in 15 minutes. - If it’s a critical error (e.g., Order not found): It flags the record as
NEEDS_HUMAN_REVIEWand sends a Slack alert.
3. Execution & Self-Correction (Act)
The agent scans Airtable for all
VERIFIED records. It calls the Stripe API to process the refund.- Success: Updates the status to
REFUND_COMPLETEand logs the Transaction ID. - Failure: Updates the status to
PAYMENT_FAILEDand logs the specific error code.
4. The “Easy Restart” Mechanism
This is the key to making it hands-off. We created a simple Airtable View called “Needs Attention.” If a refund gets stuck, a manager opens Airtable, sees the error message in a cell, fixes the issue (like updating a card number), and changes the status back to
VERIFIED. The Orchestrator is watching that view; as soon as the status changes, it picks up the task and finishes the loop. No code deployment required.5. Automated Accounting Reporting
At 5:00 PM daily, a workflow queries Airtable for all
REFUND_COMPLETE records. It generates a summary (Total Refunded, Count, Transaction IDs) and emails it to the Accounting distribution list. A live Looker Studio dashboard provides real-time visibility into “Refunds Processed by Agent” vs. “Refunds Flagged for Review.”Why This Works for Ops Leaders
- Visibility: You aren’t guessing if the AI is working. You have a live “dashboard” showing the health of every transaction.
- Resilience: The “Retry” logic means temporary glitches don’t kill the process. The agent just waits and tries again.
- Auditability: Accounting doesn’t need to trust the AI; they trust the Ledger. Every penny is accounted for with a timestamp and a Transaction ID.
Can you spot the deficiencies in this process? I hope they are glaring.
This architecture gets the refund processed, but it doesn’t yet guarantee that the refund is safe, auditable, or scalable. There is no event log, no duplicate prevention, no fraud checks, and no disaster recovery plan. Deploying this as-is would be like driving a car without brakes because the engine runs perfectly.
Next week, in Part 3, I will provide the complete checklist of 25 critical questions we had to answer before putting this process into production, along with the finalized state machine that accounts for every edge case. That’s where the real engineering begins.
About The Author
