We Built an Autonomous Sales Pipeline on a Raspberry Pi

Six AI agents, a cron scheduler, and markdown files. No cloud infra, no SaaS subscriptions, no ops team.

Our outbound sales pipeline runs autonomously on a Raspberry Pi 4 sitting next to our router. Twice a week, a single cron job chains five agents in sequence: market research, lead generation, enrichment, event scouting, and content drafting. A company goes from market signal to scored lead to drafted outreach email in one morning. Every day, a Telegram message lands on our phones with a pipeline digest.

The total hardware cost was EUR 80. Electricity is rounding error.

We built this because we needed to acquire new clients while running a profitable services business with no dedicated sales staff. What we ended up with taught us more about AI agent architecture than any tutorial we’ve read.

Six Agents, One Shared Filesystem

The system has six agents: CMO, SDR, Social Media, Events Scout, CTO, and a CEO orchestrator. Each runs as a subprocess spawned by a Python cron script, built on Anthropic’s Claude Agent SDK. Each has a defined role and a defined set of files it can read and write.

The shared state is a directory of markdown files: research/, crm/leads/, outreach/drafts/, content/, events/, reports/. No message queue. No shared memory between agents. They communicate by writing files the next agent reads.

The weekly rhythm is two compressed pipeline runs plus a Friday synthesis:

• Monday 07:00: CMO → SDR → Enrich → Events Scout → Social Media. One cron entry chains all five agents sequentially. A company discovered by the CMO at 07:05 has a scored lead profile, enriched contacts, and a drafted outreach email by mid-morning.
• Thursday 07:00: CMO → SDR → Enrich → CTO. Same research-to-outreach chain, plus a technical blog post draft.
• Friday 16:00: CEO synthesizes everything into a weekly brief, flags items needing partner decisions.

We started with agents spread across the week: CMO Monday, SDR Tuesday, enrichment Wednesday. It was a debugging convenience from early development. When we compressed everything into two sequential pipelines, leads started moving from market signal to outreach draft in hours instead of days. The only real dependency was CMO before SDR, and everything else could run the same morning. If one agent fails mid-pipeline, the rest still run. The fail-forward design means a CMO error doesn’t block Social Media from publishing.

We chose markdown files deliberately. They are human-readable, git-diffable, and debuggable without tooling. When an agent writes a lead profile, you can open it in any text editor and see exactly what it decided and why. This matters more than it sounds when something goes wrong at 03:00 on a Tuesday.

Write Restrictions Are Enforced at the CLI Level, Not the Prompt Level

This took the most iteration to get right.

Early on, agents would write files to wrong directories. The CMO would occasionally emit a lead profile to crm/ when it should have gone to research/. The SDR would try to update content calendars. The errors cascaded because agents downstream would read corrupted state.

The fix was enforcing write restrictions at the process level. Each agent invocation passes --allowedTools flags to the Claude CLI that explicitly enumerate which directories the agent can write to:

• CMO: writes only to research/
• SDR: writes to crm/leads/ and outreach/drafts/
• Social Media: writes to content/
• Events Scout: writes to events/
• CEO orchestrator: writes to reports/ and context/

If an agent attempts to write outside its permitted paths, the tool call is blocked at the permission layer before the filesystem is touched. The restriction is architectural. It cannot be overridden by clever system prompt instructions because it operates below the model layer.

This changed the reliability profile significantly. Agents that can’t corrupt each other’s state are much safer to run unattended overnight.

Scored Leads Flow Automatically From Research to Draft Outreach

The outreach pipeline is the core business function, and it runs end-to-end in a single morning.

First, the CMO produces a market-intel-*.md file with funding signals, job postings, and company news for companies in our target segment. The CMO is a pure research agent. It writes one file and exits.

Minutes later, in the same pipeline run, the SDR reads the CMO output and creates individual lead profiles in crm/leads/. Each profile gets a numeric score (0-100) based on ICP fit criteria: tech stack match, company size, funding stage, growth signals, decision-maker accessibility.

The enrichment agent runs next, still in the same pipeline. For mid-scored leads (40-59), it digs deeper: LinkedIn signals, recent hires, engineering team composition, CTO identity. The score is updated. The profile gets richer. This is the most expensive step in tokens, but it only touches leads that have already cleared the initial threshold.

For leads above the score cutoff, the SDR writes a three-email sequence to outreach/drafts/. Email 1 is the cold opener, tied to a specific signal (a funding announcement, a job posting, a product update). Emails 2 and 3 are follow-ups with soft value adds. The cadence and due dates are tracked inside the lead profile itself.

Leads scoring 70 or above are auto-approved and sent immediately. Leads scoring 60-69 get drafts but wait for a partner to review before sending. Below 40, leads are archived automatically.

Humans Approve Everything With External Consequences

We put approval gates at every point where an error is expensive to reverse, and removed them where speed matters more.

High-confidence leads (score 70+) auto-approve and auto-send. The system drafts the email, marks it approved, and sends it via SMTP, all within the same pipeline run. Partners get a Telegram notification after the fact. They can intervene, but most of the time the scoring is right and the email lands before anyone needs to check.

Mid-scored leads (60-69) get drafts but no auto-approval. These sit in outreach/drafts/ until a partner reviews them. The Telegram bot sends a daily digest: pipeline health, stale leads, follow-ups due today, new drafts pending review.

LinkedIn posts are auto-approved and auto-published. A scheduled script posts them at 09:00 on the right day. Partners see them on LinkedIn and can delete if needed, but we haven’t had to yet.

The CEO agent, which runs Friday, produces a weekly brief that flags decisions requiring human judgment: leads scored 60-69 needing review, proposals ready for partner editing, market shifts that need a strategic call. The brief is a decision document, not a status dump.

The pattern: automate high-confidence actions, gate uncertain ones. Agents handle research, drafting, scoring, scheduling, and sending. Humans handle commitments, approvals for borderline leads, and anything with client-facing consequences.

A Raspberry Pi Forces You to Build Something That Actually Works

We chose a Raspberry Pi 4 (4 GB RAM) for a specific reason: we wanted the system to run 24/7 at near-zero marginal cost, and we wanted to force ourselves to build something lightweight enough that it could.

The constraint shaped the architecture. You can’t run a bloated microservices stack on a Pi. There’s no elastic scaling. You work with what you have: sequential subprocess execution, file I/O, and cron. These constraints pushed us toward simpler designs, which turned out to be more maintainable and easier to reason about.

Memory usage per agent run peaks around 200 MB. A full weekly cycle completes in under 20 minutes. The Pi handles this without stress.

The broader point: if your AI automation requires Kubernetes and a managed database to run, you’ve probably over-engineered it. Start with the minimum that works.

Every Agent Run Is Logged With Token Count and Cost

Every agent run writes a structured log entry: timestamp, agent name, input files read, output files written, Claude API tokens consumed, and approximate cost in USD.

A full weekly cycle costs roughly $2-4 USD in API calls, depending on how many leads need enrichment. We know exactly which agent is spending what. The CMO research step is the cheapest. SDR enrichment is the most expensive.

The logs are also the primary debugging surface. When an agent produces bad output, you can trace the exact files it read, see the token count, and reconstruct what context drove the decision. Structured logs from the start saved us hours of guesswork.

The Fallback Is Bash

The Python SDK orchestrator is the primary execution layer. But every agent function has a bash fallback.

If the SDK breaks or a cron misconfiguration takes down the Python layer, we can run individual agents as plain Claude CLI invocations. The bash scripts don’t have cost tracking or structured logging, but they produce identical file outputs. We’ve used them twice during development: once during an SDK version upgrade, once when the orchestrator cron was broken for a day.

The fallback existing means we’re never blocked. The agents keep running while we fix the orchestrator. This is a better operational posture than depending on a single execution path.

Key Takeaways

• Shared filesystem state with strict per-agent write restrictions is more robust than shared memory for sequential agent pipelines. Files are observable, diffable, and debuggable.
• Tool restrictions enforced at the process level are architecturally stronger than system prompt instructions. The model cannot override what the permission layer blocks.
• Compress your pipeline schedule. We started with agents spread across five days because it was easier to debug. When we chained them into two sequential pipeline runs, lead velocity improved without changing any agent logic. The only real dependency was research before lead gen. Everything else was artificial spacing.
• Tiered approval gates beat blanket approval. High-confidence actions (score 70+) auto-send. Uncertain ones (60-69) wait for a human. This lets you move fast on strong signals without losing safety on borderline decisions.
• Fail-forward pipeline design. If one agent fails mid-chain, the rest still run. A CMO research failure shouldn’t block Social Media from posting. Log the error, continue the pipeline, fix it later.
• Cost logging per agent run from day one. You will want this data earlier than you think.