Building Omega: A Multi-Agent Sales Assistant Embedded in Slack

netguru · Tech · 2025 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Sales workflow automation inside Slack

Netguru built Omega because its scaling sales team had key deal context scattered across Slack, CRM data, call transcripts, shared drives, and process documents. Sales Framework 2.0 was intended to create consistency, but a document on a shared drive was not enough to make the framework part of daily work. Reps still spent time preparing expert calls, organizing project details, reviewing proposals, building feature lists, retrieving documentation, and tracking follow-ups across multiple systems.

Constraints:

• Sales context was distributed across Slack threads, CRMs, call transcripts, and shared drives.
• Sales Framework 2.0 needed to be embedded in the daily workflow rather than left as a separate document.
• The assistant had to work where the team already worked, especially Slack.
• The system needed to combine automation with contextual intelligence, not just generic chat responses.
• Each capability had to be testable and scalable without breaking the rest of the system.
• Production deployment needed secure secrets/configuration handling, CI/CD, monitoring, prompt evaluation, and separation between development and production environments.
• Users needed transparency into what Omega could and could not do to trust AI outputs.

Architecture

Omega is a modular multi-agent Slack assistant for sales workflows. Slack is the user interface. Routing logic interprets intent and delegates work to role-based AutoGen agents: SalesAgent aligns requests with Sales Framework 2.0, PrimaryAgent executes tasks using tools such as Google Drive, Apollo, and BlueDot, and CriticAgent reviews outputs for validation or feedback. Capabilities such as proposal validation, transcript summarization, document generation, deadline tracking, and proposal feature-list creation are implemented as standalone black-box modules. The cloud-native backend runs on AWS Lambda, uses AWS Step Functions for orchestration, retries, and state management, manages infrastructure through Terraform, stores secrets/configuration in AWS Systems Manager Parameter Store, and uses Langfuse, Promptfoo, and CircleCI for monitoring, prompt evaluation/versioning, and CI/CD.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  slack-workspace["Slack workspace"] --> omega-slack-service["Omega Slack service"]
  omega-slack-service --> routing-logic["Routing logic"]
  routing-logic --> salesagent["SalesAgent"]
  salesagent --> primaryagent["PrimaryAgent"]
  primaryagent --> criticagent["CriticAgent"]
  primaryagent --> google-drive-api["Google Drive API"]
  primaryagent --> apollo-api["Apollo API"]
  primaryagent --> bluedot["BlueDot"]
  primaryagent --> standalone-capability-modules["Standalone capability modules"]
  omega-slack-service --> aws-lambda["AWS Lambda"]
  aws-lambda --> aws-step-functions["AWS Step Functions"]
  standalone-capability-modules --> aws-lambda
  terraform-infrastructure["Terraform infrastructure"] --> aws-lambda
  terraform-infrastructure --> aws-systems-manager-parameter-store["AWS Systems Manager Parameter Store"]
  omega-slack-service --> langfuse-monitoring["Langfuse monitoring"]
  promptfoo-evaluation["Promptfoo evaluation"] --> circleci-pipeline["CircleCI pipeline"]
  circleci-pipeline --> terraform-infrastructure
  salesagent --> sales-framework-2-0["Sales Framework 2.0"]

Components

Data flow

A sales rep mentions or interacts with Omega inside Slack. Routing logic interprets the user's intent and assigns the request to the appropriate role-based agent. SalesAgent checks the request against Sales Framework 2.0 and decides next steps. PrimaryAgent carries out the task, using integrations such as Google Drive for documents, Apollo for company enrichment, BlueDot for call transcripts, and Slack for channel/thread interaction. CriticAgent reviews the response and provides validation or feedback. AWS Lambda executes capabilities on demand; Step Functions handles workflows that require orchestration, state, or retries. Langfuse logs LLM inputs/outputs and agent behavior, Promptfoo tests and versions prompts, CircleCI ships changes across environments, and the result returns to Slack in the team's existing workflow.

Why this architecture

Netguru kept Omega inside Slack to avoid adding platform fatigue and to put automation directly where sales reps already coordinate work. Role-based agents split analysis, execution, and review responsibilities. Serverless AWS infrastructure lets capabilities run on demand with low overhead, while Step Functions adds state and retry handling for workflows. Black-box modules isolate capabilities so the team can test, scale, debug, and iterate without breaking the rest of the system. Monitoring, prompt evaluation, CI/CD, Parameter Store, and environment separation were used to make the agent production-ready rather than just a prototype.

Models used: Language model · AutoGen · Langfuse · Promptfoo

Scale

• Omega was built after the sales team scaled and introduced Sales Framework 2.0.
  “As our sales team scaled, we introduced a structured approach—Sales Framework 2.0—to bring consistency and quality to every deal.”article, stated
• Omega operates across multiple sales-process stages inside Slack.
  “Omega now supports our sales team at multiple stages of the sales process—without ever leaving Slack.”article, stated
• Proposal feature lists can be generated in structured formats such as CSV.
  “Based on historical documents and scope inputs, Omega can compile feature lists in structured formats like CSV.”article, stated
• The pattern is positioned beyond sales for customer success, operations, HR, and other repeatable workflows.
  “Sales was just the start. The same logic applies across customer success, operations, HR—anywhere information is scattered and workflows are repeatable.”article, stated

Alternatives considered (roads not taken)

Add more tools or heavier sales processes.

Rejected because: The team instead embedded automation in Slack so reps could get support without leaving their daily workflow.

Build one monolithic assistant capability.

Rejected because: Netguru implemented capabilities as standalone black-box modules to isolate logic, test, scale, debug, and iterate safely.

Adopt complex RAG pipelines early.

Rejected because: The team deliberately started with smart caching, prompt engineering, and simple routing for speed and reliability, adding fallback logic and better routing later as needs grew.

Replace human sales input.

Rejected because: Omega is positioned as a teammate that reduces repetitive work and improves access to information, not a replacement for human judgment.

Start with broad end-to-end automation.

Rejected because: The team says value came from starting with simple, high-frequency, specific problems and iterating with real sales needs.

Patterns

multi-agent-orchestration (agent-architecture)

Omega uses AutoGen role-based agents where SalesAgent analyzes the request, PrimaryAgent executes the task with tools, CriticAgent reviews output, and routing logic assigns intent.

tool-use-orchestration (integrations)

PrimaryAgent uses integrations such as Slack, Google Drive, Apollo, and BlueDot to retrieve documents, enrich proposals, process transcripts, and act inside existing sales workflows.

observability-tracing (operations)

Langfuse logs LLM inputs and outputs and tracks agent behavior over time, giving the team visibility for debugging and impact measurement.

eval-driven-development (quality)

Promptfoo provides prompt testing, evaluation, and version control, while CircleCI carries CI/CD automation across environments.

fallback-degradation (reliability)

Omega avoided complex RAG early, then added fallback logic and better routing as needs grew, so the system could improve without overbuilding the first version.

prompt-versioning (llmops)

Promptfoo is used for prompt testing and version control so prompt behavior can be managed as part of the release workflow.

safety-policy-enforcement (security)

The architecture uses guardrails, black-box module boundaries, Parameter Store for secrets/configuration, and separated dev/prod environments to reduce unsafe model drift and release risk.

Tradeoffs

Embed Omega in Slack.

Chose Slack-native assistance over Adding another sales tool or heavier process layer.

Rationale: Slack placement reduced adoption friction and let the assistant meet the team where coordination already happened.

Use role-based multi-agent orchestration.

Chose SalesAgent, PrimaryAgent, CriticAgent, and routing logic over A single undifferentiated Slack bot.

Rationale: Role separation lets the system analyze framework fit, execute tasks, and review quality as separate responsibilities.

Keep capabilities modular and black-boxed.

Chose Standalone modules for proposal validation, transcript summarization, doc generation, and similar tasks over A tightly coupled feature set.

Rationale: Module isolation made it possible to test, scale, debug, and iterate on one capability without breaking the rest of Omega.

Start with simpler retrieval/routing instead of complex RAG.

Chose Smart caching, prompt engineering, simple routing, then fallback logic and better routing over A complex RAG pipeline in the early stages.

Rationale: The team optimized for fast, reliable early results and only layered in more complexity as needs grew.

Use serverless infrastructure.

Chose AWS Lambda with Step Functions for orchestrated workflows over Managing always-on infrastructure for every capability.

Rationale: Lambda provides on-demand execution with minimal overhead, while Step Functions adds state, retries, reliability, and consistency where needed.

Gotchas (what bit them)

A sales framework does not create consistency unless it appears inside the daily workflow.

Root cause: Sales Framework 2.0 was separate from the places where reps actually prepared calls, reviewed proposals, and coordinated deals.

Resolution: Embed the framework in Slack through SalesAgent-guided assistance.

Scattered sales data slows coordination when timing matters.

Root cause: Relevant information lives across Slack threads, CRMs, call transcripts, and shared drives.

Resolution: Connect Omega to existing systems so it can retrieve context and provide just-in-time support in Slack.

LLMs can drift or hallucinate without boundaries.

Root cause: Model outputs are probabilistic and can move outside expected behavior when guardrails and module boundaries are missing.

Resolution: Use black-box modules, CriticAgent review, guardrails, monitoring, and prompt evaluation to constrain and debug behavior.

Trust requires transparency about capability limits.

Root cause: Users need to know what the agent can and cannot do before they rely on it in real workflows.

Resolution: Communicate early, provide regular updates, and make Omega's operation visible enough to build confidence.

Broad automation can overreach before there is product fit.

Root cause: Trying to automate too much before validating concrete sales needs risks heavier processes and less useful tooling.

Resolution: Start with high-frequency, specific tasks and expand alongside the team's real needs.

Evaluation

Omega uses Promptfoo for prompt testing, evaluation, and version control; Langfuse for logging LLM inputs/outputs and tracking agent behavior; CircleCI for CI/CD; and CriticAgent for output review. The source describes monitoring and continuous improvement but does not provide quantitative accuracy, latency, or adoption metrics.

Metrics: Prompt tests and versioned prompts in Promptfoo · LLM inputs and outputs logged in Langfuse · Agent behavior tracked over time · CI/CD automation across environments · CriticAgent validation of PrimaryAgent output

Outcomes

• Omega evolved from an R&D experiment and basic Slack bot into a working AI sales companion.
• It supports expert-call preparation, sales-conversation summaries, project-document navigation, proposal feature-list generation, and deal-momentum tracking.
• It operates without leaving Slack and integrates with tools the team already uses.
• The article claims improved efficiency, process clarity, continuity, and access to information but does not publish quantitative business metrics.

The source gives qualitative outcomes rather than measured production KPIs. Concrete scope signals are Sales Framework 2.0, multiple sales-process stages, Slack/Drive/Apollo/BlueDot integrations, structured CSV outputs, and potential reuse across customer success, operations, and HR.