Sales Pipeline Automation Without Reinventing the CRM
Two agents, 14 tools, $92-242/month. Pipeline always up to date with zero human coordinator.
A team of 3 people. Prospect emails going unanswered for days. A Notion pipeline nobody updated. Calendar coordination requiring 4-5 email exchanges per meeting. Contact information scattered across 6 business units, with nobody cross-referencing the data.
That was the operational reality at Odisea (the technology lab behind Synaptic) before building Penelope and Ulises. It wasn’t a willingness problem. It was a capacity problem: 3 people can’t keep up with managing a podcast with 50+ potential guests, a DeFi sales pipeline with 92+ prospects, and research programs across 6 countries.
The obvious solution was hiring an operations coordinator at $1,500-2,500/month. The solution we implemented was building two AI agents for $92-242/month.
Penelope: The Personal Operations Agent
Penelope is a Slack bot with 14 tools in production. She runs on Claude Sonnet 4.5, connected to Gmail, Notion, Google Calendar, and Brave Search. The code is pure Python: ~940 lines, using slack_bolt in Socket Mode.
The architecture is straightforward. A background thread checks Gmail every 5 minutes for unread emails. A pattern list filters noise (noreply@, notifications@, internal @odisea.xyz emails). When something relevant arrives, Claude generates a draft response with Penelope’s voice and personality. That draft gets posted to a Slack channel with three buttons: Approve, Reject, Edit. The human decides. Only after that decision does the agent execute.
That last part is what separates a usable system from a dangerous one. Penelope never sends an email without explicit approval. Never schedules a meeting without confirmation. Never modifies the pipeline without someone validating it. The pattern is always the same: the agent prepares, the human approves, the agent executes.
The 14 tools
The tool stack covers 5 categories:
Email: check_inbox, read_email, send_email, reply_email. Full Gmail cycle. Each read email gets marked to prevent double processing.
CRM: search_guests, query_pipeline, create_guest, update_guest, read_page, create_episode_page. Full CRUD on the Personas de Interes database in Notion. The pipeline has 5 stages: Scouted, Contacted, Confirmed, Pre-Production, Done.
Calendar: find_available_slots, create_recording_event. Queries Google Calendar FreeBusy for 3 team members simultaneously. Creates events with Google Meet and all attendees included.
Research: web_search. Brave Search API for background research on guests and prospects.
Communication: post_to_channel. Posts updates to the podcast’s Slack channel.
What changed in practice
Before Penelope, scheduling a podcast recording required 4 to 5 email exchanges. Someone on the team checked their calendar, the calendars of the other 2 members, proposed times to the guest, received a counterproposal, went back and forth until landing on a date. It frequently took 3-4 days between the first email and the confirmed date.
With Penelope, the flow is: the guest confirms interest, Penelope queries availability across all 3 calendars via FreeBusy, proposes 3 options to the guest, and when the guest picks one, creates the event with a Meet link and all attendees. One email exchange instead of five.
Email response time went from days to hours. The bottleneck is no longer the bot’s speed (which responds in seconds) but the time the human takes to approve the draft in Slack. And since the draft arrives with full context from the original email, the decision to approve or reject takes 10-15 seconds.
Personality matters
Penelope isn’t a generic assistant. She has a defined persona: ~30 years old, direct, lives the LATAM tech ecosystem. Speaks Spanish by default, switches to English based on context. Has opinions (“This profile is a strong fit for the regulation episode,” “I don’t think this is a good fit, honestly”). Writes like a person, not a report generator.
What happens with generic AI assistants is they get ignored. The Odisea team uses Penelope because interacting with her feels like interacting with a competent colleague, not a form. The anti-pattern list is as important as the technical integrations: no “Happy to help,” no “Don’t hesitate to reach out,” no parallel lists with caveats everywhere.
Ulises: The Operational Intelligence Agent
Ulises is Penelope’s internal counterpart. While Penelope handles external communication (emails, guests, prospects), Ulises handles internal operational intelligence.
The architecture is different: Ulises doesn’t have a standalone Python codebase. He operates as a Claude Code agent definition with access to MCP tools (Model Context Protocol) for Slack, Notion, and Google Workspace. Lighter, more flexible, and invoked on demand instead of running continuously.
What Ulises does that nobody else was doing: he cross-references information between business units. Odisea has 6 units (podcast, legal tech, DeFi sales, infrastructure, research, Synaptic). A guest researched for the podcast could be relevant to the Pan.Tech sales pipeline. A contact from the research program might have connections to an enterprise prospect. Before Ulises, those connections got lost. Each unit operated with its own database and its own memory.
Ulises reads from multiple Notion databases and agent memory directories. When he detects a connection (a name appearing in both the podcast pipeline and the sales prospect list), he surfaces it in the corresponding Slack channel. The routing rule is strict: all operational messages go through Ulises, all external messages go through Penelope. Never the reverse. This separation prevents context contamination and keeps each agent’s prompt focused.
Pipeline always up to date
Before Ulises, the Notion pipeline was a graveyard of outdated data. Someone created a record when they contacted a guest, but nobody updated it when the guest replied, when the recording got scheduled, or when the episode was published. After 2 weeks, the pipeline no longer reflected reality.
With Ulises, updates are automatic. The pipeline state reflects the real situation at all times. When Penelope processes a confirmation email, the Notion record updates. When a recording gets scheduled, the stage changes. The team has a single, reliable view of all prospects.
Why two agents and not one
The obvious question: if both agents access Slack, Notion, and Gmail, why not consolidate them into one more powerful agent.
The answer comes from experience. An agent with 25+ tools, external and internal responsibilities, a public-facing personality, and operational logic becomes unmanageable. The prompt grows. Routing errors multiply. The agent starts using internal tools in external contexts and vice versa.
Separation of responsibilities works for the same reason it works in human teams. A salesperson who’s also a data analyst, community manager, and scheduling coordinator does all those things poorly. Two specialists with clear roles produce better work than one overloaded generalist.
With Penelope and Ulises, the rule is simple: if the message leaves the organization, Penelope handles it. If the message is internal or analytical, Ulises handles it. No ambiguity, no overlap, no confusion about who said what.
The numbers
Email response time: from days to hours (limited by human approval, not bot speed).
Email exchanges to schedule: from 4-5 to 1.
Tools in production: 14 (Penelope) + full MCP access (Ulises).
Pipeline tracking: from sporadic manual updates to automatic real-time updates.
Cross-unit connections detected: operating daily, surfacing relationships that previously got lost.
Lines of code: ~940 (Penelope). Ulises operates as an agent definition, no independent codebase.
Monthly cost
| Item | Cost |
|---|---|
| Penelope VPS (shared with other services) | ~$12/month |
| Claude API (Sonnet 4.5, ~50-100 conversations/day) | $50-150/month |
| Ulises (on-demand Claude Code usage) | $30-80/month |
| Brave Search API | $0 (free tier sufficient) |
| Total | $92-242/month |
Versus the alternative: a part-time operations coordinator at $1,500-2,500/month. Or the prior situation: nobody coordinating anything, with the invisible cost of lost opportunities and prospects that never got a response.
What this means for a client
This system deploys in 5-9 days:
| Phase | Duration | Activities |
|---|---|---|
| Requirements | 1-2 days | Map email patterns, CRM structure, approval flows |
| Slack setup | 1 day | Create Slack app, Socket Mode, permissions, channels |
| Integrations | 1-2 days | Gmail OAuth, Notion API, Calendar API, web search |
| Persona and prompts | 1-2 days | Define voice, system prompt, tool descriptions, filtering patterns |
| Testing | 1-2 days | End-to-end email flow, CRM operations, scheduling |
What gets customized per client: the agent’s personality, email filtering patterns, CRM structure, Slack channels, approval flows, and inter-agent routing logic. What stays the same: the tool architecture, human approval pattern, conversation threading, and separation of responsibilities between agents.
The result is a 2-agent operations team that runs 24/7, responds in seconds, keeps the pipeline updated without manual intervention, and costs less than a single day of work from a human coordinator per month.
It doesn’t replace the team. It replaces the 40 weekly hours of operational work the team didn’t have time to do.
Synaptic turns overwhelmed teams into AI-native operations. Deployment in 5-9 days. synaptic.so