Product position and scope

What Veracto is being built to offer, and what remains outside a public product promise.

Status: product direction. This page describes the product boundary Veracto is working toward. It does not claim that every part is available today.

Veracto is being designed as a managed personal agent in Telegram. A person brings work to a familiar chat; the agent uses only the capabilities needed for that task, asks before an external effect, and returns a result that can be understood without reopening the task.

The intended value

The product is built around a simple path:

1. One conversation for the request. A person should be able to state the task plainly instead of assembling a workflow or configuring an agent from scratch.
2. One clear next action. The system should either begin the work, ask for the missing information, or show the specific approval it needs.
3. One checked handoff. The result should say what was produced, what was verified, and what remains uncertain or requires a decision.

This is a direction for the product experience, not a performance guarantee or a statement that every integration is already available.

Where control belongs

The agent should not treat access as implicit. When a task needs a connected source or an external action, the person should be able to see the relevant scope and make a deliberate choice. A richer interface may later show task status, settings, consent, and complex artifacts, while the chat remains the primary place to state intent and receive the final handoff.

What Veracto is not presenting itself as

• A self-hosted framework or an agent builder that customers assemble themselves.
• A claim that every future connector, workflow, or Mini App surface is already released.
• A substitute for explicit consent when an action reads, changes, or sends information outside the conversation.
• A reason to expose internal infrastructure, model configuration, security controls, or operational details in public documentation.

How to read future pages

Public documentation separates current capabilities from proposed product direction and unknown areas that still need evidence. This keeps product language useful without turning research or implementation plans into promises.