The model is a third of the work

Our best follow-up system for a realty team runs on a model that is two generations old. A newer model would not be what made it better. What moves the results is everything around the model: what it knows about the lead before it writes, what it's allowed to change in the CRM, and the check that runs after it writes. The model is maybe a third of the work. The rest is the boring stuff nobody screenshots.

I say this because the first question we get on almost every sales call is which model we use. It's a reasonable question. It's also the wrong place to look if you want to know whether a system will work in your business.

What the other two thirds are

Here is roughly what happens before our realty follow-up agent sends a single text.

An n8n flow wakes up on a schedule or on a CRM event. It pulls the lead's current state from Supabase: stage, last contact, last reply, who on the team owns them, whether they have an appointment on the books, whether they've asked not to be texted. That last field gets checked first and ends the run if it's set. Then it pulls the conversation history, trimmed to what matters. The last few messages in full, older ones summarized, and any facts the lead has given us, like budget, area, timeline, or whether they're pre approved.

Only then does the model see anything. It gets a short brief: who this person is, where they are in the process, what happened last time, and what the next useful message would be. It writes one draft.

The draft then goes through a second pass that can kill it, which is its own post. If it survives, the flow sends it through the team's own number, logs it to the CRM, and updates the lead's state so the next run sees what happened.

Count the steps. The model call is one of them. The others are reads, checks, and writes, and every one of them can be wrong in a way that no model can fix.

Memory beats intelligence

The most common failure we see in follow-up tools is an agent that writes a smart message to the wrong situation. It asks a lead if they're still looking when they closed on a house last week. It offers a showing for a listing that went under contract yesterday. It follows up on a question the lead already answered by phone with a human agent.

A smarter model doesn't fix any of that. The model wrote a fine message. It just didn't know what had happened. The fix is state. Every touch, from any channel, has to land in one place the agent reads before it writes. That's the reason the flow checks Supabase before every single message rather than trusting what it saw an hour ago. Leads change fast, and the agent has to see those changes before it writes.

Compare an agent that reads a nightly export with one that reads live state. Same model, same prompt. The second one simply stops writing to situations that no longer exist, and that is most of what people mean when they say an agent feels smart.

Permissions are product decisions

The other thing that matters more than the model is what the agent can touch. Can it change a lead's stage? Can it book a showing on an agent's calendar, or only suggest times? Can it mark someone as not interested?

Every one of those is a product decision with a real cost when it goes wrong. An agent that can close out leads will eventually close out a lead who was about to buy. So our agents get the smallest set of writes that still makes them useful. They log messages, update a few fields we have agreed on with the team, and hand anything bigger to a human with a note explaining why.

This makes the system look less autonomous in a demo. It also means the team trusts it enough to leave it on, which is the only measure that counts.

So when should you change models?

Sometimes the model really is the bottleneck. Long documents, messy reasoning across many records, or tasks where the older model keeps misreading intent. In those cases we swap it, and we treat the swap like a software release, with tests and a slow rollout.

But the order matters. Fix the memory first. Fix what the agent can see and what it can touch. Add the check after it writes. Then, if the results are still not where they need to be, look at the model.

Most teams do it backwards. They chase the newest model, rebuild prompts every few weeks, and never fix the stale export that's feeding the agent yesterday's data.

If a vendor can only tell you which model they use and can't tell you what the agent reads before it writes, they haven't built the system yet.