What is Canvass?
Learn what Canvass does, the operating loop, key terms, agent roles, and where to begin as a new user.
Canvass is a signal-driven revenue system by Tech Fabric. Instead of manually building lists and writing cold emails, you define who you want to reach, connect your data sources, and let the system find accounts that have a real reason to hear from you right now.
It watches for relevant market movement (a company hiring a data platform leader, closing a funding round, posting about a migration), remembers every account interaction, judges which opportunities deserve attention, drafts a personalized message from the actual trigger, and learns from what comes back.
It is built for a specific operating principle:
AI can accelerate research, judgment, and language. A human remains accountable for prospect-facing action.
No agent-initiated send leaves Canvass without human approval. That restriction is enforced by workflow and policy code, not by a model instruction.
What problem does it solve?
Traditional outbound is labor-intensive: you research accounts, guess at timing, write generic templates, and send blindly. Canvass changes that by:
- Finding the right accounts automatically — it searches your connected data providers for companies that match your ideal customer profile and have a current buying signal.
- Explaining why now — every recommendation includes the specific trigger (a job posting, a funding round) so you know why this account is worth contacting today.
- Drafting from the real trigger — instead of generic templates, each message references the actual event that made the account relevant.
- Keeping you in control — every draft stops for human review. You can edit, approve, or reject before anything reaches a prospect.
- Learning from outcomes — it tracks which signals and messages correlate with replies and meetings, so your targeting improves over time.
The operating loop
| Stage | Question it answers | Primary implementation |
|---|---|---|
| Sense | What changed in the market? | Apollo or signal adapter |
| Remember | What do we already know about this account? | Tenant-scoped PostgreSQL history |
| Judge | Is this account worth action, and why now? | Claude or heuristic judge |
| Draft | What relevant message follows from the trigger? | Claude drafter and prompt variants |
| Approve | Should this exact action be allowed to continue? | Human decision in Temporal |
| Act | Do suppression, ramp, idempotency, and delivery allow it? | governed action pipeline |
| Learn | Which signals and copy correlate with outcomes? | outcome and variant policies |
Key terms
If you are new to Canvass, these terms appear throughout the documentation:
| Term | Meaning |
|---|---|
| ICP (Ideal Customer Profile) | The versioned policy that defines which companies are eligible for outreach — size, geography, industry, buyer roles, exclusions. |
| Signal | An observable market event that creates a reason to act — a job posting, a funding round, a company change. |
| Verdict | The judge's output: a score, a recommended play, a why now explanation, and a confidence level. |
| Draft | A proposed outreach message with subject and body, generated from the trigger and parked for human review. |
| Touch | A recorded outreach attempt (first touch or follow-up) tied to an account. |
| Play | One of four service plays: Health & Governance, Migration & Modernization, Agent-Ready Data Platform, or Databricks Application Delivery. |
| Proof | A reviewed, approved evidence asset that backs a claim in the outreach message. |
| Suppression | A rule that prevents outreach to specific domains, companies, or contacts (customers, partners, unsubscribes). |
| Dry run | A campaign pass that senses, judges, and drafts but does not send a real message. The safe starting point. |
| Campaign pass | One execution of the sense → judge → draft → approve → act cycle for a campaign. |
| HITL (Human-in-the-loop) | The approval gate where a human reviews and decides on every prospect-facing draft. |
Product surfaces
Canvass keeps the everyday path to seven screens:
- Today ranks work that needs your attention.
- Prospects brings discovery, companies, people, and lists together.
- Campaigns keeps the brief, recipients, emails, review, launch, and activity together.
- Inbox supports reading, replying, and reviewing drafts beside a conversation.
- CRM holds companies, people, deals and their next steps.
- Meetings keeps conversations, transcripts and recordings together.
- Agents connects your harness and shows its activity.
Company & knowledge groups your company context, audience and reusable content. Reports groups results and diagnostics. CRM holds companies, people, deals, tasks and notes; Meetings holds conversations and recordings. Press ⌘K to jump to a destination by name.
Open Agents → Connect an agent to set up your preferred harness and choose its access. Administrators can use Team & agents for advanced access settings. Terminal agents and background workers use the Canvass CLI.
Start with Navigate the application for the full sidebar map and the common operator journeys.
Agent roles
Six specialist roles support the work behind the scenes:
- Signal Scout
- Account Memory
- Opportunity Judge
- Message Drafter
- Human Approval Gate
- Delivery and Learning
These roles do not share unrestricted authority. Each has a narrow contract and feeds a durable workflow. For runtime status and configuration, see Agents.
Portable production foundation
TechFabric production runs the web application and worker as separate Cloudflare Containers, stores authoritative tenant and action state in PostgreSQL, and uses Temporal Cloud for durable orchestration. Fabric Platform governs mutations; Fabric Harness bounds agents; Fabric Experiments supplies quality evidence. Model and provider adapters remain explicit and portable.
A separately certified, customer-managed Databricks target remains available when a customer requires workspace-local identity, data, models, and analytics. It is not a fallback for Cloudflare production. See Application and data architecture.
Identity and tenancy
Better Auth establishes the signed-in person and active organization. GTM access profiles and Fabric Platform policy decide which tenant resources and actions that identity may use. Outside agents have a registration-bound identity and never inherit the administrator's browser session.
Every GTM API read and mutation verifies organization membership. Integration management requires an organization admin. The current application release supports password, email magic-link, and passkey authentication. Google and GitHub social OAuth are deliberately disabled at both the UI and Better Auth provider boundary. Enabling them later requires an explicit release change plus both provider credential pairs; adding credentials alone does not activate either provider.
Choose your starting path
- New user: How it works — a plain-language walkthrough from ICP to leads.
- Revenue operator: Run your first campaign.
- Approver: Human approvals.
- Platform owner: Deployment architecture and Production runbook.
- AI owner: Models and gateways.
- Integration owner: Integrations and credentials.
- External-agent builder: External agent gateway.
- Agent-led GTM owner: Agent-led GTM lifecycle — what agents can do today, what escalates, and which provider boundaries are not yet implemented.
The safest first milestone is a vendor-connected dry run, reviewed against real account signals. Live delivery is a separate, administrator-controlled launch and remains unavailable while the deployment gate is off.