Kargo ARK

Results

• 84% catch rate on inbound RFP (goal: 75%)
• 96% reduction in opportunity creation time (goal: 50%)
• $500K in budget surfaced during beta alone (goal: $150K)

The Problem

Kargo's sales team ran on email. RFPs arrived constantly — buried in threads, attached in every format imaginable, at all hours. Experienced sellers were spending significant time on administrative triage that had nothing to do with selling.

The failure modes were obvious and expensive: - Opportunities missed because a thread got buried over a long weekend - Duplicate entries from different sellers working the same RFP - Manual data entry errors in Salesforce - No scheduling coordination across account teams and time zones

The company had tried bolt-on tools. None of them worked, because the problem wasn't any single step — it was the entire pipeline from inbox to kickoff.

The Approach

I spent the first eight weeks not writing code. Face-to-face interviews with top performers and their reports across the sales org. The goal was to understand how the best sellers actually worked — not the documented process, but the real one.

What I found was a 10-step workflow that nobody had written down, with automation breakpoints at every transition. The sellers knew the steps intuitively. They just couldn't articulate them as a system, and nobody had asked.

I presented the architecture to departmental and executive audiences, refined it on feedback, and got alignment before writing a line of production code.

The Architecture

Pipeline Design

ARK processes email through a 10-stage agentic pipeline, each stage handled by a specialized worker:

1. InboxAgent — Continuously reads a shared inbox for externally-originated threads. Creates thread records, acquires attachments, and spawns pipeline items for each.
2. Pre-filter — Strips internally-originated threads so the pipeline only processes inbound RFP.
3. AttachmentProcessorAgent — Routes items by MIME type. Supported formats go to document processors; unsupported formats advance directly to analysis.
4. Document Processors — Four specialized agents (Word, Spreadsheet, PowerPoint, PDF) perform minimally-destructive format reduction — .docx to .md, spreadsheets to structured text — using python-docx, python-pptx, openpyxl, pypdf, and xlrd. Legacy formats delegate to LibreOffice.
5. Aggregation — Processed items are reassembled at the thread level, prioritizing RFP-named attachments for context window allocation.
6. OpportunityAnalysisAgent — A hybrid scoring stage. A Redis-backed Naive Bayes classifier provides fast, cheap pre-scoring. Threads that clear the keyword threshold move to LLM analysis, which extracts five key fields: advertiser, agency, budget, campaign name, and due date. Low-scoring results are remanded to garbage collection. High-scoring results hit a breakpoint.
7. Slack HITL — The seller gets a Slack message with extracted fields and a binary confirm/reject action. One tap.
8. BreakpointAgent — On rejection: thread marked processed, items flagged for cleanup. On confirmation: root item advances to CRM.
9. CRMAgent — Creates a Prospect-stage opportunity in Salesforce with extracted detail and account teaming. Retries on failure up to a configured limit.
10. GoogleCalendarAgent — Resolves account team availability across time zones and schedules the first available 30-minute kickoff slot.

Orchestration

I evaluated existing orchestration frameworks against four requirements: atomic state transitions, per-stage horizontal scaling, self-healing on agent failure, and deterministic routing without model-driven sequencing. Nothing in the LangChain ecosystem satisfied all four.

I built a bespoke orchestrator instead, which eventually split into two services — Pipeline (state management and routing) and AgentScaling (population control and recovery) — as agent requirements came into focus during development.

Observability

Line-level telemetry for agent failure attribution. A dashboard for pipeline health, throughput, and cost tracking. This wasn't an afterthought — it was how I debugged the system during development and how the team monitored it after handoff.

The Rollout

Testing (2 weeks): Full lifecycle testing with a core team of 10 volunteer sellers. Prompt refinement, agent configuration tuning, and failure mode discovery.

Deployment (2 weeks): Onboarded the remaining 70 sellers (80 total, plus 20 support staff). Continued telemetry work and built a utility API for authentication and data access by other internal projects.

Executive presentation: Co-developed and co-presented the live product to 23 of 25 Kargo executives in person.

Handoff (4 weeks): System documentation, architecture walkthroughs in twice-weekly sessions with the handoff resource, repo cleanup, and removal of orphaned code.

Technology Stack

• PHP 8+ — Core application logic, PSR-4 autoloading
• PostgreSQL — Pipeline state, transaction safety
• Redis — Distributed locks, agent coordination, Naive Bayes classifier, configuration caching
• Amazon EFS — Attachment storage
• Python — Document processing agents
• Anthropic Claude / OpenAI GPT — Opportunity analysis and extraction
• Gmail API — Inbox ingestion
• Salesforce API — CRM integration
• Google Calendar API — Cross-timezone scheduling
• Slack API — Human-in-the-loop confirmation

What I Learned

The hardest part of this project wasn't the code. It was the eight weeks of interviews that preceded it. Sellers don't think in pipelines — they think in relationships and urgency. Translating that into a deterministic system without losing the judgment calls that make good sellers good was the actual engineering problem. The Slack HITL exists because I learned that the right automation isn't full automation — it's removing everything except the decision. ~