Roadmap

Direction, not a commitment

The items below describe engineering direction. They are not available today, and nothing here is a commitment to a specific date. Build against what’s documented elsewhere in these docs — this page is a heads-up on where things are headed, not a spec.

Telephony — inbound and outbound calling

Today, a Wetel agent is reachable through the embeddable web SDK (<vai-avatar>) or through a custom UI you build against the GraphQL API. There’s no phone-network integration — an agent can’t currently receive or place a real phone call.

This roadmap item extends the same agent and workflow you already configure to a phone-call channel. The persona, the workflow graph, the session/message model — none of that changes. What changes is the channel a session comes in on: instead of (or alongside) a web embed, a call would start a session the same way, run the same workflow, and produce the same message history you already query today. If you’ve already built a workflow for chat or voice-over-web, the goal is that it works for a phone call with no redesign.

Agent Templates Marketplace

Today, every agent’s persona and workflow is built from scratch: you call createAgent, then build a workflow graph node by node through createWorkflow → updateWorkflow → publishWorkflow. That’s flexible, but it means every new use case starts from a blank canvas.

A templates marketplace would sit on top of that same create → update → publish flow, offering pre-built starting points for common use cases — a persona and a workflow graph you fork and customize instead of assembling from nothing. The underlying API doesn’t change; what’s new is a faster path from “we want an agent for X” to a first working draft, without changing how you’d edit or publish it once forked.

Scheduled and triggered workflows

Today, a workflow run always starts because a message arrived — a user wrote, spoke, or an integration called sdkSendMessage. An agent can’t yet start work on its own.

This roadmap item adds schedule- and event-based triggers to the same published workflow: “every weekday at 9am, check yesterday’s unfiled applications,” or “when a record changes, run this graph.” The graph, nodes and execution trace stay exactly as they are today — only what starts a run changes. It’s the piece that lets an agent pick up recurring work instead of waiting to be asked.

Supervision view

Today, everything an agent did is already recorded — per-node execution traces (workflowRuns), conversation evaluation scores, and spend per tenant — but reading it means querying the API or opening individual runs in the dashboard.

This roadmap item puts that same data into one manager-facing view per agent: what it handled, what it escalated, where it failed, and how that trends over time. No new data is being collected; it’s a readable view over what already exists.

What’s already shipped

This page is intentionally forward-looking. For what’s already built and live, see the Changelog — it tracks real, shipped API changes as they land.