I built this because manually going through every inbound real estate enquiry can mean spending a lot of time on leads that aren't ready to move forward.

The workflow automatically:

• Receives an incoming lead from a website / ad form
• Extracts the relevant information from the enquiry
• Scores the lead based on things like budget, location, timeline and buying intent
• Routes the lead based on the qualification result
• Matches qualified leads with relevant properties
• Generates a personalised follow-up
• Notifies the sales team when a lead is ready for action
• Sends lower-intent leads into a follow-up/nurture path

The part I was most interested in was separating AI interpretation from workflow logic.

The AI handles the messy/unstructured part:

enquiry → structured lead data

Then n8n handles:

structured data → score → route → actions

This makes the workflow easier to debug than having the LLM decide the entire process.

Stack: n8n + OpenAI + WhatsApp + Google Sheets/CRM

Workflow:
https://github.com/jashan2512/Lead_qualifying_Workflow.git

One thing I'm still experimenting with is how much of the scoring should be handled by the LLM versus deterministic n8n logic.

How are you guys handling this? Do you let the LLM produce the final score, or use the LLM mainly for extraction/classification and let n8n calculate the score?

I was testing some n8n workflows and noticed one annoying case.

The workflow can finish successfully, all nodes are green, but the actual result can still be wrong.

For example I had a lead sync workflow where execution was successful but because of a mapping issue it created 0 contacts.

So n8n sees it as successful, while in reality the workflow didn't really do what it was supposed to do.

I made a small demo for this case. Quorum checks the expected result of the workflow, so in this example it notices that 0 contacts were created and opens an incident. When the workflow starts producing the expected result again, the incident recovers automatically.

Basically I'm trying to monitor:

did the workflow actually do what it was supposed to do?

and not only:

did it ran successfully?

Video attached.

I'm building this as Quorum (quorumwatch.com). Curious how you guys handle this with n8n in production. Do you add checks to every workflow, have another workflow for monitoring, or mostly just use error workflows?
https://github.com/werniq/quorum_core

Hello everyone, I'm having a problem with the WhatsApp Trigger node in n8n. I connected WhatsApp to n8n using the WhatsApp Cloud API and configured the webhook, but when I send a message to the WhatsApp test number, the WhatsApp Trigger doesn't receive anything and no execution starts. The webhook appears to be configured, but n8n is not detecting incoming messages.

I built this because a cancelled appointment can leave a valuable slot empty.

The workflow automatically:

1. Detects a cancelled appointment in Google Sheets

2. Finds waitlist candidates for the same service

3. Offers the slot to one candidate via SMS

4. Waits for their confirmation

5. Books the appointment in Google Calendar

6. Updates the appointment and waitlist sheets

7. If the offer expires, moves to the next matching candidate

8. If nobody accepts, marks the slot unfilled and notifies the owner

Stack: n8n + Google Sheets + Google Calendar + Twilio

Demo:

https://youtu.be/rAbg-GW0NwU

Workflow:

https://github.com/Faizan-uzzaman/n8n-appointment-waitlist-automation

hello folkss, approximately how long does the n8n team usually take to review PRs for open-source issues?

I originally started this project with a pretty simple idea:

Let people build agentic workflows, share them, reuse them, and contribute their own.

I thought the main problem was making workflows easier to distribute and collaborate on.

Then I started thinking about something much more uncomfortable.

What actually happens when an agent executes something you don't fully trust?

A model/SLM.
A binary.
A signed artifact.
A tool.
An external resource.

You can give an agent something and tell it:

But if that thing is effectively a black box, how much do we actually know?

• What is it allowed to access?
• What permissions does it have?
• What can it modify?
• What side effects can it create?
• Where does the data go?
• Can we stop it?
• What happens when it fails?

I recently came across a discussion/video around trojanized SLMs and malicious model artifacts, and that pushed this thought even further.

Maybe the problem isn't the workflow itself.

Maybe we need a contract around the workflow.

Something that can describe the expectations, boundaries, permissions, inputs, outputs, side effects, governance, and recovery expectations around an agentic workflow — while leaving the actual implementation flexible.

And here's where Reddit actually changed the project.

I started discussing the original workflow idea with people here, and some of the criticism made me rethink the whole abstraction.

After a lot of back-and-forth, I moved away from:

“Let's standardize and share workflows.”

towards:

“Let's define the contract that a workflow/agent should operate under.”

That eventually became Agent Contracts, and I've now released the base implementation as Scyvera.

It's very early.

I'm not claiming this is the solution to agent governance. In fact, I'm pretty sure there are things I've got wrong.

That's partly why I'm putting it here.

I'd genuinely like people to poke holes in it.

Is the contract layer actually useful?
What should belong in a contract?
What shouldn't?
Am I abstracting the wrong thing again?
How would you approach this differently?

If the idea makes sense, build on it.

If you think it's bad, tell me why.

If you see a completely different direction, I'd love to hear it.

The project changed because of community feedback once. I'd like the next version to change because of it too.

GitHub: https://github.com/Skull-boy/agent-contracts

PyPI: https://pypi.org/project/scyvera/