I've worked in advertising and online business since 2012. Along the way I've learned that the difference isn't in which tools you subscribe to, but in how clearly you design your workflows, how complete the data feeding your systems is, and how well you judge when to use deterministic automation versus calls to language models.
At SpartAds, the team provides AI and automation services for businesses that need to solve concrete workflows. In the AI Lab, I bring together entrepreneurs in two mentoring sessions per month on online business, where I review projects and share the technical backstage of what we build.
On Sextas Ímpares, my free YouTube lecture series, I show code, discuss architecture, and share business decisions with examples. On this page you'll find the lectures organized by theme, with links to the videos and the exact minutes where I demonstrate each concept.
What I was already saying about AI in 2022
In my book Aprende a vender com Marketing Digital, written in 2022, I devoted two sections to algorithms and artificial intelligence. I mainly discussed automation in advertising and the need to develop strategic thinking. Today I apply that same approach to language models and the tools I build for my businesses.
The question was already in the book: do algorithms threaten the traffic manager’s job? I wanted to understand what we would do with the time freed up by the machine. There was more room to study the offer, interpret results and improve conversion. Staying busy adjusting campaigns manually had little value if that intervention did not improve the outcome.
Since then, the work I can support with AI has expanded. In my lessons I demonstrate file analysis, application development and tool integrations. These applications came after the book and bring their own responsibilities: deciding which information may be used, which actions are authorised and how to check what the system actually did. Advertising experience helps me ask better questions; each application still needs testing.
I like to start with a simple question: if this task takes less time, where will I use that time? It might help us respond better to customers, review projects or reduce pressure on the team. I then check whether that happened. The value of the change shows up in the work we can deliver and how well we deliver it.
How to describe a process before automating it
A process should only be automated once you can describe every manual step without ambiguity, identify the data sources, and define the exception rules. If the team hesitates over who validates a record or where the result gets saved, automation will only speed up errors that already exist.
Before opening the tool, talk to whoever does the task. Ask them to walk you through a case from start to finish: what they receive, what they decide, and what they do when information is missing. If each person follows a different process, agree first on how the work should function. Only then does it make sense to automate it.
Imagine, hypothetically, a lead capture flow where a form inserts an opportunity into the CRM and notifies a manager. Its stability depends on the edge cases: what happens if the contact already exists under another owner? How do you handle submissions outside business hours? Without those answers settled on paper, any automation will generate data conflicts.
To decide where to intervene first, I evaluate four variables: how often the task happens, how much human time it consumes, the quality of the data at the source, and the cost of an error. Frequent routines with standardized inputs bring faster returns. Rare tasks involving a lot of subjective judgment call for manual organization first, not immediate automation.
The business process automation guide follows that journey into daily operation. It covers states, exception testing and maintenance responsibilities.
Conditional rules versus language models: when to use each approach
Use conditional rules for calculations and direct logical checks, since they're deterministic and cheap. Use language models when interpreting unstructured text or extracting semantic meaning. Assigning basic business logic to probabilistic models instead increases operating costs and introduces failures that are difficult to predict or debug reliably.
In the lecture The role of the traffic manager in the age of AI, Sextas Ímpares #151, I showed this separation in AdSummit's campaign management. I used AI during the planning and code-writing phase, but the execution engine ran on fixed rules, as I explain starting at 7:03. The system reads hourly metrics and decides budgets based on a predefined matrix, without consulting any language model in that routine.
If you need to check whether a cost per acquisition has crossed a ceiling, a code condition resolves that in fractions of a second and at no cost. If you need to classify the sentiment of a message or extract data from free text, that's where a language model pays off. Mixing these two natures within the same execution block compromises the system's reliability.
When you do use a model, force structured outputs, verify the integrity of the response, and shield the business from hallucinations. Text generated by AI should never pass directly into a critical billing action or a budget cut without validations and permissions specific to that action. In the automations I presented at 35:22, the sequence is fixed: data collection via API, mathematical evaluation of limits, execution, and a WhatsApp alert. You can read more about this logic in the article how to use AI in business beyond chatbot questions.
When the system needs to choose steps and use tools, consider AI agents for businesses. I explain how to define scope, limit access and check when the agent should stop.
B2B prospecting: collecting data, qualifying, and delivering an opportunity
AI-driven prospecting should focus on qualifying companies compatible with your offer before any human contact happens, avoiding mass and indiscriminate outreach. The goal is to hand the sales team only contacts that have passed some verified criteria, not just volume.
In the lecture B2B Prospecting with AI, Sextas Ímpares #131, I showed how to collect and qualify contacts using Apify, n8n, and language models. In the live demonstration I ran, I tried to extract contacts from psychology practices through Instagram and the result came out weak: most contacts came from Brazil, not Portugal, because the chosen keyword didn't work well for that scraper. Through Google Maps, though, the same approach for dental clinics brought back results that were almost all Portuguese. This illustrates well how results depend heavily on the tool and the keyword used, and nothing guarantees success on the first try.
Any scoring assigned by AI needs to keep auditable criteria. If you're evaluating sector, size, and digital presence, a score from 1 to 10 is useful for ranking priorities, not for predicting the probability of closing a deal. It's important that the sales team knows how to distinguish a fact collected directly from an inference made by the model.
Before scaling data collection to large volumes, it's worth manually checking a sample: confirming whether the company's activity matches the niche, whether contacts are actual decision-makers, and whether discard criteria were applied correctly. The ability to extract hundreds of contacts quickly creates the temptation to fire off generic messages; the serious work goes the opposite direction, refining filters and limiting volume to contacts with a real match. I go deeper into this process in the article how to qualify B2B opportunities before making contact.
Building internal software: the example of the betting pool with Claude Code
Building internal tools with vibe coding lets you solve operational problems without depending on generic market platforms, but the result depends on a careful initial planning phase that defines rules, data architecture, and access levels before any code gets written. Without that planning, the risk of rework is high.
In the lecture How I built an app with Claude Code (step by step), Sextas Ímpares #145, I showed the construction of a sports prediction app to use with friends during the World Cup. The project involved authentication, guess submissions locked by time, multi-level scoring, automatic match updates via an external API, and an admin area. I started building it on a Wednesday late afternoon, and by the next morning the app was already operational; I still spent a few more hours afterward reinforcing security before exposing it publicly.
Before generating any code, I wrote down every detail in a document: submission cutoff times, scoring rules, the sports API endpoints to query, and admin panel permissions. In Claude AI, I asked the model to ask me exhaustive questions about anything that was still unclear before moving on to Claude Code. In that specific case, I answered more than 280 questions before the specification file was ready. It was that interrogation that closed gaps which would otherwise only surface halfway through the build, forcing me to rewrite parts already done.
This discipline applies to client portals, pricing calculators, or internal dashboards. Vague instructions like "build me a sales dashboard" tend to produce unstructured databases and fragile code. Detailing permissions, user types, and state flows before starting gives the model enough context to build in phases without breaking what's already been done. I develop this method in more detail in the article how to plan an app with Claude Code before starting to code.
Security before publishing a project online
An application built with the help of language models should only be exposed to the internet after a careful review of credentials, database rules, and server-side validations. The speed at which code gets generated doesn't replace the technical care needed to avoid data leaks.
In lecture #145, I dedicated a specific work block to security once the tool was functional, covering everything from excluding secrets from version control to protecting participants' data, as I explain at 23:43 and go deeper on at 1:23:04.
In the tools I build before publishing them, I follow a set of checks I consider minimal:
- Database access policies. Tables with private data need row-level access rules, ensuring each user only sees what belongs to them.
- Server-side permission validation. Hiding a button in the interface doesn't stop someone from attempting the same action through another path; the server has to confirm identity and permission on every request.
- Isolation by identifier. The system should reject attempts to access third-party records through parameter manipulation in the address.
- Segregation of environment variables. Access keys and credentials should never appear in the repository or in code exposed to the browser.
- Input validation. Forms, uploads, and parameters received from external APIs need limits and sanitization to avoid injections.
I usually separate building from reviewing. In lecture #145, I show how I use Codex to review the work done with Claude Code, at 1:38:43. The report gives me points to investigate and fix; afterward I need to test the changes and confirm the application's behavior.
For examples of reviewing these layers, explore the five security rules for AI-built applications. The application development guide connects review with the first version, testing and maintenance.
Complete data and context in campaign analysis
AI only produces reliable performance diagnostics when the data it's fed is free of distortions and comes accompanied by the business's commercial context. A model doesn't guess at inconsistencies in an exported report, nor does it evaluate numbers detached from a company's financial reality.
In the lecture How I use Claude in my ads, Sextas Ímpares #142, I worked through interpreting advertising reports. One practical detail exposed a common risk: the exported file only reflected the columns visible on the platform's screen, at 26:31. If the export omits metrics or includes aggregate totals in the same table, the model draws wrong conclusions based on incomplete data.
Before asking an AI assistant for analysis, it's worth confirming that the period is aligned, the currency matches, campaign naming is consistent, and that overall summary rows have been removed so investments aren't duplicated. It's also necessary to clarify what each conversion metric actually means: an acquisition event might be a cold lead, a phone call, or an already completed purchase.
Then, the question you ask needs to reflect the operational context of the campaign. Evaluating whether cost per click rose from one week to the next is a mechanical analysis; understanding whether that rise is acceptable because commercial conversion improved requires crossing advertising data with real billing data. Send only aggregated metrics and avoid transferring customer names, contacts, or addresses to public AI platforms.
I develop question preparation and calculation checks in the AI data analysis guide. It is useful reading before turning a report into a campaign or team decision.
From the team’s playbook to automation instructions
A playbook should let another person carry out a task and understand decisions already made. In the book, I recommended documenting objectives, steps and lessons to make that handover easier. When applying this practice to AI today, I add access limits, situations requiring review and a way to stop an execution.
Consider a request for a quote. The document can explain which information is needed, where to confirm the requested service and who prepares the proposal. Include examples of complete and incomplete requests, with the reason for each decision. If essential information is missing, the process should request clarification or pass the case to a responsible person.
Giving that document to a model provides context, but permissions must also exist in the application. An assistant that prepares a proposal does not therefore need permission to change prices, approve discounts or send the proposal to the customer. A written instruction to “ask for authorisation” needs a technical check that prevents the action until that authorisation exists.
The test record belongs in the playbook too. Keep the case, expected result, actual outcome and correction, using fictional or appropriately anonymised examples. When you change instructions, an integration or the model, run the important cases again. This is a current application of the learning discipline I already advocated in the book.
For the technical detail, Anthropic explains how predefined workflows differ from agents and how to evaluate AI agent behaviour. These are complementary references; my Claude Code planning demonstrations let you follow the decisions in a concrete project.
Daily operation: monitoring, failures, and costs
Daily operation requires monitoring routines confirming data updates correctly and safeguards preventing destructive actions during network outages. Failure handling must address connection drops, sensor errors, and unexpected downtime gracefully. Tracking consumption limits and resource costs matters too. Ignoring these operational details transforms a promising technical project into an ongoing, unplanned burden requiring constant attention and troubleshooting.
A reliable automation distinguishes a momentary absence of data from an actual result of zero. If a payments API doesn't respond for a few minutes, the system should log the occurrence and retry in a controlled way, rather than assuming billing dropped to zero and firing false alerts. Tasks that send messages or create orders need idempotency keys, so that a repeat caused by a technical failure doesn't create duplicates.
In lecture #142, I explained the routing architecture between Google Sheets, n8n, and WhatsApp alerts, at 29:28. A useful alert summarizes just the detected anomaly, states the period involved, and links directly to the error record. Continuous, generic messages generate fatigue in the team and cause real incidents to go unnoticed.
It's worth tracking the consumption of model calls and the computing cost of each automation. Before connecting a process to thousands of records, testing on a small sample helps estimate the average cost and set daily limits. It also pays to measure how much time the team still spends reviewing or correcting the system's results. That number helps you understand whether the process actually improved. You can see this balance in the article growing an online business: what I've learned about margin, team, and AI.
Team training and integrating AI into the business
AI adoption in a company fails when it's treated as a theoretical exercise disconnected from profitability goals and daily routines. Technology only takes root when leaders and executors alike master diagnosing their own problems before asking the machine for solutions.
In Sextas Ímpares #143, from May 15, I spoke about a common trap in many Portuguese companies: almost all of them say they use AI daily, but most limit themselves to drafting generic texts or summaries, while a minority uses vibe coding and more advanced automations to cut fixed costs and redesign the operation.
Building team capability starts with focusing on the whys, not the tools. Whoever already understands the business's economics and knows how to correlate financial metrics multiplies their productivity once given tools like Claude Code or Codex. Whoever doesn't master the fundamentals of the business tends to limit the use of these tools to cosmetic tests with no impact on revenue. In the in-person immersions I run, the format is a hands-on workshop: each participant works on a real challenge from their own company and leaves with an initial version of a tool to test afterward in their business.
How to work with me in this area
If you need a team to implement, SpartAds offers that service. If you'd rather learn and discuss your project with me directly, check out the Laboratório da IA and the available courses. Start by explaining what you want to solve and what you've already tried; that helps clarify which path makes sense.
If you're looking for a team to design and implement custom automations, check out SpartAds' AI and automation services. The team evaluates your existing workflows and builds integrations that return predictability to your operation.
If you want to learn how to architect these systems and follow the practical evolution of these technologies under my guidance, sign up for the AI Lab, where I run two mentoring sessions per month and review practical projects from the community.
For speaking invitations or executive training for your team, send the context of your proposal through the invitations page. My team evaluates availability and clarifies objectives before presenting a proposal. To see how I connect this approach with generating revenue, continue on to the article how to turn more leads into clients in a services business.
A small trial before handing the process to the team
Before handing an automation over to the team, prepare a small trial with a few records, different situations and someone responsible for reviewing the results. The trial should show what happens when everything works and when information is missing. Keep a record of the decisions so someone else can understand and repeat the checks.
Imagine a service business receiving enquiries through its website. This is an illustrative process design, not a client result: the form collects the enquiry, a rule checks the required fields and AI suggests a category from the description. The team confirms that category before using it to decide how to follow up.
Prepare three fictional enquiries. The first clearly names a service; the second gives a vague description; the third combines two different requests. The system should distinguish these situations and show when it lacks enough information to continue. A convincing response does not make an incorrect classification useful.
Use a simple sheet to record the enquiry, expected category, actual response and reason for any difference. If the model gives everything the same category, review the context and examples. If a field is missing, check that the automation flags the gap rather than filling it with an assumption.
Then test the handover. The person receiving the enquiry should see the original text and be able to correct the classification without depending on whoever built the workflow. The internal message should identify the next action and its owner. A notification only helps if someone knows what to do with it.
Test an integration failure as well. Interrupt the connection in a test environment and check whether the enquiry is saved, an alert appears and recovery avoids duplicate contact. Do not run this exercise on real enquiries without a plan that protects the business operation.
Once the process is understood, increase the volume in stages. Track which cases need correcting, where delays occur and what the workflow costs to run. Those records help you decide whether to continue, simplify a step or keep part of the work manual.