If you want to learn about building voice AI solutions, consider subscribing to my YouTube channel. It'll mostly be technical content (like my latest video on PBX).

I used to worry about competing with companies that sell Voice AI as a SaaS product, or with companies that have already served trade businesses for 15–20 years and are now pushing Voice AI as an add-on to clients they already own (ServiceTitan, Housecall Pro, Jobber, Service Fusion, FieldEdge, Workiz, FieldPulse, Podium). I also used to worry about VoIP providers (CloudTalk, Nextiva, RingCentral, Dialpad) pushing Voice AI as an add-on to their clients. Then I tested their Voice AI and adoption among their customers. The fear disappeared. The number of companies advertising voice AI is a lot higher than the number of businesses actually using it. For example, I called many of Scorpion's existing customers to test their Voice AI solution and found that many clients still use voicemail, even when Scorpion offers Voice AI as an add-on. There are hardly any online reviews of Scorpion Voice AI (Scorpion Convert), even though they serve thousands of trade businesses. The Achilles' heel of all these companies is that they offer Voice AI as an add-on. It's not their primary product/service. Their existing relationships give them a distribution advantage, but that doesn't automatically translate into a product-quality advantage. Selling voice AI as an add-on may get customers to try it; continued use depends on how well it handles their calls. These companies can not give agent development, testing, and ongoing improvement the attention you can because it doesn't scale and it's not their primary offering. Detailed work on each client’s agent conflicts with the economics of a standardised add-on. A specialist voice AI developer/agency can compete on the attention given to configuration, testing and ongoing improvement. So they rely on pre-built configurations that adapt based on information a customer provides through a web form. Trade Voice AI is unforgiving. The caller is stressed, talking over background noise, using trade language: “unit is icing up,” “breaker trips when the dryer kicks on,” “slow drain in the master.” In one conversation, the agent has to triage emergency vs routine, capture address and access notes, check real truck availability, and write a clean job onto the board. Generic voice agents almost always fail one of those. They sound like a polite IVR with a better voice. They miss urgency. They book the wrong slot. They cannot recover when the homeowner interrupts. If the agent is not time-aware, it may ask your customer to show up when your office is closed. If the agent does not know how to break the required-fields loop, it will keep asking the same question over and over again despite the caller’s clear refusal. If the agent doesn't know how to accept stacked answers, it will keep asking the same question over and over again even after the caller has already provided the answer. Once a caller goes off-script or provides information in a way the agent does not accept, it is over for your business reputation. The owner hears two or three of those calls and turns it off. That's why the 15-year relationship is weaker than it looks. It buys the incumbent the first 30 days. Product quality decides month two. For a voice agent to actually work in the real world, it has to be highly customised. Someone has to sit down, understand your business, and understand your target market. They have to understand how your customers actually talk and describe their issues. Then they have to keep adjusting the agent based on real call data and test edge cases. The market is not whoever gets in the door first. It is whoever survives the second week of live after-hours emergencies. That is still wide open. You don't need to worry about the companies selling voice AI as an add-on. What you need to worry about is scheduling that demo call so that you can show how good your agent really is.

Say goodbye to SEO, GEO, Content development and marketing, as well as all the jobs directly and indirectly tied to website traffic. Some people have already experienced this shift and agree it's no overstatement; others are still waiting to experience it firsthand.

LLMs treat permission to achieve an objective as permission to choose whatever means appear useful unless the instructions clearly outline and prohibit unacceptable methods to achieve the desired objective. This is a well-documented LLM failure mode called 'Scope Overreach'. Agent not following your instructions; agent going rogue is largely a result of not understanding this failure mode. For example, if your agent's objective is to resolve a customer complaint, find all possible ways a customer complaint should NOT be resolved, then instruct the agent not to use any of the listed unacceptable methods. For example, do not resolve a customer complaint by: >> Issuing a partial or full refund without human approval. >> Agreeing or providing a free replacement or repair. >> Accessing customer accounts and depositing funds/credits there. >> Sending email notifications to the client about a refund issued or denied. ... What your agent must not do is infinitely more important than what it must do to achieve a desired objective esp. when you give high-level instructions (“resolve this complaint” or “complete this evaluation”) to your agents.

Avoid the Overengineering Trap in AI Automation Development. Overengineering typically manifests as: >> Replacing working visual automation tools with custom code. >> Self-hosting platforms that work perfectly fine as managed services. >> Building infrastructure to save small amounts of money. >> Adding layers of abstraction that require ongoing maintenance. >> Optimising for problems you don't actually have. For example, if your n8n workflows run reliably, replacing them with custom code solves nothing. Every hour spent maintaining infrastructure is an hour not spent improving the actual automation logic or acquiring new clients. If a managed platform costs you a few hundred dollars monthly but saves twenty hours of maintenance, debugging, and infrastructure management, you're ahead. Your hourly rate exceeds that cost. Don't build custom solutions to save pennies. Build revenue first.

The reason is straightforward: most people can only meaningfully engage with what they can understand. So when you post something they don’t understand, they can’t agree or disagree or ask questions. Platforms amplify this further because algorithms optimize for engagement, not depth. That’s why there is lot more user engagement for generic AI related news (new model drops, funding rounds, CEO drama, “AI will replace X”) or generic posts (“nobody is coming to save you”) but hardly any for content that goes deep into AI development. It also reveal real knowledge gap. You are still not too behind if you are serious about learning AI beyond generic stuff. Most of your competition is still AI wrappers and not developers. The people who can meaningfully discuss training dynamics, evaluation reliability, systems constraints, or failure modes remain a small minority. If you’re serious, the window is still open but not infinite. Focus on building things that force you to confront real constraints (evaluation, failure modes, cost, integration with existing systems) rather than consuming more generic news or tutorials.

You can add Gibberish detection to your system prompt so that callers don't waste your tokens. My agent tolerates one instance of gibberish and gives a chance to correct it. After two chances, it politely ends the call. You can train the agent to do whatever you like. For example, you can escalate the matter to HR for AI abuse. Similar functionality can also be used to stop abuse of interviews carried out by AI. **Gibberish:** the words are clear English, but the utterance makes no sense as a whole, or the answer doesn't fit the question. Example: "My name is what do you want for breakfast but night is not good and my email has passed away." **Not gibberish:** accents, filler, rambling, self-corrections, off-topic but sensible questions, or a single misheard word (→ Unclear audio rule). Armed with this knowledge, ask Claude to help you create a gibberish detection prompt.

AI-generated code often introduces hard-to-detect security vulnerabilities. n8n’s node layer partly absorbs this risk because authentication, credentials and API calls are handled by pre-built nodes rather than by code you have to review. When you build workflows in code on Vercel or Trigger.dev without being an experienced developer, you trade that protection for flexibility and speed. Your production workflows are more likely to contain security flaws you can’t spot and failures you can’t easily fix. Most people realise this too late.

Try → discomfort → “I just can’t / I need it” → full return to the old baseline → temporary willpower attempt → repeat. My coffee progression over the years: Latte/cappuccino with added sugar > Latte/cappuccino > Regular coffee + Milk + Sugar > Regular coffee + Milk > Regular coffee. All of this was just to get milk and sugar out of my coffee. Gradual reduction works better than abrupt change. This is a general principle of sensory and habit change, not just coffee. People who don't understand this principle often relapse and get stuck in the cycle of : Try → discomfort → “I just can’t / I need it” → full return to the old baseline → temporary willpower attempt → repeat. The goal is not to become someone with infinite willpower. It is to reach a state where the desired behaviour no longer requires much willpower at all.

You should not be relying on Vercel or Trigger.dev for voice AI. Trigger.dev doesn’t receive requests directly. So your webhook has to live somewhere else, like a Vercel or Next.js route. Here’s what a single mid-call lookup looks like when you build it that way. > Caller asks “Can I get a slot on Tuesday?” > Retell turns speech into text. The LLM decides it needs the calendar. > Retell sends a request to the webhook on your server (a Vercel or Next.js route you build and host). > Your server asks Trigger.dev to run the “check availability” task, then waits. > Trigger.dev queues the task and runs it on a worker, starting one if needed. > The task calls the calendar or CRM API. > The result goes back to Trigger.dev. > Back to your server. > Back to Retell. > The LLM writes the reply. Retell speaks it: “Yes, 10am Tuesday is free.” > By now the caller has gone to bed. (OK, that’s a joke. But you get my point.) What are you running here? Retell, your own server, Trigger.dev, and the calendar or CRM. Four systems in the chain. You built and maintain two of them. Where does it hurt? Every arrow adds delay while the caller sits in silence. And when it breaks, the cause could be your server, the Trigger.dev queue, the task code or the CRM. You check each one separately. Same thing in n8n: Retell → n8n webhook → calendar/CRM node → Respond to Webhook → Retell One system. Webhook and automation in the same place. Why not just use Vercel on its own? Here’s the thing. Vercel is best for workflows that finish quickly. Once a workflow needs to run long, wait, or retry reliably, you need a tool like Trigger.dev. You won’t need Trigger.dev for every voice agent. But you will for some. Host your webhooks in code, and sooner or later you’re depending on a second platform. And once Vercel hands a job to Trigger.dev mid-call, that handoff adds latency. With n8n, there’s no handoff. Not to mention, if you can’t read and debug code, you shouldn’t be using Vercel or Trigger.dev at all. That’s most people. So in that context, when i say don't rely on Vercel or Trigger.dev for voice AI instead use n8n, it should make sense. Remember: >> Vercel alone doesn’t cover every workflow, so you end up depending on a second platform. >> The handoff adds latency mid-call, and n8n has no handoff. >> If you can’t read and debug code, neither is safe to rely on, and that’s most people.

You’ve been sold a lie about Claude Code replacing n8n. Many people jump to Claude Code to skip n8n’s steep learning curve. However, the learning curve doesn’t disappear. It actually becomes steeper with increased maintenance overhead for most people. With n8n, most of the learning happens up front, while you build. With Claude Code, the build feels easy at first. The learning is deferred until something breaks in production. And it will. At that point, you’re learning automation fundamentals, git, logs, deploys and TypeScript under pressure and that too on code you didn’t write and can’t debug. Not to mention, AI-generated code often introduces hard-to-detect security vulnerabilities that n8n’s node layer partly absorbs. You end up trading fast builds for security issues and maintenance overhead. Building happens once. Maintenance runs forever as long as the automation lives: API changes, auth expiry, rate limits, schema drift, new edge cases in the data. Each of those means reading unfamiliar code, judging an agent’s proposed fix, redeploying, and verifying. The end state is often: >> The automations get switched off. >> You end up hiring a developer to untangle or rebuild the spaghetti code, often costing more than doing it correctly at the start. >> You retreat to n8n where you can see what’s happening. Understand what you are signing up for.

My career advice for 2027: Audit your career. A native worker often thinks, “This is how things are done here. That’s just the way it is. That's my niche.” An outsider asks, “Why are we doing it this way, or why are we even doing this? What's the point when the market has moved on"? You respond to the labour market that exists, not the one you prefer. If your existing skills are no longer serving you, let them go. It's not a sunk cost. They served their purpose, and your market has moved on. When a skill no longer clears the market at the rate you need (whether because of automation, changed buyer preferences, or simply oversupply), the rational move is usually to stop treating it as the centre of your offering. Continuing to refine it, market it, or organise your career around it simply because you already invested years/decades is how people end up becoming obsolete. Develop new skills for the new market. Growth and innovation require stepping outside the comfort of majority thinking. The outsider mindset allows you to see problems and opportunities more clearly and earlier than your competition. Your existing career may have become your comfort zone, and it could soon become your death zone if you don't adapt fast. Audit your current skill stack against actual demand signals (job postings, contractor rates, internal project success, customer willingness to pay) rather than against what felt valuable 2 or 3 years ago. Don’t play by the same rules as everyone else. Question them. Redefine them. Create your own path. That mindset can open doors, sometimes even to working with world-class clients like MIT, from an office halfway across the world.

People in tech role who are currently being replaced by AI today are going to be the same people who replace others with AI once they build there career in AI. This answers your question "why you are being a part of the system which results in mass layoff for others". There is no right or wrong here. Its just survival at this point. You respond to the labor market that exists, not the one you prefer. If you don't do it, someone else will. Survival of the fittest.

Pick your role now, as it will get far worse in 2027. Most companies of the future will revolve around only two core roles: Agent Developers and Agent Supervisors. Over time, every department will likely operate within this structure. Agent Supervisors - senior subject-matter experts responsible for overseeing the performance, reliability, and strategic alignment of AI agents. Agent Developers - build, maintain, and optimise these agents, translating business logic and domain knowledge into operational code, APIs, and workflows.

Learn to manually perform a task first and do it dozen of times before thinking of automating it. So when anything breaks during automation (and it will), you know exactly what broke and how to fix it. Without manual reps, your automation workflow is unlikely to survive production load.

AI is not a technology. It’s infrastructure. You can’t opt out of infrastructure. It's deeply embedded in everything you use. Using failed adoption stories and memes as a crutch to highlight AI's current shortcomings won't halt or reverse AI adoption or change decision-makers' minds. “Billions” of dollars have already been invested. Your memes, complaint posts, and boycotts stand no chance. Adapt or see yourself becoming obsolete.

Keep all your workflow automation in n8n and forget about Retell Workflows. Retell Workflows lets your agent run a few actions at the start or end of a call without an external tool like n8n. For example, before the call, it can fetch the caller’s lead, booking or account details. After the call, it can update your CRM, create a ticket, post to Slack or send an SMS. It has no other triggers. n8n goes much further. It can be triggered by almost anything: a schedule, a webhook, a form submission, a new CRM record, an incoming email or SMS, or a Retell call. It has hundreds of ready-made nodes with authentication handled for you. It can branch, map and reshape one payload for five systems, with retries and error paths on each branch. It gives you error workflows and replay. And the same workflow can serve voice, chat, forms and email. Retell gives you eight native integrations and a JavaScript sandbox. In short, Retell Workflows is nowhere near a substitute for n8n. So if you still need n8n, why split your logic across Retell and n8n? Splitting it means no single place shows how the system works. One side gets updated, and the other doesn’t. Both may write to your CRM. And when something fails, you have to debug two systems to find out which one did it. Keep all your workflow automation in n8n and forget about Retell Workflows.