TLDR
What is Subport?
The AI-native support operating system for teams that want conversations to become resolved work.
TLDR
Subport turns repeated customer conversations into governed, resolved work by combining AI agents, tickets, trusted knowledge, workflows, SLAs, integrations, and human handoff in one permission-aware support system.
Most teams do not need another chatbot. They need a support system that remembers customer context, answers from approved knowledge, creates accountable tickets, follows team rules, escalates risky issues, and shows managers where work gets stuck. Subport brings those pieces into one operating layer.
Read the product TLDR →How Subport works
The technical architecture behind AI-native support operations.
TLDR
Subport is a production runtime for AI-powered support operations: persistent multi-tenant state, conversation orchestration, channel adapters, configurable tickets, permission-scoped tools, trusted knowledge retrieval, SLA lifecycle automation, human approvals, notifications, MCP extensibility, and durable workflows in one controlled system.
The technical story is bigger than "AI agent with tools." Subport gives models the infrastructure they need to work safely in support: customer identity, project scope, group permissions, field visibility, ticket lifecycle rules, approved knowledge, channel delivery, SLA timers, human confirmation, audit trails, and operator dashboards.
Read the technical architecture →Subport is a production runtime for AI-powered support operations: persistent multi-tenant state, conversation orchestration, channel adapters, configurable tickets, permission-scoped tools, trusted knowledge retrieval, SLA lifecycle automation, human approvals, notifications, MCP extensibility, and durable workflows in one controlled system.
Subport's technical value lives in the systems that make AI usable in production support. A model can generate a reply. A tool-calling agent can call an API. A support operation needs much more: persistent identity, tenant and project boundaries, channel-specific messaging, ticket lifecycle rules, field-level visibility, knowledge retrieval, SLA timers, assignments, handoffs, notifications, operator dashboards, and audit history.
Subport is built around that operational substrate. Conversations are durable records. Tickets are configurable state machines with definitions, fields, statuses, priorities, assignment, SLA policy, auto-close rules, and activity logs. Knowledge bases use hybrid retrieval so AI answers from approved information. Agents are given tools — filtered by the invoker's permissions, the customer's group, the agent's own capabilities, and the current project context. Sensitive actions pause for confirmation before execution.
The platform abstracts real messaging providers through adapters. Meta WhatsApp, MTalkz and Baileys provide WhatsApp paths; authenticated API chat supports customer-built apps. Slack provides outbound notifications, not an inbound chat channel. Channel identities and threads remain distinct. The workflow foundation adds long-running execution, published snapshots, checkpoints, runtime service adapters, and triggers.
12 pillars
Persistent multi-tenant support state
Workspaces, projects, conversations, customers, tickets, agents, groups, knowledge bases, channel identifiers, and workflow executions persisted as durable state. A conversation can resume after hours or days without losing ownership, history, or context.
Conversation orchestration across channels
Customer and conversation context is preserved across inbound and outbound messages. AI operates with customer identity, channel identity, conversation history, ticket state, project configuration, and available tools.
Channel adapter layer
Real messaging providers are abstracted through adapters. WhatsApp providers and authenticated API chat support conversations, while Slack is outbound-only. The playground is a testing surface. Provider-specific constraints and channel identities remain in effect.
AI execution and structured intelligence
Model/provider execution, structured output, embeddings, conversation analysis, field extraction, tool calling, and prompt/template execution. Models are replaceable execution engines — the runtime is the product.
Permission-aware agent runtime
Tool registration and execution are shaped by project context, customer/user identity, resolved permissions, group membership, agent capabilities, channel verification, and field-level visibility.
Configurable ticket definitions
Category-specific work objects with custom fields, statuses, priorities, UI metadata, validation rules, SLA configuration, auto-close rules, and templates for different domains.
Trusted knowledge retrieval
Keyword, vector, and hybrid search, configurable thresholds, adjacent chunk retrieval, project-wide search, and model-specific embeddings. Answers come from approved knowledge, not generic model recall.
SLA and lifecycle automation
SLA timers, multi-policy evaluation, business-hour behavior, pause/resume on status changes, breach warnings, scheduled checks, auto-close warnings, auto-close execution, notifications, and dashboard visibility.
Human-in-the-loop controls
Human approval is a protocol, not a fallback. Sensitive tool calls create confirmation requests, record decisions, verify arguments, send interactive channel messages, and execute only after approval.
Durable workflow foundation
Published snapshots run through a durable runtime with Postgres-backed execution, checkpointing, payload storage, task bindings, service adapters, triggers, and runtime scope.
MCP and external tool extensibility
MCP tools can be discovered, registered, filtered, rate-limited, and executed for agents — mediated by the platform's permission and runtime model.
Operator UI, observability, and auditability
Queues, dashboards, settings, ticket views, activity history, permissions, knowledge management, agent configuration, workflow execution visibility, and notification history. A control surface for AI-operated work.
Claude Code + MCPs
Claude Code + MCPs excel at task automation. Subport is the infrastructure required to run customer support as a production system: state, permissions, channels, tickets, SLAs, humans, tools, and workflows coordinated across people, teams, and time.
Subport is model-agnostic infrastructure for AI-operated support. The AI model is one component; the technical value is the runtime that gives that model state, tools, permissions, knowledge, human oversight, and operational consequences.
The model can write the answer. Subport makes sure the answer is grounded, authorized, routed, tracked, approved when necessary, and tied to real work.