Functional Overview & Personas

What the VegaDūta platform does, for whom. This section is the functional specification for the product surface: each domain page enumerates capabilities as numbered feature requirements (FR-xxx-nn), states which personas they serve, and marks every item with a status badge so the reader can distinguish shipping software from roadmap.

What the platform does

VegaDūta is a multi-tenant agentic-AI platform. A tenant (a customer organisation) configures AI agents — each with its own model, provider credentials or platform-hosted pool access, tools, skills, memory, reasoning depth and guardrail posture — then exposes those agents to end users through omnichannel messaging (WhatsApp, Telegram, Slack, Email, Voice and five more), through embedded chat surfaces and share links, through workflows that orchestrate agents alongside deterministic steps, and through autonomous jobs that run agents on schedules and event triggers. Knowledge bases give agents grounded retrieval; usage is metered per call; the governance layer wraps every side-effecting tool call in verification, approval and audit machinery. External clients reach the same core through the developer API, A2A and MCP.

Billing and plans are off by default

Billing and plan gating (core/billing, core/payments, plan_limits, an optional Razorpay gateway) exist for operators who run a paid hosted service. For self-hosters they are off: the consoles hide plan and billing surfaces unless NEXT_PUBLIC_BILLING_ENABLED=1 (WEB_BILLING_ENABLED in Compose), and FREE mode resolves every tenant as the top tier for feature gates. Where the pages below mention a plan gate, it only matters if you turn billing on.

flowchart LR subgraph Personas TA["tenant-admin"] AB["agent-builder"] EU["end-customer / channel end-user"] PA["platform-admin"] API["API consumer / external agent"] end subgraph Surfaces WA["web-admin console"] WEB["web end-user app"] CH["10 channel types"] DEV["developer API · A2A · MCP"] end CORE["core/app — Spring Boot modular monolith"] TA --> WA AB --> WA EU --> WEB EU --> CH PA --> WA API --> DEV WA --> CORE WEB --> CORE CH --> CORE DEV --> CORE

Personas reach the same core runtime through different surfaces.

Persona directory

Each persona below maps to a real surface in the repository. "Where they live" names the deployable or module the persona's experience is served from; "what they do" summarises the functional scope detailed in the domain pages.

Persona	Where they live	What they do	Primary spec
tenant-admin	`web` tenant console (`app.<your-domain>`), tenant-scoped APIs	Owns the tenant: invites and roles users, wires channel credentials, approves gated actions in the approval inbox, sets guardrail rules, allow-lists and approval policies, reviews the audit log.	VD-FN-006
agent-builder	`web` agent workbench, workflow canvas, knowledge pages	Creates and versions agents, attaches tools/skills/memory, tunes reasoning depth, designs workflows on the canvas, curates knowledge collections, runs A/B experiments.	VD-FN-001, VD-FN-002, VD-FN-004
delegated-user	`web` tenant console, approval inbox subset	A non-admin tenant member who chats with the tenant's agents, runs workflows they're entitled to, and can approve non-admin-only requests. Cannot approve gated tool calls (tenant-admin only).	VD-FN-001, VD-FN-006
end-customer	Public share links, embedded chat widgets, public ACP commerce feed	An unauthenticated or lightly-identified visitor who talks to a shared/embedded agent, or buys through an agent's checkout surface. No console access.	VD-FN-001
platform-admin	`web-admin` platform console (`admin.<your-domain>`), control-plane APIs	Operates the platform itself (realm role `platform-admin`, granted with `scripts/vegaduta make-admin`): manages the platform LLM provider pool, flips FREE MODE and the platform kill switch, oversees moderation queues across tenants, edits `plan_limits` if billing is on.	VD-FN-006
API consumer / external agent	REST developer API, A2A agent cards, AG-UI run endpoints, MCP server	Programmatic callers — other software or other agents — that invoke agents, runs and workflows over authenticated HTTP/A2A/MCP without using a human UI.	VD-FN-001, API: developer surface
channel end-user	WhatsApp, Messenger, Instagram, Slack, Discord, X, Telegram, Email, Teams, Voice	Messages or calls a tenant's connected number/account and converses with the routed agent. Goes through pairing, session resolution and (optionally) human handoff to an operator.	VD-FN-003

Capability map

Domain page	Doc ID	Scope
Agents & Agent Runtime	`VD-FN-001`	Agent lifecycle, skills, reasoning depths, tools, memory, sharing, A2A/AG-UI, autonomous jobs, vision, crews, edge agents
Workflow Engine	`VD-FN-002`	Definitions and runs, the 18 node types, synchronous + Temporal engines, versioning/diff, triggers, approvals, recovery
Channels & Omnichannel	`VD-FN-003`	The 10 channel types, contacts/routing, pairing and operator inboxes, health, credentials, channel plan gates
Knowledge Base & RAG	`VD-FN-004`	Collections/documents, ingestion and connectors, hybrid search + reranker, agent knowledge tools, graph memory
Governance, Guardrails & Approvals	`VD-FN-006`	Guarded tool pipeline, approval inbox and policies, moderation, Procedures/SOP, audit, kill switches, autonomy tiers

Feature status conventions

Functional items in this section carry one of three statuses, distinct from the site-wide verification badges (which describe whether a doc page was re-checked, not whether a feature shipped):

Status	Meaning	How to recognise it
live	Implemented and enabled by default (or by the Compose profile / flag named on the page).	Default for items in this section unless marked otherwise.
on-main	Merged to `main` and present in the repository, but not yet in a tagged release or not verified end to end — treat as "merged, not necessarily released".	Stated inline where release state was not re-verified.
draft	Authored but never shipped or verified. Aspirational, not real.	Always called out in a warning callout.

Plan-gated features are marked with an info callout naming the plan_limits flag or tier that controls them (see Billing and plans are off by default). Requirements that were verified against source rather than a running deployment cite the file or migration that proves them, e.g. core/agents/.../ReasoningDepth.java or V270__procedures.sql.

Relationship to other sections

Functional pages describe what exists and who uses it. For how it is built see System Architecture; for the exact REST surface see API Overview; for how to enable optional services see the Deployment Guide.