The Model Is the Cheap Part

Most conversations about AI in business stop at the model. Which one, how big, how clever. That is the part that matters least. The model is a commodity you rent by the token, and it gets cheaper and better every few months whether you do anything or not.

The part that decides whether any of it works is everything around the model. The plumbing. The rules. The data it reads, the systems it writes back to, the humans on both ends. That is the work, and it is the skill that does not go obsolete when the next model drops.

This is a tour of that layer. It is written so a CEO can follow the shape of it and the person doing the work can recognise their day in it. No tool here is magic. The skill is knowing how they fit.

One request, start to finish

Forget the abstract for a second. Picture a single thing happening in a business.

A lead fills in a form on the website. Within a few seconds the system has checked who they are, scored how serious they are, decided who should handle them, written all of that into the place the sales team already works, sent the right first message, and put a line on a dashboard the founder reads on Monday. Nobody touched it. And if a step broke halfway through, someone on the team got told before the customer ever noticed.

That is the whole article in one paragraph. Everything below is just the layers that make that paragraph true, and reliable, a thousand times in a row.

Orchestration is a pattern, not a tool

The thing that holds the sequence together is an orchestrator. n8n, Make, Zapier, take your pick. It is the conductor: this happens, then that, and if this other thing is true, branch here, and if a step fails, retry or raise a flag.

Here is the part people miss. Once you can think in triggers, steps, branches, and retries, the specific tool stops mattering. I work in n8n by preference because I can self-host it and own it outright. But Make and Zapier are the same idea wearing different clothes, and moving between them is an afternoon, not a career change. The skill is the mental model of a workflow, not the logo on the canvas. That stays true all the way up this stack, and I will keep pointing at it.

For a C-level reader the takeaway is simple. You are not hiring someone who knows a tool. You are hiring someone who thinks in systems, because the tools are interchangeable and the thinking is not.

The connective tissue: endpoints, APIs, and MCPs

None of these systems live in the same place, so most of the real work is getting them to talk.

Endpoints are the doors. When the website form needs to wake the system up, it knocks on a door, a webhook or an API endpoint, and the system answers. I build those doors on Vercel, on Cloudflare Workers, in FastAPI or plain Node, depending on what the job needs, and I use ngrok to test them against the real world before they go live. In plain terms: this is how your tools stop being islands.

APIs are how the system asks other services to do things. Need to know who a lead is? That is an enrichment call to something like Clay, Clearbit, or Apollo. Need to send the first email at scale? SendGrid, Instantly, or Smartlead. Need to book the meeting? Calendly. Need to reach the team? Slack or Telegram. The exact service depends entirely on the goal, and swapping one for another is, again, a small job once you understand the category it belongs to.

MCPs are the newest piece. Think of them as a standard plug that lets an AI agent reach into a real tool and use it: your GitHub, your Notion, your Supabase, your browser through Playwright. There is a managed option like Composio, there is Zapier's own, and when nothing fits I build a custom one. The list of available integrations grows constantly, so the names matter far less than knowing what they are for. They give the system hands.

This whole layer is unglamorous, and it is where most AI projects quietly die. Not because the model was not smart enough. Because nobody could make the systems talk to each other reliably.

Business logic is the core, and it does not live in a prompt

This is the part I care about most, and the part most demos skip.

The model can suggest. The business decides. The rules for what actually happens, who counts as a qualified lead, what discount is allowed, when a human must be looped in, when to stop, those rules are the business itself. They cannot live inside a prompt, where they drift and cannot be checked. They live in code and at the data layer, in FastAPI, in NestJS, or in Supabase with its rules sitting right on top of the database.

Why this matters to a CEO: this is your control surface and your IP. It is the difference between a system that does what you decided and a system that does whatever the model felt like that day. When a regulator, a customer, or your own finance team asks why the system did something, the answer has to be a rule you can point at, not a vibe.

Why it matters to the person on the floor: this is what stops the thing from doing something stupid in your name.

Data is where the truth lives

A system is only ever as good as the state it reads. Feed it a messy, half-duplicated, out-of-date picture of the business and it will make confident, fast, wrong decisions.

So the boring skill underneath all of this is data. Modelling it, storing it, keeping it clean. I work mostly in PostgreSQL and Supabase for live state, manage and inspect it with the usual SQL tooling, reach for a warehouse or ClickHouse when the question is analytical rather than operational, and use Turso, Airtable, or NocoDB when the job calls for something lighter or something a non-technical teammate can edit directly. When the system needs to find things by meaning rather than by exact match, which is most AI retrieval, that is pgvector or Qdrant doing the work.

None of this shows up in a demo. All of it decides whether the system survives contact with a real business.

Meet the business where it already lives: the CRM

Here is a mistake I see constantly. Someone builds a clever automation that lives in its own shiny new tool, and the sales team ignores it, because the sales team lives in the CRM and is not moving.

The CRM is the system of record. HubSpot, Salesforce, Pipedrive, Attio, Zoho, Dynamics, monday, sometimes just Airtable for a smaller shop. The skill is not picking the best one in the abstract. It is writing your automation back into whichever one the business already trusts, so the work appears where people already look. Automation that forces people to change where they work does not get used. It gets quietly worked around.

Dashboards, and the layer everyone forgets

The dashboard is the last piece. It is where the system reports back, in plain numbers a founder can read in ten seconds. I usually build these custom, and the specific tool matters far less than the discipline of showing the right number to the right person. This is the output, and it is the easy part.

The layer people forget sits right next to it: observability. A dashboard tells the business what is happening. Observability tells you whether the machine itself is healthy. Error tracking, run logs, tracing every AI call so you can see what it did and what it cost. Tools like Sentry and Langfuse live here. This is the difference between hearing about a problem from your monitoring and hearing about it from an angry customer. Most people skip it. Operators never do.

Two experiences run through every step

Everything above is mechanics. This part is judgement, and it is where most of these systems live or die.

Customer experience is not a screen at the end. It is a constraint on every single decision in the chain. The customer should feel faster, smarter, more attended to, and should never once feel like they have been handed to a machine that forgot who they are. Every branch in that workflow, every automated message, every handoff to a human, gets designed around that. If the automation makes the customer's life worse so the business's life can be easier, it is built wrong, no matter how efficient it looks on paper.

Employee experience is the other half, and it is the one that quietly kills projects. Automation that dumps more on people, or that feels like surveillance, gets sabotaged by the people forced to live with it, and they are right to. The goal is to take the repetitive load off the team and hand the work back to them inside the tools they already use, Notion, Asana, Jira, Confluence, the wider Atlassian stack. Workload management is not an HR afterthought bolted on later. It is part of the architecture. A system the team resents is a failed system, however clean the code.

It has to stay up

A prototype that works on your laptop is not a system. A system is something that stays up, is owned, and can be moved.

That is hosting and infrastructure, and it is the proof that someone can ship rather than just sketch. GitHub for the code and the history of every change. Vercel for the front of things. Coolify and Hostinger for the self-hosted services I want to own outright. Docker so it runs the same everywhere instead of only on the machine it was born on. Cloudflare for DNS, security, and speed. Namecheap for the domains. The real decision here is rarely which host. It is managed versus owned, convenience versus control, and making that call on purpose for each project rather than by accident.

The skill is the whole map

Read back over all of that and notice what the skill turned out to be.

It was not any single tool. Every layer had three or five interchangeable options, and I told you each time that swapping between them is a small job. The orchestrator, the CRM, the database, the host, all of it rhymes once you have the pattern.

The skill is holding the whole map at once. Knowing that a given problem belongs to the logic layer and not the prompt. Knowing that a change to the data model ripples out into the dashboard and the CRM. Knowing where to spend reliability effort and where good enough is fine. Knowing that the customer and the employee are sitting at the two ends of every wire you connect.

The model will keep getting cheaper and smarter, and most of what feels impressive today will be a checkbox next year. The architecture around it, the part that understands how your specific business actually runs and makes a hundred systems behave as one, does not commoditise. That is the job. It has always been the job.