Agentes IA que trabalham sozinhos (24/7). Seu SaaS faz?

Agentes IA que trabalham sozinhos (24/7). Seu SaaS faz?

Você é founder de SaaS.

Seu produto:

• Agente de IA (WhatsApp, web, Slack)
• Modelo: REACTIVE (responde quando usuário pergunta)
• Exemplo: Customer envia mensagem → Bot responde em 5 segundos
• Você assume: "Isso é o padrão. Agentes trabalham on-demand."

Seu problema agora:

• Pizza Bot (projeto open-source) lançou: Agentes em BACKGROUND
• Meaning: Agente trabalha 24/7 (mesmo sem usuário interagir)
• Method: Roda localmente (desktop app), expõe via email-like inbox
• Architecture: Finished work in "Unread", awaiting approval in "Action"
• Implication: Agentes podem ser PROATIVOS (não apenas reativos)
• Your question: "Meu SaaS pode fazer isso?"
• Real answer: "Provavelmente NÃO. Seu agente é reativo."
• Insight: "Background agents é novo modelo. Você tá 1 versão atrasado."

O que Pizza Bot está dizendo (sem dizer):

"Agentes não precisam esperar usuário clicar. Podem trabalhar sozinhos. Seu SaaS só faz on-demand? Você tá perdendo automação potencial."

---

O problema invisível: On-demand agents são 50% da solução

Reactive vs Proactive: A diferença que quebra sua venda

=== EXAMPLE: SALES AUTOMATION ===

Your SaaS today (REACTIVE model): ├─ Setup: "Agente entra em contato quando lead pedir help" ├─ Reality: │ ├─ Lead preenche form → Espera agente responder │ ├─ Agente responde → Lead vê resposta │ ├─ Lead pensa → Envia segunda pergunta │ ├─ Agente responde → Lead vê resposta │ └─ Timeline: 2-3 horas (lead perde interesse) │ ├─ Problem: Lead tem que INICIAR conversa ├─ Reality: 70% de leads NÃO iniciam (deixam form pra depois) └─ Result: 70% de leads NUNCA falam com agente

Competitor with background agents (PROACTIVE model): ├─ Setup: "Agente trabalha 24/7, processa leads automaticamente" ├─ Reality: │ ├─ Lead preenche form às 22:00 (à noite) │ ├─ Agente processa imediatamente (não dorme) │ ├─ Agente identifica: "Lead é hot (high intent)" │ ├─ Agente prepara resposta customizada │ ├─ Agente envia email + SMS (mesmo antes de lead voltar) │ ├─ Lead acorda de manhã, vê resposta já esperando │ ├─ Lead é hooked ("Wow, empresa é rápida") │ └─ Lead RESPONDE (engajado) │ ├─ Problem: Agente trabalha 24/7 (você precisa gerenciar) ├─ Benefit: 95% de leads RESPONSIVOS (agente já preparou) └─ Result: 95% vs 30% conversion (competidor ganha)

=== THE MATH ===

Your SaaS (on-demand only): ├─ Leads/month: 100 ├─ Leads that engage: 30% (only they initiate) ├─ Conversion rate: 10% (out of 30) ├─ Sales: 3/month (100 × 30% × 10%) ├─ Revenue: 3 × R$ 5K = R$ 15K/month │ └─ Problem: You're leaving 70 leads on table (never engaged)

Competitor with background agents: ├─ Leads/month: 100 ├─ Leads that agentprocesses (24/7): 100% (all engaged) ├─ Conversion rate: 15% (out of 100, pre-warmed by agent) ├─ Sales: 15/month (100 × 100% × 15%) ├─ Revenue: 15 × R$ 5K = R$ 75K/month │ └─ Advantage: 5x more sales (R$ 75K vs R$ 15K)

=== WHY THIS HAPPENS ===

Reactive agents (your model): ├─ Customer must: Initiate conversation ("Hey bot, help me") ├─ Trigger: Human action (user clicks, types, submits form) ├─ Timeline: When human acts ├─ Latency: Instant (if bot is running) ├─ Problem: MOST HUMANS DON'T ACT │ ├─ "I'll email tomorrow" → Forget │ ├─ "I'll call later" → Never happens │ ├─ "I'll submit form when I have time" → Never free │ └─ Result: 70% of leads never engage │ └─ Model name: "On-demand" or "reactive" (responds to requests)

Proactive agents (Pizza Bot model): ├─ Agent must: Work continuously (24/7) ├─ Trigger: Time-based, event-based, or data-based ├─ Timeline: Predetermined schedule or real-time events ├─ Latency: Continuous (agent never sleeps) ├─ Benefit: AGENT INITIATES │ ├─ Agent: "Lead came in 2 hours ago, let me process" │ ├─ Agent: "I found 3 issues in their form, prepared answers" │ ├─ Agent: "Now I'm sending email so they see it tomorrow AM" │ ├─ Agent: "If they don't respond in 24h, I'll follow up" │ └─ Result: 95% of leads get engaged │ └─ Model name: "Background" or "proactive" (initiates actions)

=== REAL WORLD EXAMPLES ===

Example 1: Email inbox cleaning ├─ Reactive (your model): User asks "Clean my inbox" │ ├─ You: "OK, let me delete old emails" │ └─ Problem: User has to ask (takes effort) │ ├─ Proactive (Pizza Bot model): Agent runs 24/7 │ ├─ Agent: "Every night at 2 AM, clean inbox automatically" │ ├─ Agent: "Delete emails older than 30 days" │ ├─ Agent: "Archive newsletters" │ ├─ Agent: "Tomorrow you wake up to clean inbox" │ └─ Benefit: Zero effort from user │ └─ Winner: Proactive (user doesn't have to ask)

Example 2: Lead scoring ├─ Reactive (your model): User asks "Score my leads" │ ├─ You: "OK, let me score them" │ └─ Problem: User forgets to ask (process doesn't happen) │ ├─ Proactive (Pizza Bot model): Agent runs 24/7 │ ├─ Agent: "New lead comes in → Score immediately" │ ├─ Agent: "If hot lead → Send alert to sales team" │ ├─ Agent: "If warm lead → Queue for follow-up" │ ├─ Agent: "If cold lead → Tag for nurture sequence" │ └─ Benefit: Sales team always has scored leads ready │ └─ Winner: Proactive (happens automatically)

Example 3: Customer support ├─ Reactive (your model): Customer asks question │ ├─ Flow: Customer asks → Bot responds → Customer waits │ └─ Problem: Customer has to initiate │ ├─ Proactive (Pizza Bot model): Agent monitors 24/7 │ ├─ Agent: "Customer hasn't logged in for 7 days" │ ├─ Agent: "Let me check their recent activity" │ ├─ Agent: "They have 3 unresolved tickets" │ ├─ Agent: "Send proactive email: 'We noticed... let us help'" │ ├─ Agent: "If they respond → Escalate to human" │ └─ Benefit: You reach out before they complain │ └─ Winner: Proactive (company initiates support)

=== THE ARCHITECTURE DIFFERENCE ===

Reactive agents (your current model): ├─ Deployment: Cloud API (responds to HTTP requests) ├─ Running: Only when called (sleep 99% of time) ├─ Trigger: External (user clicks, sends message) ├─ Logic: Simple (read input, generate output) ├─ State: Stateless (forget after response) ├─ Monitoring: User monitors (if they check) ├─ Costs: Low (pay only for requests) └─ Limitation: Can't initiate action

Proactive agents (Pizza Bot model): ├─ Deployment: Local (desktop app) or always-on server ├─ Running: Continuous (24/7, never sleeps) ├─ Trigger: Internal (schedule, queue, events) ├─ Logic: Complex (plan, execute, verify, iterate) ├─ State: Stateful (remember context, history) ├─ Monitoring: Agent self-monitors (built-in) ├─ Costs: Higher (always running, need infra) └─ Capability: Can initiate action, follow up, verify

=== WHY PIZZA BOT MATTERS ===

Pizza Bot is saying: ├─ "Background agents don't need cloud infrastructure" ├─ "You can run on your own machine (Mac, Windows, Linux)" ├─ "No signup, no telemetry (privacy-first)" ├─ "Use any model provider (OpenAI, Anthropic, Google, etc)" ├─ "Apache 2.0 licensed (open source, you own it)" ├─ "Simple inbox UI (finished work, pending approval)" │ ├─ Subtext: "Building background agents is EASY now" ├─ Implication: "Your SaaS should have this feature" ├─ Timeline: "In 6 months, every decent SaaS will have it" └─ Window: "First-mover advantage is ~3-6 months (before commoditized)"

---

Como implementar background agents no seu SaaS

Architecture blueprint: Do simple to complex

=== PHASE 1: START SIMPLE (Week 1-2) ===

Use case: Email cleaning (simplest background agent)

├─ Agent capability: │ ├─ Every night at 2 AM (schedule) │ ├─ Connect to user's Gmail (permission required) │ ├─ Find emails older than 30 days │ ├─ Ask user: "Delete these 200 emails? Y/N" │ ├─ User approves via email (simple approval flow) │ ├─ Agent deletes them │ └─ Agent sends report: "Cleaned 200 emails" │ ├─ Implementation: python

Simple background agent

import schedule import anthropic import gmail_api

def background_agent_task(): # Step 1: Get user's old emails old_emails = gmail_api.get_emails(older_than_days=30)

# Step 2: Let Claude decide what to delete
prompt = f"""
User has {len(old_emails)} emails older than 30 days.
Which should I delete (keep important ones)?

Emails:
{old_emails}
"""

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}]
)

# Step 3: Get user approval (email with Y/N buttons)
approval = send_approval_email(response.content)

# Step 4: Execute if approved
if approval == "yes":
    gmail_api.delete_emails(list_to_delete)
    send_report("Cleaned emails successfully")

Schedule to run daily at 2 AM

schedule.every().day.at("02:00").do(background_agent_task)

│ └─ Result: Simple background agent (no complex logic)

=== PHASE 2: ADD PROACTIVE LOGIC (Week 3-4) ===

Use case: Lead qualification (more complex)

├─ Agent capability: │ ├─ Every 30 minutes (frequent check) │ ├─ Check new leads in CRM (Salesforce, Pipedrive, custom DB) │ ├─ Analyze each lead (qualification logic) │ ├─ If hot lead → Send alert to sales team immediately │ ├─ If warm lead → Add to follow-up queue │ ├─ If cold lead → Add to nurture sequence │ ├─ Track all actions in CRM │ └─ Send daily report to sales manager │ ├─ Implementation: python def background_agent_lead_qualification(): # Step 1: Get new leads new_leads = crm.get_leads(status="new")

for lead in new_leads:
    # Step 2: Qualify lead (Claude analyzes)
    qualification = claude_qualify_lead(lead)
    # Returns: {score: 0-100, category: "hot"|"warm"|"cold", reason: "..."}
    
    # Step 3: Take action based on qualification
    if qualification.category == "hot":
        # Send Slack alert to sales team
        slack.send_message(
            channel="#sales-hot-leads",
            text=f"🔥 HOT LEAD: {lead.name}. Score: {qualification.score}. Reason: {qualification.reason}"
        )
        # Send SMS to sales manager
        sms.send(manager_number, f"Hot lead: {lead.name}")
    
    elif qualification.category == "warm":
        # Add to follow-up queue
        crm.add_to_queue(lead, queue="warm_leads_followup")
    
    elif qualification.category == "cold":
        # Add to nurture sequence
        crm.add_to_sequence(lead, sequence="cold_lead_nurture_3months")
    
    # Step 4: Record action
    crm.log_action(lead, action=f"Auto-qualified as {qualification.category}")

Run every 30 minutes

schedule.every(30).minutes.do(background_agent_lead_qualification)

│ └─ Result: Proactive lead processing (24/7)

=== PHASE 3: ADD CONTINUOUS MONITORING (Week 5-6) ===

Use case: Customer health monitoring (most complex)

├─ Agent capability: │ ├─ Continuous (every 1 hour) │ ├─ Monitor active customers (engagement metrics) │ ├─ Detect at-risk customers (usage drop, support tickets, etc) │ ├─ Trigger interventions automatically: │ │ ├─ If usage ↓ 50% → Send email: "We noticed... how can we help?" │ │ ├─ If 3 support tickets → Offer priority support │ │ ├─ If no login in 7 days → Send SMS reminder │ │ └─ If negative sentiment in feedback → Flag for CS team │ ├─ Track success (did intervention work?) │ └─ Learn + improve (refine logic over time) │ ├─ Implementation: python def background_agent_customer_health(): # Get all active customers customers = db.get_customers(status="active")

for customer in customers:
    # Step 1: Analyze health metrics
    metrics = {
        "last_login": customer.last_login,
        "usage_trend": customer.get_usage_trend(days=30),
        "support_tickets": customer.get_recent_tickets(days=7),
        "feedback_sentiment": customer.get_feedback_sentiment()
    }
    
    # Step 2: Assess risk (Claude analyzes)
    risk = claude_assess_risk(customer, metrics)
    # Returns: {level: "low"|"medium"|"high", reason: "...", action: "..."}
    
    # Step 3: Execute intervention
    if risk.level == "high":
        # Send personalized email
        email_content = claude_generate_intervention_email(customer, risk.reason)
        email.send(customer.email, subject="We're here to help", body=email_content)
        
        # Also alert CS team
        slack.send_message(
            channel="#customer-success",
            text=f"⚠️ At-risk customer: {customer.name}. Risk: {risk.reason}"
        )
        
        # Schedule follow-up (if intervention doesn't work)
        schedule_followup(customer, delay_hours=24)
    
    # Step 4: Track intervention
    db.log_intervention(customer, action=risk.action, status="pending")
    
    # Step 5: Monitor outcome
    # Next run: Check if customer engagement improved

Run every 1 hour (continuous monitoring)

schedule.every(1).hours.do(background_agent_customer_health)

│ └─ Result: Continuous customer health monitoring (24/7)

=== DEPLOYMENT OPTIONS ===

Option 1: Like Pizza Bot (self-hosted) ├─ Run on desktop (Mac, Windows, Linux) ├─ User's machine runs agent 24/7 ├─ Pros: Privacy, control, no subscription ├─ Cons: User must keep machine on, complex setup └─ Example use: Personal assistant, privacy-first users

Option 2: Always-on server (your infrastructure) ├─ Run on cloud server (AWS, GCP, Azure) ├─ Server runs agent continuously ├─ Pros: Reliable, scalable, no user hassle ├─ Cons: You pay for infrastructure, need to manage └─ Example use: SaaS, enterprise, high-volume

Option 3: Hybrid (best of both) ├─ User can choose: Self-hosted OR your servers ├─ Self-hosted: Privacy-first users ├─ Your servers: Convenience-first users ├─ Pros: Flexibility, appeal to all segments ├─ Cons: Complex to implement └─ Example use: Enterprise SaaS

=== COST IMPLICATIONS ===

Reactive agents (your model): ├─ Infrastructure: Minimal (stateless API) ├─ Uptime requirement: 99.9% (during business hours) ├─ Scaling: Easy (horizontal scaling) ├─ Cost model: Pay-per-call (cheap) ├─ Annual cost: R$ 10K-50K (depending on volume) └─ Margin: High (cheap to run)

Proactive agents (Pizza Bot model): ├─ Infrastructure: Significant (always-on service) ├─ Uptime requirement: 99.99% (24/7) ├─ Scaling: Complex (stateful, coordination needed) ├─ Cost model: Pay-per-month (fixed or variable) ├─ Annual cost: R$ 50K-200K+ (depending on complexity) └─ Margin: Lower (expensive to run 24/7)

=== THE TRADE-OFF ===

Reactive (your model): ├─ Pro: Cheap, simple, easy to scale ├─ Con: Limited value (customer has to ask) ├─ Result: 3/10 customer value │ └─ Margin: 70% (you keep most revenue)

Proactive (Pizza Bot model): ├─ Pro: High value, automations, differentiation ├─ Con: Expensive, complex, need 24/7 uptime ├─ Result: 9/10 customer value │ └─ Margin: 40% (half of revenue goes to infra)

=== THE DECISION ===

Stay reactive: ├─ Keep margin high (70%) ├─ Lose to competitors with proactive agents ├─ Customer churn (competitors offer more value) └─ End: Out of business in 2 years

Go proactive: ├─ Accept lower margin (40%) ├─ Win against competitors (you offer more value) ├─ Customer loyalty ("How did I live without this?") └─ End: Growing business, market leader

---

Conclusão: Background agents são future. Ondemand é past.

O que Pizza Bot está sinalizando:

• "Building background agents is now EASY (open-source, no signup, any model)."
• "You don't need cloud infrastructure (can run locally)."
• "Your SaaS should have this feature (if doesn't, you're behind)."
• "Window is 3-6 months before it's table-stakes (every SaaS will have it)."

O que você deveria fazer:

1. This week: Auditar seu SaaS (é reativo ou proativo?)
2. Next 2 weeks: Prototipar background agent (simples, como email cleaning)
3. Next 4 weeks: Pilotar com 10 beta customers
4. Next 8 weeks: Rollout para todos (se pilot bem-sucedido)

Na OpenClaw:

Ajudamos SaaS builders migrar de reactive para proactive agents:

• Architecture Design: Como desenhar background agents (stateless vs stateful, triggers, approval flows)
• Use Case Selection: Qual feature seu SaaS beneficia de background execution?
• Implementation: Build background agent (schedule, event-based, data-based)
• Deployment: Self-hosted vs cloud vs hybrid?
• Cost Optimization: Como rodar 24/7 sem quebrar margin?
• Monitoring: Como garantir agente funciona corretamente 24/7?
• User Experience: Como comunicar que agente trabalhou (inbox, reports, notifications)?

Você quer estar 1 ano à frente (background agents) ou 1 ano atrás (on-demand only)?

Background Agents | 24/7 Automation | Proactive Agents | Architecture Design →