Revenue Intelligence Platform with Ambient AI Agents

tabs · Finance · 2024 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (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: B2B revenue operations automation

Tabs wanted to automate revenue operations for lean B2B finance teams by extracting contract data, hydrating a commercial graph, and running ambient agents for billing, collections, reporting, and customer communications.

Constraints:

• Finance teams are lean and often rely on outsourced tactical operators.
• The system must operate through existing communication channels such as Slack, Teams, and email rather than a separate chat UI.
• Agents need relevant contract, usage, sentiment, change, and communication data from a large commercial graph.
• Human review remains important for trust, learning, and correcting repeated mistakes.
• Memory and retrieval must be enterprise-specific because each customer has different business practices.

Architecture

Tabs builds a vertical revenue-intelligence platform around a commercial graph. Contracts are extracted into structured relationship data, invoices and revenue workflows are generated from that graph, and ambient/background agents monitor Slack, Teams, email, schedules, and customer communication to trigger finance workflows. The architecture emphasizes graph hydration, retrieval of relevant context, human-in-the-loop corrections, and eventual workflow-specific memory rather than a generic chat interface.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  A["Contracts and customer records"] --> B["Commercial graph"]
  B --> D["Ambient revenue agents"]
  C["Slack and email event channels"] --> D
  D --> E["Human finance team"]
  E --> F["Retrieval and memory layer"]
  F --> B
  F --> D
  D --> G["Revenue operations outputs"]
  G --> E

Components

Data flow

Contracts and customer relationship data are extracted into a commercial graph. The graph is hydrated with contract terms, customer sentiment, usage data, agreement changes, and communications. Ambient agents listen to Slack/email/scheduled events, retrieve relevant graph context, draft or execute revenue workflows, and pass decisions or drafts through human interaction patterns that can be reflected back into the graph as memory for future runs.

Why this architecture

Tabs chose a vertical graph-plus-ambient-agent architecture because generic document extraction was expected to commoditize. The durable value sits in domain data, graph hydration, workflow-specific retrieval, and interaction loops that let finance users supervise agents in the channels where revenue work already happens.

Models used: LLMs · Ambient agents

Scale

• Tabs targets lean B2B finance teams around the $50 million revenue scale.
  “you can think of a $50 million revenue B2B company has probably one VP of finance and maybe uh maybe someone in the Philippines that's doing all of the billing.”transcript, stated
• The founding team spent the first three months on CFO interviews before writing code.
  “for the first 3 months of our um existence, I didn't write a single line of code.”transcript, stated
• Revenue agents must account for invoice value differences from $100 to $100,000.
  “one of them's 10 a $10,000 invoice that might get paid and $100,000 or a $100 invoice that is definitely”transcript, stated

Alternatives considered (roads not taken)

Build only document extraction

Rejected because: Tabs believed extraction and retrieval would become commoditized, so the product needed vertical workflow value.

Expose agentic workflows through a chat UI

Rejected because: Tabs designed agentic work to happen ambiently in Slack, Teams, email, and scheduled processes instead.

Make agents fully autonomous immediately

Rejected because: The speaker argues human-in-the-loop remains important for trust, result quality, and learning from corrections.

Patterns

tool-use-orchestration (orchestration)

Tabs frames revenue agents as workflow executors that act on contracts, invoices, communications, Slack, email, and scheduled triggers rather than standalone chat responses.

agent-memory (memory)

Tabs treats memory as customer-specific learned behavior that should be stored in or retrieved through the commercial graph so agents stop repeating corrected mistakes.

human-in-the-loop-gate (governance)

Human review and edits are part of the agent loop, both to build trust and to provide learning signals for future runs.

rag-retrieval (retrieval)

The commercial graph creates a retrieval problem: select the relevant contract, usage, sentiment, communications, and change data for each revenue task.

context-engineering (context)

Tabs explicitly focuses on structuring, pruning, and retrieving the right graph context for each agent run rather than stuffing every hydrated fact into the prompt.

Tradeoffs

Product wedge

Chose vertical revenue-intelligence workflows on a commercial graph over generic contract extraction.

Rationale: The founders believed generic extraction would commoditize, while domain data and workflows would create durable value.

User experience

Chose ambient Slack/email/scheduled workflows over a chat interface for agentic work.

Rationale: Finance work already happens through communication channels and scheduled processes, so agents should live there.

Graph hydration strategy

Chose gather broad data first and solve retrieval/pruning iteratively over only storing data already known to be relevant.

Rationale: Tabs sees relevance selection as the harder problem and wants enough graph context available for future agent tasks.

Gotchas (what bit them)

Document extraction alone was not enough of a product moat.

Root cause: The founders expected extraction and retrieval to become commoditized after the ChatGPT wave.

Resolution: Tabs focused on a specific vertical, commercial graph, and revenue workflows around the extracted data.

Hydrating the graph creates a retrieval problem.

Root cause: B2B relationships contain too much possible context across sentiment, usage, contracts, changes, and customer communication.

Resolution: Prioritize structuring, pruning, and first-version retrieval before trying to build generalized memory.

Ambient agents still need human feedback to avoid repeating mistakes.

Root cause: Independent agents need to learn what a given CFO or enterprise wants, and that learning comes from interaction.

Resolution: Keep users in the loop through Slack/email/draft-edit patterns and reflect corrections into memory or the graph.

Evaluation

The transcript does not present formal eval metrics for Tabs' agents. It evaluates the design qualitatively around customer discovery, ability to run revenue workflows, relevance retrieval, human feedback, and whether agents trend in the right direction for customers.

Metrics: Three months of CFO interviews before writing code · Customer expectation that agents trend in the right direction · Reduction in repeated human corrections as memory/retrieval improves

Outcomes

• Tabs pivoted from extraction toward a vertical revenue-intelligence platform.
• The platform centers on a commercial graph rather than a generic document-processing layer.
• Agentic experiences are ambient rather than chat-first.
• The team identified retrieval, graph structuring, pruning, and workflow-specific memory as core production challenges.

The target operating model is lean B2B finance teams, including $50M revenue companies with one VP of finance and limited tactical operators, using agents across billing, collections, reporting, and customer communication.