How I built an AI workflow with preview, approval, and monitoring
Using one AI agent works for small tasks.
But once there are multiple steps — building, checking, updating, monitoring — things start to fall apart.
So, you need to structure AI into a system that can handle it.
Here’s how to set that up.
What this system does
This system takes a request and moves it through a structured process that:
- Interprets what needs to change
- Generates a proposed update
- Lets you preview the result
- Requires approval before it goes live
- Monitors the result afterward
The workflow
Request → Plan → Change → Preview → Approve → Monitor
Each step does one job. Together, they run with minimal manual work.
Example
We’ll use one example the whole way through: Update contact page copy (e.g., change or rewrite the text)
Tools
- Jotform → collect requests and run approvals
- n8n → run the workflow
- GitHub → store and update files
- Vercel → preview and deploy
- Claude (through n8n) → generate/rewrite the content
Step 1 — Create the trigger (Jotform)
Set up a form in Jotform.
Add:
- Page/file (Short text)
- What should change (Long text)
- Definition of done (Long text)
- Risk (Dropdown: Low / Medium / High)
Click Publish
Result: This form collects change requests (like changing text on a page). Once published, each submission triggers the workflow.
Step 2 — Create the workflow in n8n
Open n8n and click Create Workflow
Add your first node: Jotform Trigger
- Connect your Jotform account
- Select your form
- Click Execute Node
- Submit a test form
You should now see the form data inside n8n.
This is your trigger.
Result: Each submission now enters n8n and starts the workflow.
Step 3 — Planner (n8n model node)
- Click +
- Add a model (OpenAI, Claude, etc.)
- Connect your model
Paste:
Pick ONE file to change.
Return:
- file path
- branch name
- short summary
Only choose content files.
Connect data
Map:
In your AI node, use values from the Jotform Trigger node as inputs.
Build your prompt like this:
Update the file based on this request:
What should change:
{What should change}
Definition of done:
{Definition of done}
Risk level:
{Risk level}
Keep the structure the same. Only change what is needed.
How to insert those fields in n8n
- Click inside the prompt box
- Click “Add Expression”
- Select a field (e.g. “What should change”)
- It will appear in your prompt
Repeat for the other fields.
Test
Click Execute Node
You should see:
- File path
- Branch name
- Summary
Result: The AI decides what file to change and how to change it.
Step 4 — Add the builder (GitHub)
Add node: GitHub → Get File
Set:
- Repository
- File path (from planner)
This fetches the current version of the file.
Add next node: AI (text generation)
Paste this (or similar):
Update this file based on the request.
Keep the structure the same.
Only change what is needed.
Add next node: GitHub → Edit File
Set
In the GitHub → Edit File node:
-
Click into File path
- Click Add Expression
- Select the file path from the planner (Step 3)
-
Click into Branch name
- Click Add Expression
- Select the branch name from the planner (Step 3)
-
Click into Content
- Click Add Expression
- Select the output from the AI node
Test
Run workflow
Result: A new version of the file (with the updated content) is saved in your repository.
This is the step where the system makes a real change.
Step 5 — Preview (Vercel)
Set this up once in Vercel
- Click New Project
- Import your GitHub repo
- Deploy
Now, every time your workflow creates or updates a branch in GitHub:
- Vercel automatically builds that version of your project
- It creates a preview URL for that branch
When that branch is later merged:
- Vercel deploys it as the live version
Result: Each change can be viewed and checked before it goes live.
Step 6 — Review (manual approval with Jotform)
Do not automate this.
Create a second form in Jotform:
- Task
- Preview link
- Approve / Reject
- Notes
Flow: n8n sends the preview link → you check → you approve or reject
Result: You review each change before it goes live.
This is your quality control step.
Step 7 — Monitor (GitHub)
In GitHub: Click Add file → Create new file
.github/workflows/check.yml
Paste this:
name: Check site
on:
schedule:
- cron: "0 0 * * *"
jobs:
check:
runs-on: ubuntu-latest
steps:
- run: curl -f https://your-site.vercel.app
Commit
Result: The system automatically checks that your site is still working after changes.
This is the monitor agent.
That’s it.
You now have a controlled system for making changes safely, from request to verification.
Each step is separate and clearly defined — that’s what makes it reliable.
The preview-and-approve gate is what separates 'AI helping' from 'AI breaking production on a Tuesday morning'. We run a similar shape at SocialPost.ai for AI-generated content that touches a customer's brand: model proposes, human sees a diff, one click approves or rewrites. The unsung hero in your workflow is step 6, monitoring. Most teams ship the agent and never instrument it. Six weeks later they cannot tell if the model is drifting because nobody is watching the output. Quick question: what is your rollback path when monitoring catches a regression after deploy?
Nice breakdown. I built something similar for Kryva (B2B SaaS) but kept everything inside Claude tool-use directly, no n8n orchestration. The human-in-the-loop checkpoint becomes a tool call that returns control to the user, which removes the need for an external approval UI. Tradeoff: tighter feedback loop but less observability than n8n's flow view. For non-technical approvers your Jotform-based approach is the right call. For dev-facing workflows, native tool-use is faster to ship and easier to debug. Have you tried Claude's MCP servers (file/git) for the GitHub step instead of n8n nodes? I've found the diff quality is higher when Claude has the full repo context.
Really like the preview → approval flow you've built. I've been working on something with a similar pattern for freelancers — after a client pays, AI drafts a review for them to preview and approve before it goes public. The "human-in-the-loop" step before publishing makes a huge difference in trust. One thing I learned: keeping the approval step as frictionless as possible (one click, not a form) dramatically increases completion rates. Curious how you're handling cases where users want to edit the AI output before approving?
The session boundary problem is what I keep coming back to.
Your Request → Plan → Change → Preview → Approve → Monitor loop solves the workflow side. But there's a parallel issue for non-technical founders: the AI loses context between sessions entirely.
I solved it with a dead-simple "session end" ritual — a file that captures what was done, what broke, what's next. Next session starts by reading that file. No re-explaining, no context loss.
Same principle as your approval gate: a 2-minute human checkpoint that saves hours downstream.
The 'preview → approve → monitor' loop is the part I've been retro-fitting into my own much smaller setup. I'm a solo dev building a lightweight iOS memo app and I let an LLM draft App Store release notes for me — first version had no preview step and it once shipped a sentence calling a bug fix a 'feature.' Tiny mistake, but the kind a real user screenshots. Adding a 1-minute manual check before publish was the cheapest reliability win I've made all quarter. The interesting question at this scale is: which gates eventually deserve to be auto-approved once the failure rate is below some threshold? How do you decide a step is safe enough to remove the human?
The approval step is underrated. Most people jump straight to full automation and then get burned when an edge case slips through confidently. A human-in-the-loop checkpoint before the final action catches the stuff models get wrong with high confidence — which is actually the dangerous failure mode. The monitoring piece is what I always want to see more detail on: what signals actually trigger a review vs. pass through automatically?
The approval gate is the part that separates toy demos from production AI. We learned this the hard way building aisa.to — our AI skills assessment runs a full calibration pass after every conversation, essentially a second AI reviewing the first one's work before any report goes to an employer. Without that review step, the error rate was way too high to ship with confidence.
Your Request → Plan → Change → Preview → Approve → Monitor pipeline mirrors what we ended up building for a completely different use case, which tells me this pattern is becoming the standard for any AI workflow that touches real decisions.
The monitoring piece is underrated too — you only learn what your prompts consistently get wrong after enough runs to see the pattern.
Love the approval flow — I build similar dashboards for healthtech. Clean UI is what makes or breaks these tools
skipped the monitor step in my first few agent workflows. things would break quietly for 2-3 days before I noticed. now verification is step 0, not an afterthought.
Built an AI workflow with seamless preview, approval, and monitoring features to ensure accuracy, control, and transparency. The system streamlines operations, improves decision-making, reduces errors, and enhances overall workflow efficiency for businesses.
The risk field is a clever addition — I've found that passing it directly into the AI prompt (not just logging it) actually changes how conservative the model is with edits. For high-risk tasks I use a stricter "minimal changes only, preserve all existing structure" instruction, while low-risk gets more creative latitude. Have you experimented with conditional prompting based on the risk input, or are you using it purely as a human review signal? Also curious whether you've run into issues with n8n timing out on longer content rewrites — that's been my main friction point with similar setups.
The monitoring step is underrated. I built something similar for AI writing outputs: three layers of checks before anything reaches the user.
Biggest lesson from shipping this: you cannot trust the model to follow instructions 100% of the time.
Layer 1 is prompt-level constraints. Layer 2 is structured output validation. Layer 3 is regex-based cleanup. That third layer catches things the first two miss about 15% of the time.
The preview step you described is crucial for trust. Users who can see what changed and approve it before it goes live are way more comfortable with AI-driven workflows. The alternative, "just let the AI do it and fix it later," breaks down fast at scale.
LLM-eval harness for prompt-tuning the same shape. Five-dimension rubric (local relevance, brand voice, SEO usefulness, accuracy, format fit), claude-haiku-4-5 as judge, 1-5 per dimension. Run all profile×content-type combinations in parallel, write markdown report with flagged issues and full output for spot-checking.
Baseline run scored 18.6/25 average. Three prompt fixes (em-dash ban, target-keyword enforcement, less-bracketing) re-ran same eval at 19.7/25. The +1.1 is exactly the kind of regression-test signal that makes me willing to ship prompt changes without manually checking every output.
Trick I borrowed: have the judge surface "flags" alongside scores — short strings like "missing target keyword in output." 100+ flags across 18 runs gave me the exact actionable fixes for the prompt changes.
Preview, approval, monitoring is exactly the wall we hit building voice agents. The tricky bit on voice is you cant put a human in the approval loop, sub-800ms latency means the AI has to make the call live, so monitoring has to do double duty as post-hoc QA and as the only safety net. What worked for us was logging every call as a structured event with intent tags and CRM pipeline state, so we caught about 1 in 12 calls where the agent technically completed the script but missed the actual sales signal. Treating monitoring as a sales surface, not a debug surface, changed how we built the whole stack.
If you want to focus on sales and not technical workflows, DM me.
This is a clean breakdown of what most people miss with “AI agents” — the real win isn’t the model, it’s the workflow boundaries around it.
Request → Plan → Change → Preview → Approve → Monitor is basically just proper software discipline applied to AI, and that’s what makes it production-ready instead of a demo.
The Jotform + n8n + GitHub + Vercel stack is also a nice reminder that most of this is already possible with off-the-shelf tools if you stop trying to overbuild custom orchestration.
This is exactly the mental model shift that separates "using AI" from "deploying AI as infrastructure."
At NEXUS, we run a similar pattern with n8n — each node owns one job, no node tries to be smart about everything. The approval gate (Step 6) is the part most people skip because it feels like friction. But it's actually the trust layer that makes the whole system auditable.
One thing we added: a lightweight log at each step — not for debugging, but for learning. After 30 runs, you start seeing which request types the planner consistently misreads. That's where you invest in prompt refinement, not earlier.
Good architecture. The GitHub Actions monitor at the end is underrated — simple cron, zero maintenance, and it catches the silent failures nobody thinks about until they're embarrassing.
I like it
The preview-before-approve step is the part most people skip and then regret.
a great system for solopreneurs especially - many thanks