# Feature Research **Domain:** AI workforce platform — channel-native AI employees for SMBs (Slack + WhatsApp) **Researched:** 2026-03-22 **Confidence:** MEDIUM-HIGH (WebSearch verified against multiple sources; some claims from single sources flagged) --- ## Feature Landscape ### Table Stakes (Users Expect These) Features users assume exist. Missing these = product feels incomplete or unprofessional. | Feature | Why Expected | Complexity | Notes | |---------|--------------|------------|-------| | Natural language conversation in-channel | Core promise: AI employee lives in Slack/WhatsApp. No NL = no product. | MEDIUM | Must handle message threading, @mentions, DMs, and group channels | | Persistent conversational memory | Users expect the AI to remember prior context within and across sessions. A "goldfish" agent feels broken. | MEDIUM | Sliding window (short-term) + vector search (long-term) required | | Human escalation / handoff | Users must be able to override or transfer to a human. Especially required for WhatsApp per Meta's 2026 policy (non-compliant without it). | MEDIUM | Full chat history must transfer with the handoff; clean no-overlap handover | | Role and persona configuration | Customers need to define what the AI employee does, its tone, its name. Without this it's a generic bot, not "their" employee. | LOW | YAML/form-based config: name, role description, system prompt | | Tool / integration capability | An AI that only talks but can't DO anything (look up a ticket, book a calendar slot) has minimal value for SMBs. | HIGH | Requires tool registry, sandboxed execution, defined tool schemas | | Admin portal for configuration | Operators need a UI to set up and manage agents. CLI-only = early adopter only. | HIGH | Tenant CRUD, agent config, channel connection, basic monitoring | | Multi-tenant isolation | Platform SaaS: Tenant A must never see Tenant B's data or conversations. | HIGH | PostgreSQL RLS at minimum; enforced at every layer | | Subscription billing | SaaS businesses must accept payment. No billing = no revenue = not a product. | MEDIUM | Stripe integration, plan management, upgrade/downgrade flows | | Slack integration (Events API + Socket Mode) | Slack is the primary channel for v1. Must support @mention, DM, channel messages, thread replies. | MEDIUM | slack-bolt handles Events API; Socket Mode for real-time without public webhook | | WhatsApp Business API integration | WhatsApp is second channel for v1. 3B+ users globally, dominant for SMB-to-customer and team comms. | MEDIUM | Cloud API (Meta-hosted) preferred over on-prem. Per-message billing since July 2025. | | Rate limiting per tenant | Without limits, one misbehaving tenant can degrade service for all others. Platform-level hygiene. | LOW | Token bucket per tenant + per channel; configurable hard limits | | Audit log for agent actions | SMBs want to know what the AI did. Required for debugging, trust-building, and future compliance. | MEDIUM | Every LLM call, tool invocation, and handoff should be logged with timestamp + actor | | Structured onboarding flow | Operators won't configure agents if setup is painful. Wizard-style onboarding is expected by SMB tools. | MEDIUM | Channel connection wizard, agent role setup, first-message test — all in portal | --- ### Differentiators (Competitive Advantage) Features that set Konstruct apart. Not universally expected but create defensible advantage. | Feature | Value Proposition | Complexity | Notes | |---------|-------------------|------------|-------| | True channel-native presence (not a dashboard) | Competitors (Lindy, Sintra, Relevance AI) all require a separate UI. Konstruct's AI lives IN the channel. Zero behavior change for end users. | HIGH | The entire architecture is built for this — gateway normalization, channel adapters, in-thread replies | | Single identity across channels (Slack + WhatsApp as same agent) | "Mara" responds on Slack during office hours and WhatsApp during off-hours — same agent, same memory, same persona. Competitors don't offer cross-channel identity. | HIGH | Requires unified memory store keyed to agent ID, not channel session | | Tiered multi-tenancy with upgrade path | Starter (RLS) → Team (schema) → Enterprise (dedicated namespace). Competitors are one-size-fits-all. Enables SMB-friendly pricing that scales to enterprise. | HIGH | RLS for v1; schema isolation in v2. Architecture must account for future upgrade path. | | LLM provider flexibility (local + commercial) | BYO model or use platform models. Privacy-conscious SMBs can stay on-prem (Ollama). Cost-sensitive ones use smaller models for simple tasks. No competitor offers this at SMB scale. | HIGH | LiteLLM router handles provider abstraction. BYO API keys in v2. | | Agent-level cost tracking and budgets | Paperclip-inspired: per-agent monthly budget with auto-pause at limit. SMB operators want cost predictability — they hired an "employee," not a runaway credit card. | MEDIUM | Track LLM tokens per agent per tenant. Surface in portal dashboard. | | Coordinator + specialist team pattern (v2) | One "coordinator" agent routes to specialist agents. Enables AI departments, not just individual employees. Market gap identified by TeamDay.ai research — no platform does this for SMBs. | VERY HIGH | v2 feature. Requires inter-agent communication, shared context, audit trail for delegation. | | Self-hosted deployment option (v2+) | Enterprise and compliance-sensitive customers can run their own Konstruct. No other SMB-focused competitor offers this. Differentiated vs. SaaS-only solutions. | VERY HIGH | Helm chart + Docker Compose package. Deferred to v2+. | | Pre-built agent role templates (v3) | "Customer support lead," "sales development rep," "project coordinator" — pre-configured roles reduce time-to-value. Competitors require extensive config (Lindy = "days or weeks" of setup). | MEDIUM | v3 marketplace. Platform must support importable agent configs first. | | Sentiment detection and auto-escalation | Agent detects negative sentiment or frustration and proactively escalates before the customer asks. Competitors handle explicit escalation triggers; proactive sentiment escalation is rare. | HIGH | Requires sentiment scoring in message processing pipeline. Configurable thresholds. | --- ### Anti-Features (Commonly Requested, Often Problematic) Features that seem good but create problems when built too early or built wrong. | Feature | Why Requested | Why Problematic | Alternative | |---------|---------------|-----------------|-------------| | Open-ended general-purpose chatbot on WhatsApp | "Let users ask anything" seems like maximum flexibility | Meta banned general-purpose bots on WhatsApp Business API (effective Jan 2026). Violates ToS and risks account suspension. | Scope agents to specific business functions (support, sales, ops). Use intent detection to handle off-topic gracefully. | | Real-time streaming token output in chat | Feels more responsive and "alive" | Slack and WhatsApp do not support partial message streaming — you can only update a message after initial send. Streaming architecture adds complexity for zero user benefit in these channels. | Send complete responses. Use typing indicators during generation. | | Full no-code agent builder for customers | "Let customers build their own agents" reduces support burden | Premature abstraction. If core agent quality isn't proven, giving customers a builder produces bad agents and they blame the platform. Increases surface area dramatically before PMF. | Provide config-based setup (YAML/form) with guardrails. Add builder UX in v2 after workflows are understood. | | Autonomous multi-step actions without confirmation | Fully autonomous "just do it" appeals to power users | SMBs have low tolerance for irreversible mistakes. Gartner: 40%+ of agentic AI projects cancelled. Trust must be built incrementally. | Support human-in-the-loop confirmation for consequential actions (send email, create ticket, book meeting). Make it opt-out, not opt-in. | | Cross-tenant agent communication | "Marketplace scenario: agents from different companies collaborating" | Major security and isolation violation. No current compliance framework supports it. Creates massive liability. | Keep agents strictly tenant-scoped. Marketplace is about sharing templates, not live agent-to-agent communication. | | Voice/telephony channels (Twilio integration) | Broadens market reach | Completely different technical stack, latency requirements, and regulatory environment (TCPA, call recording laws). Dilutes focus before channel-native messaging is proven. | Defer to v3+. Validate Slack + WhatsApp first. | | Dashboard-first UX (separate webapp for users to talk to AI) | Familiar pattern from other SaaS | Defeats the core value proposition. Konstruct's differentiator is zero behavior change — agent lives in existing channels. A separate dashboard makes Konstruct just another chatbot SaaS. | Keep all agent interactions in the messaging channel. Portal is for operators only, never for end-user conversations. | | Context dumping (all docs into vector store at once) | "The more context the better" | Research shows context flooding degrades LLM reasoning. Indiscriminate RAG causes hallucinations and irrelevant responses. | Implement selective retrieval with relevance scoring. Start with narrow, high-quality knowledge sources. Add context hygiene controls in admin portal. | --- ## Feature Dependencies ``` [Slack Integration] └──requires──> [Channel Gateway (normalize messages)] └──requires──> [Unified Message Format (KonstructMessage)] [WhatsApp Integration] └──requires──> [Channel Gateway (normalize messages)] └──requires──> [Unified Message Format (KonstructMessage)] [Conversational Memory] └──requires──> [Tenant-scoped conversation store (PostgreSQL)] └──requires──> [Vector store for long-term memory (pgvector)] [Tool / Integration Capability] └──requires──> [Tool Registry] └──requires──> [Sandboxed Execution Environment] └──requires──> [Agent Orchestrator (decides when to call tools)] [Agent Orchestrator] └──requires──> [LLM Backend Pool (LiteLLM)] └──requires──> [Conversational Memory] └──requires──> [Tool Registry] [Multi-tenant Isolation] └──requires──> [Tenant Resolution (Router)] └──requires──> [PostgreSQL RLS configuration] └──requires──> [Per-tenant Redis namespace] [Subscription Billing] └──requires──> [Tenant management (CRUD)] └──requires──> [Stripe integration] └──enhances──> [Agent-level cost tracking] [Admin Portal] └──requires──> [Tenant management (CRUD)] └──requires──> [Agent configuration storage] └──requires──> [Channel connection management] └──requires──> [Auth (NextAuth.js / Keycloak)] [Human Escalation / Handoff] └──requires──> [Audit log (context must transfer)] └──requires──> [Configurable escalation rules in agent config] [Agent-level Cost Tracking] ──enhances──> [Subscription Billing] [Audit Log] ──enhances──> [Human Escalation] [Audit Log] ──enhances──> [Admin Portal monitoring view] [Coordinator + Specialist Teams (v2)] └──requires──> [Single-agent orchestrator (v1) proven stable] └──requires──> [Inter-agent communication bus] └──requires──> [Shared team context store] [Cross-channel Identity (same agent on Slack + WhatsApp)] └──requires──> [Agent memory keyed to agent_id, not channel session_id] └──requires──> [Both channel integrations working] [Self-hosted Deployment (v2+)] └──requires──> [All v1 services containerized] └──requires──> [Helm chart or Docker Compose packaging] └──requires──> [External secrets management documented] ``` ### Dependency Notes - **Channel integrations require Channel Gateway:** All Slack/WhatsApp adapters must normalize to KonstructMessage before reaching any business logic. This isolation is what enables future channels to be added without touching the orchestrator. - **Agent Orchestrator requires LLM Pool:** The orchestrator cannot function without a working LiteLLM router. LLM Pool is a prerequisite, not a parallel track. - **Human handoff requires Audit Log:** The full conversation context (including tool calls) must be available at handoff time. Audit Log is not just a compliance feature — it's operationally required. - **Coordinator teams (v2) require stable v1 single-agent:** Multi-agent coordination multiplies failure modes. The single-agent path must be reliable and instrumented before introducing delegation. - **Cross-channel identity requires memory keyed to agent_id:** If conversation history is stored per-channel-session rather than per-agent, the same agent on two channels will have fragmented memory. This is an architectural decision that must be correct in v1. --- ## MVP Definition ### Launch With (v1 — Beta-Ready) Minimum viable product to validate the channel-native AI employee thesis with real paying users. - [ ] Slack integration (Events API + Socket Mode via slack-bolt) — primary channel, where SMB teams work - [ ] WhatsApp Business Cloud API integration — secondary channel, massive business communication reach - [ ] Channel Gateway with unified KonstructMessage normalization — architectural foundation for future channels - [ ] Single AI employee per tenant with configurable role, persona, and tools — prove the core thesis - [ ] Conversational memory (sliding window + pgvector long-term) — agents must remember; goldfish agents get churned - [ ] Tool framework with at least 2-3 built-in tools (web search, knowledge base search, calendar lookup) — agent must DO things, not just chat - [ ] Human escalation / handoff with full context transfer — required for trust, required for WhatsApp ToS compliance - [ ] LiteLLM backend pool (Ollama local + Anthropic/OpenAI commercial) — cost/quality flexibility - [ ] Multi-tenant PostgreSQL RLS isolation — prerequisite to accepting multiple real customers - [ ] Admin portal: tenant onboarding, agent config, channel connection wizard — operators need a UI, not config files - [ ] Stripe billing integration (subscription plans) — no billing = no revenue = not a real product - [ ] Rate limiting per tenant + per channel — platform protection before accepting real users - [ ] Audit log for agent actions — debugging, trust-building, future compliance foundation - [ ] Agent-level cost tracking — SMB operators need cost predictability; surfaces in portal dashboard ### Add After Validation (v1.x) Features to add once core is stable and validated with early users. - [ ] BYO API key support — validated demand from privacy-conscious or cost-sensitive customers - [ ] Additional channels (Mattermost, Telegram, Microsoft Teams) — after Slack + WhatsApp patterns proven - [ ] Cross-channel agent identity (same agent memory across Slack + WhatsApp) — architectural upgrade once both channels are stable - [ ] Sentiment-based auto-escalation — requires volume of real conversations to tune thresholds - [ ] Pre-built tool integrations (Zendesk, HubSpot, Google Calendar) — validated by what tools early users actually request - [ ] Agent analytics dashboard in portal — requires baseline data from real usage ### Future Consideration (v2+) Features to defer until product-market fit is established. - [ ] Multi-agent coordinator + specialist team pattern — complex orchestration only after single-agent is proven - [ ] AI company hierarchy (teams of teams) — organizational complexity requires strong single-agent foundation - [ ] Self-hosted deployment (Helm chart) — compliance-driven demand; validate SaaS first - [ ] Schema-per-tenant isolation (Team tier) — upgrade from RLS when scale requires it - [ ] Agent marketplace / pre-built role templates — requires understanding of what roles customers actually use - [ ] White-labeling for agencies — secondary market; validate direct SMB first - [ ] Voice/telephony channels — completely different stack; defer until messaging is proven --- ## Feature Prioritization Matrix | Feature | User Value | Implementation Cost | Priority | |---------|------------|---------------------|----------| | Slack integration | HIGH | MEDIUM | P1 | | WhatsApp integration | HIGH | MEDIUM | P1 | | Channel Gateway (normalization) | HIGH (architectural) | MEDIUM | P1 | | Conversational memory | HIGH | MEDIUM | P1 | | Human escalation / handoff | HIGH | MEDIUM | P1 | | Single agent per tenant (config + orchestration) | HIGH | HIGH | P1 | | Multi-tenant isolation (RLS) | HIGH (invisible, but critical) | HIGH | P1 | | Admin portal (onboarding + agent config) | HIGH | HIGH | P1 | | Stripe billing | HIGH | MEDIUM | P1 | | LiteLLM backend pool | HIGH (architectural) | MEDIUM | P1 | | Tool framework (registry + execution) | HIGH | HIGH | P1 | | Rate limiting | MEDIUM | LOW | P1 | | Audit logging | MEDIUM | MEDIUM | P1 | | Agent cost tracking | MEDIUM | MEDIUM | P2 | | BYO API keys | MEDIUM | MEDIUM | P2 | | Cross-channel agent identity | MEDIUM | HIGH | P2 | | Sentiment-based auto-escalation | MEDIUM | HIGH | P2 | | Pre-built tool integrations (Zendesk, HubSpot) | MEDIUM | MEDIUM | P2 | | Multi-agent coordinator teams | HIGH (v2) | VERY HIGH | P3 | | Self-hosted deployment | MEDIUM (v2+) | HIGH | P3 | | Agent marketplace / templates | MEDIUM (v3) | MEDIUM | P3 | **Priority key:** - P1: Must have for v1 beta launch - P2: Should have, add after v1 validation - P3: Future roadmap, defer until PMF established --- ## Competitor Feature Analysis | Feature | Lindy / Relevance AI | Sintra | Agentforce (Salesforce) | Paperclip.ing | Our Approach | |---------|----------------------|--------|-------------------------|----------------|--------------| | Channel-native presence | No — separate dashboard UI | No — separate UI | Partial — Slack only via enterprise plan | No — orchestration layer only (uses OpenClaw as channel layer) | Yes — primary value proposition; agents live IN Slack/WhatsApp | | SMB pricing | $49+/month, usage-based | $97/month flat | Enterprise pricing ($150+/user) | Open-source self-hosted | Subscription tiers starting SMB-friendly; transparent per-agent pricing | | Setup time | Days to weeks (no-code builder) | Fast but limited | Weeks (Salesforce ecosystem required) | Fast CLI setup; agents via connected frameworks | Under 30 minutes via wizard onboarding in portal | | Multi-agent teams | Yes (workflow chains) | No (siloed assistants) | Yes (enterprise) | Yes (org chart of agents) | v2 — single agent for v1, teams in v2 | | Memory / conversation history | Yes (varies by plan) | Limited | Yes (Slack Enterprise Search + CRM) | Yes (persistent agent state) | Yes — sliding window + pgvector long-term; cross-channel memory in v1.x | | Tool integrations | 1,600+ (Lindy) | Limited | Salesforce CRM native | Any HTTP webhook / bash | Start with essential SMB tools; expandable registry | | BYO LLM models | Partial | No | No (Salesforce models only) | Yes (any agent framework) | Yes — LiteLLM abstracts providers; BYO keys in v2 | | Self-hosted option | No | No | No | Yes (MIT license) | v2+ (Helm chart) | | Human escalation | Yes | Limited | Yes | No (out of scope) | Yes — required for WhatsApp ToS and trust | | Audit trail | Partial | No | Yes (enterprise) | Yes (ticket system, tool-call tracing) | Yes — every action logged; surfaces in admin portal | | Multi-tenancy (SaaS) | Yes | Yes | Yes (enterprise) | No (single-tenant self-hosted) | Yes — PostgreSQL RLS v1, schema isolation v2 | | Cost tracking per agent | No | No | Limited | Yes (per-agent budgets) | Yes — adopting Paperclip's budget model; surface in portal | --- ## Critical External Constraint: WhatsApp 2026 Policy **HIGH confidence** — verified against Meta's official policy rollout (effective January 15, 2026): Meta banned open-ended general-purpose chatbots on the WhatsApp Business API. Agents must serve **specific business functions** (customer support, order tracking, lead qualification, booking). This constraint shapes how agent roles are defined and marketed: - Agent personas must be scoped to a business domain (support, sales, HR, ops) - "Ask me anything" configurations must be blocked or warned against in the admin portal - Escalation to humans is implicitly required for compliance (unresolvable queries must have an out) - General-purpose Q&A capabilities (weather, general knowledge) should be disabled in the WhatsApp adapter or gracefully declined This is not optional — violating it risks WhatsApp Business account suspension. --- ## Sources - [TeamDay.ai: AI Employees Market Map 2026](https://www.teamday.ai/blog/ai-employees-market-map-2026) — Platform comparison, market gap analysis (MEDIUM confidence — single source, industry blog) - [Paperclip.ing](https://paperclip.ing/) — Feature reference for AI workforce orchestration, cost tracking model (HIGH confidence — official source) - [OpenClaw: Multi-Channel AI Agent](https://openclaw.ai/) — Channel-native agent reference implementation (MEDIUM confidence — official source) - [Respond.io: WhatsApp General Purpose Chatbots Ban](https://respond.io/blog/whatsapp-general-purpose-chatbots-ban) — WhatsApp 2026 AI policy details (HIGH confidence — verified against Meta policy dates) - [Composio: Why AI Agent Pilots Fail 2026](https://composio.dev/blog/why-ai-agent-pilots-fail-2026-integration-roadmap) — Anti-patterns, failure modes (MEDIUM confidence — industry report) - [Kore.ai: Navigating Pitfalls of AI Agent Development](https://www.kore.ai/blog/navigating-the-pitfalls-of-ai-agent-development) — Agent development pitfalls (MEDIUM confidence) - [Stripe: Framework for Pricing AI Products](https://stripe.com/blog/a-framework-for-pricing-ai-products) — Billing model guidance (HIGH confidence — Stripe official) - [Slack: AI Agent Solutions](https://slack.com/ai-agents) — Slack AI agent capabilities reference (HIGH confidence — official Slack docs) - [Vendasta: AI Employees](https://www.vendasta.com/blog/ai-employee/) — SMB AI workforce patterns (MEDIUM confidence — industry blog) - [HBR: Why Agentic AI Projects Fail](https://hbr.org/2025/10/why-agentic-ai-projects-fail-and-how-to-set-yours-up-for-success) — Anti-pattern validation (HIGH confidence — peer-reviewed publication) --- *Feature research for: AI workforce platform — channel-native AI employees for SMBs* *Researched: 2026-03-22*