Frequently asked questions about Vento

Vento is an AI control and automation platform for building and operating connected systems. Inside a network it brings together agents, software, data, people and physical devices. Unlike an isolated chat, the system persists: it can observe what is happening, make decisions, take actions and keep evolving from a first functional version into a more complete solution.

Vento is for building systems that connect software, artificial intelligence, data, people and physical devices. You can start with a functional first version, test it under real conditions and evolve it into a more complete solution or product. A project can be a dashboard, an automation, an assistant or a system that observes what is happening and acts. Prototyping adds speed; it does not define the limit of Vento.

Vento turns what you describe into a connected system inside a network.

1. 01Tell Vento Agent what you need to happen.
2. 02The agent builds and connects the parts the system needs.
3. 03Test the result with real data and actions and review what was created.
4. 04Keep talking to correct or extend it on the same foundation.

Everything you build remains in the network when you close the chat, and automations can keep running without an open conversation.

Vento combines a no-code entry point with low-code capabilities and developer tools. You can start by describing the system in natural language and working with visual assistants. When you need custom logic, a special integration or an advanced interface, Vento Agent can generate code and a technical user can review and modify it. The technical depth depends on the project, not on a fixed category.

Yes. Vento is an AI control and automation platform: its agents can observe data, decide what to do and coordinate actions, alerts or flows. The automation lives inside a network and can keep operating after the conversation that created it.

Vento can create applications with AI, but it is not just an AI app builder. Inside a network it builds dashboards, public pages, React interfaces, databases, APIs, automations and Node/Express services, and can connect them to agents and physical devices. As of August 2026 it does not generate its own compiled mobile apps; Android and iOS participate as devices through Vento Connect.

Vento is a platform that includes and lets you create agents; it is not a single AI agent. Vento Agent helps you build and modify the system through conversation. Several agents can coexist inside the network, connected to data, tools and devices, including rule-based agents that do not need an LLM.

Yes, you can start creating software in Vento by describing what you need, without writing code from the outset. The agent and the visual interface help you build interfaces, data, pages and behaviours. An unusual integration, an advanced interface or very specific logic may need code and technical review.

Yes. Tell Vento what it should observe, which condition it should evaluate and what action you want to run. Vento Agent can turn that conversation into rules and automations inside the network. Then review and test the flow, especially if it changes data, sends messages or controls devices: talking to AI speeds up construction, but it does not replace validation.

Yes. Vento connects AI agents to data from software, databases, phones and physical devices so they can observe information and trigger actions. AI therefore stops being just a conversation and becomes part of a real system. Compatibility, permissions and safeguards depend on each integration.

Vento differs from an interface-focused builder because it builds and operates the connected system behind the interface. A network can bring together agents, dashboards, pages, databases, APIs, automations and devices such as ESP32, Arduino or Raspberry Pi. The difference is not generating more code, but keeping software, AI, data and the physical world in one operating environment.

A network is your project in Vento: a connected structure made up of nodes that you operate as one system. Each node contributes one part of the project, such as an interface, automation, agent or connection to data and physical devices. You create and operate the network from the Vento workspace. Each network keeps its members, permissions, Vento Credits, plan and limits separate, so independent projects usually live in different networks.

An AI chat exchanges messages and usually generates answers or files. Vento is also used through conversation, but those conversations create and modify a network: the connected project where its data, interfaces, automations, agents and devices remain. Closing the chat does not remove the project or force you to start again; you return to the same network and continue working on it.

A chatbot can help you think, answer questions or generate files, but on its own it does not create or operate the connected system you describe. Vento is also used through conversation, but turns that chat into a network with dashboards, pages, databases, APIs, automations, agents and physical devices. The project can receive data, take actions and keep running after you close the conversation.

Vento asks for a code because the instance is configured in invite-only registration mode. That mode lets the team control access and, in some cases, associate initial credits with the new network. Not every installation works the same way: Vento also supports open or disabled registration. If you have arrived without a code, you need a valid one issued by that instance's administrator.

It depends on how it was created. Vento access codes have a usage limit: the default is one, but the administrator can allow several. They can also have an expiry date or be deactivated. General codes are not tied to an email address; email invitations to a network can be linked to a specific address. If the code has already reached its limit, Vento will reject it.

There is no built-in waitlist in Vento as of 3 August 2026. Access can be open, closed or work through invitation codes, depending on the instance configuration. If cloud.vento.build asks for a code, that means it uses invite-based access; it does not necessarily imply that a waitlist or an automatic entry period exists.

You do not need to download anything to start with Vento's web features: the workspace, Vento Agent and dashboards are used from the browser. You only install an additional component when the project requires it. For example, Desktop Agent connects a PC or a Raspberry Pi, Vento Connect turns your phone into a device, Vento Hub creates a local instance, and LM Studio lets you use local models from node logic or automations.

Vento is used mainly from the web. The network panel, the chat with agents and the building tools work in the browser. You can install Desktop Agent if you want your computer or Raspberry Pi to act as a connected device, or Vento Hub if you need a complete local instance. Those installations are optional to get started and depend on what you want to connect or run.

To use Vento in the cloud you do not install the platform: create an account and sign in from the browser.

1. 01If you need to connect your computer, open "Add Network Element", choose Desktop Agent and download the preconfigured ZIP or use the command Vento provides for Windows, macOS or Linux.
2. 02The package includes the configuration needed to link that machine to your network.
3. 03Vento Hub follows a different process for installing a local instance.

You can download Desktop Agent for Windows from the panel of your own Vento instance.

1. 01In your network, open the option to add a Desktop Agent and choose Windows; Vento offers packages for amd64 and arm64 machines, plus a preconfigured ZIP or a PowerShell command.
2. 02There is no single CDN link: the download is served from the instance so it can include your device's connection configuration.

Yes, you need an account to enter the Vento workspace, create a network and use the agent. You can sign up with email and password, with email verification, or through Google if it is enabled. Some pages, endpoints or chats created with Vento can be shared publicly and used without an account, but that does not grant access to the panel or the network where they were built.

Yes, Vento supports signing up and signing in with Google when the instance administrator has configured Google Sign-In. If the instance works by invitation, it may also ask you for a code even if you use Google. The same email address can link Google access to an existing account. If you do not see the button, use email and password or ask the operator of your instance.

Yes, you can sign up for Vento with a corporate email address as long as you can receive the verification message. You can also use Google if your organisation allows it and the instance has that option enabled. Vento does not currently offer enterprise SSO through SAML or OIDC. If the company needs single sign-on, MFA or additional corporate controls, it should validate those requirements before adopting the platform.

You do not need to know how to code to get started with Vento. You can describe the goal in natural language and use visual assistants to create agents, dashboards, databases, pages and device connections. For uncommon integrations, critical logic or advanced interfaces, technical knowledge helps you review, test and extend the code the agent generates.

Yes, Vento is useful for makers who want to combine electronics, software and artificial intelligence in the same project. It lets you work with ESP32 and Arduino boards, Raspberry Pi, sensors, actuators, dashboards and automations. Some hardware tasks require physical assembly, testing and electrical knowledge; Vento speeds up the work, but it does not replace those checks.

Yes, Vento suits operations teams that need to observe data, coordinate tasks and act on systems from a shared panel. They can build dashboards, connect databases and APIs, schedule automations and link alerts to agents or devices. For critical processes it is advisable to define permissions, tests and manual fallback procedures, because Vento does not currently offer a public SLA or formal development, testing and production environments.

Yes. Developers can use Vento to speed up construction while keeping access to the technical layer. It is also possible to consume or expose APIs and connect Node.js or Python clients. Some surfaces, such as Tasks and Network Apps, are reserved for platform administrators.

Yes, a non-technical person can get started in Vento by talking to the agent and using the visual interface. They can create a first version of a dashboard, a database, a page or an automation without writing code. In those cases, Vento makes collaboration with a technical user easier, but it does not remove the need for review.

Yes. A non-technical person can create a useful project in Vento if they start from a concrete goal, for example visualising data, receiving an alert, organising an inventory or connecting a sensor. The best results come from testing each step with real data and asking for technical help when credentials, complex integrations, electricity or security decisions are involved.

Yes. A technical team can inspect and extend what is created in Vento because the network keeps code, configuration and a Git history. The Changelog panel shows diffs and history, and there are snapshots and node versions to recover earlier states. Some destructive operations and runtime surfaces require administrative permissions.

Yes. You can use Vento for personal projects such as home automation, sensors, irrigation, lighting, bots, dashboards or AI experiments. Before connecting electrical actuators or security systems, apply the physical protections and reviews appropriate to the project.

Yes, Vento can be used to build professional projects such as internal tools, operational dashboards, automations and connected systems. It lets you work with editable code, data, APIs, roles and devices inside a network. Before putting a critical solution into production, validate its security, privacy, backup and continuity requirements: Vento does not currently publish an SLA or certifications, and some capabilities require administrative configuration.

Yes. Vento lets you quickly build a functional first version for a client and test it with real data, interfaces and devices. The prototype can keep evolving, but before delivering it as a product it is advisable to agree on hosting, permissions, data ownership, support and dependencies on the Vento runtime.

Yes. With Vento you can create internal tools that combine forms, dashboards, databases, APIs, agents and automations. For sensitive information or critical processes, the company should review the access model, the AI providers and the data policy before loading real information.

You can start with one of the examples in Vento's assistant: connect an ESP32 to read temperature, create an agent that watches a camera, or count visits on a dashboard. You can also add a template for an agent, database, page, device or blank node. Choose a small, measurable result, test it and ask Vento Agent to suggest the next steps on top of what you have already built.

With Vento you can create systems that combine agents, software, data and devices. These include dashboards, web pages, internal tools, inventories, Telegram bots, automations, APIs, databases, camera monitoring, irrigation and sensor control. Vento does not currently generate its own compiled mobile apps or offer an online shop with integrated checkout.

Vento is an especially good fit for projects where data, artificial intelligence and actions need to be connected: operational dashboards, internal assistants, automations, bots and systems with sensors or devices. It is also useful when you want to go quickly from an idea to a functional first version and keep evolving it. It adds the most value when the system needs to observe, decide and act, not just display a static interface.

Yes. Every Vento node can include a dashboard view for presenting data and controls, in addition to a visual canvas and a flow graph. The dashboard lives inside the network and requires workspace access; if you need to share a view without an account, you can build a public HTML page connected to the permitted data or actions.

Yes. Vento can create public HTML pages served from your network, a landing page for visitors, custom React views and embeddable web chats. They are hosted under the Vento instance's domain; there is currently no built-in flow for deploying them to Vercel or assigning a custom domain to each network.

Vento can build a shop's catalogue, inventory, pages and logic, but it does not currently offer an e-commerce checkout or a payment integration for end customers. That is why it is not an e-commerce platform ready to sell on its own. You could connect it to external services through APIs and custom development, as long as you validate payments, security, taxes and compliance outside Vento.

Yes. With Vento you can create an inventory system by combining a database, forms, a dashboard and automations. There is no packaged inventory product: the agent builds the solution around your fields, rules, users and integrations.

Yes, you can build a basic CRM or an internal sales tool with Vento databases, forms, dashboards, agents and automations. It is also possible to connect the APIs of an external CRM. For personal data or real sales activity, review the privacy and security requirements first.

Vento can serve as the foundation for a predictive maintenance system: it collects time series, visualises signals, runs logic and generates alerts or actions. However, it does not include a ready-to-use industrial predictive model. Before acting on machinery, validate the results with specialists and keep independent protections in place.

Yes. Vento lets you create internal agents connected to databases, APIs, documents and network actions. Before giving them access to company data, limit which resources they can read, review the actions they execute and determine what information is sent to AI providers. Sensitive data requires a specific privacy assessment.

Yes. With Vento you can create a bot that queries your business databases or APIs and replies through a channel such as Telegram. You should store tokens as secrets, limit the available actions and decide what information each bot user can see.

Yes. A Vento node can work as an operational control panel with real-time data, tables, maps, cameras, indicators and actions. The dashboard view inside the workspace requires an account; for a public or external panel you need to build an HTML page and expose only the authorised data and actions.

Yes. In Vento you can create an internal app with React interfaces or HTML pages, databases, APIs and automations. A Node/Express Network App is also possible, but creating one requires platform administrator permissions. For most internal interfaces, a page or a node UI avoids that requirement.

Yes. Vento can automate repetitive processes through node actions, events, scheduled tasks and agents. Automation runs consume credits when accounting is active, and critical processes need supervision and manual alternatives.

Yes. Vento can turn a manual process into a connected flow with forms, databases, dashboards, agents and automations. Vento provides the components to build the system; the process and its rules must be defined by the people who know it.

Yes. A Vento network brings together people with roles, AI agents, software, data and physical devices. That connection can include APIs, databases, ESP32, Arduino, Raspberry Pi, computers and phones, always subject to the compatibility and permissions of each resource.

Start by describing a concrete outcome in Vento's initial assistant, for example "connect an ESP32 and show the temperature every minute".

1. 01Signing up creates your first network and opens a conversation with Vento Agent.
2. 02The agent can propose and build interfaces, data, automations or device connections; then test each part and continue in the same chat.
3. 03You can also begin by adding an element from the network menu.

Ask it explicitly: describe the goal and add "break the project into small steps and wait for my confirmation between each one".

1. 01Vento Agent is designed to identify which parts of the network it needs to change and show a workflow with steps.
2. 02There is no formal planning mode that blocks all changes until they are approved, so also state which actions it must not execute without asking you first.

Keep the goal and key decisions in a document in the network, work in blocks, and ask for a summary when you close each phase.

1. 01Vento keeps the conversation and the real state of the project, but if the context exceeds the limit it removes the oldest complete messages and indicates this.
2. 02Separate conversations do not share LLM memory, although they do share the network's persistent state, files and data.

If Vento Agent drifts from the goal, stop the work and restate the goal, the current state and the constraints it must not change.

1. 01You can use /clear to start a fresh context without deleting the network's resources, files or data.
2. 02Ask the agent to read a saved specification and explain its plan before continuing.
3. 03Afterwards, review the changes in Changelog or restore a snapshot if needed.

A good prompt for Vento includes four things: the desired outcome, the data or devices involved, the rules of behaviour, and how to check that it works.

1. 01For example: "Read the temperature from this ESP32 every minute, show it on a dashboard and alert me if it goes above 30 °C; explain the steps to me first".
2. 02Add limits, available credentials and what it must not change.
3. 03Start small and iterate with real results.

Yes. You can ask Vento Agent to split the goal into small tasks, indicate which resources it will affect and move forward step by step. The agent shows a workflow with statuses and links to what it has created. That breakdown is a conversational guideline, not a project manager or a plan locked behind approval. If you need control, ask it to stop between phases and review the Changelog before continuing.

Yes, you can ask Vento Agent to create and maintain a specification, a log or a summary as a file inside the network. You can also use the Git history and snapshots to see what changed and with which message. There is no automatic long-term memory that summarises everything on its own, so it is worth agreeing on the document's name and asking the agent to update it at the end of each phase.

Yes. In Vento, you can open several conversations with an agent inside the same network. Each conversation has its own session and does not automatically share message history with the others, but they all see the project's persistent state, files, data and repository. To coordinate parallel work, save shared decisions in a specification and avoid having two conversations modify the same resource at once without review.

Vento can generate documents, code, HTML pages, firmware, data files and circuit representations such as breadboard or PCB when Circuits is configured. It can also save those files in the network's buckets. It does not currently have an AI image generator. For general diagrams, you can ask for text- or code-based formats; then confirm that the target viewer or tool supports them.

Yes. You can ask Vento Agent to explain the architecture, the resources it modifies and how to test the result. Its working rules tell it to communicate what has changed, what you can do now and what remains pending; the interface also shows the details of the tools it ran and links to the items created. For important decisions, ask for the explanation before the change, because there is no mandatory preview.

Yes. Vento Agent can edit existing interfaces, pages, data, firmware and other resources in the network. Changes are applied directly; there is no mandatory preview or diff before they run. Afterwards you can review differences and history in Changelog, save or restore snapshots, and recover node versions. For risky changes, ask for an explanation and a recoverable copy before continuing.

Yes, you can ask Vento Agent to propose an architecture before making changes: components, data, devices, dependencies and validation steps. However, Vento does not have a formal planning mode that forces that architecture to be approved before writing. If you want that separation, say "design only, do not modify anything" and review the proposal before authorising the build.

Yes. You can use ChatGPT or another AI to explore ideas and bring a clear specification into Vento to build the system. Paste the goal, requirements, data, constraints and success criteria into the chat, or attach a PDF, Markdown or compatible text file. Vento does not have an official hand-off format, and JSON attachments are not currently supported in the chat. Always check that the specification does not include secrets.

Yes. In Vento, the unit equivalent to a project is a network. Within a single network you can also build several connected systems and organise them with groups and topologies, but it is best to create another one when you need independent isolation, team or billing.

Yes. In Vento, create a network for each project if you want them to be truly independent. If the two systems need to share team, data or billing, they can also live together in a single network organised through groups and topologies.

Yes, it is usually best to create a separate network when the project needs its own team, billing, credits, or isolation of data and resources. If several parts form a single system and need to collaborate, they can live in one network and be organised with groups and topologies. A network is the connected project and the main boundary for permissions and consumption; the workspace is where you create and operate it.

Yes. A Vento network can contain several connected elements, such as agents, interfaces, data sources and devices. They will all share the same boundary of members, general permissions, credit wallet and plan. If you need to isolate clients, teams, billing or data, use separate networks instead of mixing everything into one.

Create one network for your personal projects and another for company work.

1. 01Each network isolates the complete system, its data, members, credits and subscription, so it is the right boundary for separating the two.
2. 02Invite colleagues only to the company network and use roles and permissions according to their responsibility.
3. 03Vento does not have a higher-level organisation entity or a subscription that automatically covers several networks.

A network is your connected project in Vento. It brings together the nodes that make up the system and keeps its members, permissions, credits, plan and limits separate from other networks. You create and operate it from the Vento workspace.

A network is for bringing together and isolating a complete system in Vento. It organises its interfaces, agents, data, devices, pages and apps, and defines who can access it, which credits it uses and which plan it has. Creating separate networks lets you separate projects, clients or teams; using a single one lets several components share resources and collaborate within the same environment.

Yes, confirmed changes to network resources, configuration, conversations, data and files are saved on the Vento instance. The Git history is not fully automatic: Vento Agent creates snapshots after successful mutations according to its rules, and the user can make commits from Changelog. Text you have not yet sent in the browser can be lost on reload.

If the Vento instance goes down, the panel, the APIs, the public pages, the agents and central control become unavailable until it comes back. Work already saved remains on disk and agent turns have durable recovery. Device firmware can keep running its local logic, as can some phone automations or a local Vento Hub, but they will not be able to use cloud services while the outage lasts.

Yes. In Vento, you can invite a person with the visitor role and grant them only read access or specific permissions on particular resources. Review those permissions before sharing data, actions or secrets they should not use.

There is no role called viewer in Vento. To give mostly read-only access, invite the person as a visitor. If you need a fully public view with no access to the workspace, create a separate HTML page.

Yes. In Vento, you can publish HTML pages from a network and share them with people who have no account. Do not share session, device or service tokens in the HTML: a public URL or token should grant only the minimum access the application needs.

Vento lets you build your own interface for external users and authenticate platform accounts that do not enter the workspace, through the external group and per-network login rules. Those users do not form an independent per-application directory and must be managed through the API. For a public product, explicitly design registration, recovery, permissions and data protection.

Yes, you can dedicate a network to testing to isolate data, devices, users and credits from the main system. It is an organisational convention, not a special environment type: Vento does not apply sandbox rules or automatic promotion just because you call it "testing". Use non-sensitive data, separate credentials and simulated or safe devices, and document how to carry over the changes you decide to keep.

You can create separate networks for development, testing and production, but Vento does not offer formal environments or an automatic flow to promote changes between them. Each network will have its own team, data, credits and plan. Define credentials and controls for each environment manually.

Vento does not currently offer a button to clone a complete network. You can save nodes as templates and reuse them in another network, export and import databases as JSON, download files or sync the Git repository. Always review credentials and data before copying resources.

Vento Credits are the unit Vento uses to account for platform usage. Each network has its own wallet and uses credits for AI agent turns, node compute and hosted integrations. Internally, one credit equals 10,000 AI model tokens, although other work is calculated by time and CPU. Credits are not a currency transferable between networks.

In Vento, tokens measure the amount of text and context an AI model processes; they are not the same as the Vento Credits the user sees. The platform converts provider consumption into credits: the current equivalence is 10,000 model tokens per credit. The cost of a conversation can also vary because the agent reads files, uses tools and maintains context, not just because of the length of the message you write.

Each Vento network has a credit wallet.

1. 01When an agent uses a model, Vento converts the tokens confirmed by the provider into credits; node compute is calculated by duration and CPU, and hosted integrations apply their own unit, such as seconds of audio.
2. 02Charges appear in the Usage ledger.
3. 03If no balance remains, Vento blocks new metered runs, but does not delete the project.

In Vento, you can see consumption on your network's Usage page. It shows the balance and a ledger with each charge, its category, the related run and the credits used; it also shows refunds when they exist. The breakdown is by network, run and usage type, not by user or by a separate "project" entity. Each network keeps its own history and wallet.

No. In Vento there is no fixed cost per message. An agent turn consumes a variable amount depending on the tokens the provider processes, the history, the files read, the reasoning and the tools used. One credit currently equals 10,000 model tokens, so a message can use a fraction of a credit or more. The chat's microphone dictation does not consume credits by itself.

Vento consumes credits in three categories: AI agent usage, node and automation compute, and hosted integrations such as audio transcription. AI is charged by confirmed tokens; compute by duration and CPU; and each integration defines its own unit. Dashboard reads, administrative tasks and browser dictation do not consume credits. In self-hosted installations, accounting may be disabled.

In Vento, a query can consume more credits if it involves a long conversation, attachments, deep reasoning, reading many files or several tools. The text you write does not reflect all of the agent's work: the context sent to the provider also counts and, in other runs, the node's time or CPU. Check the detail in Usage to identify the run and its category. If a charge looks wrong, keep that identifier for support.

When a network runs out of credits, Vento blocks the admission of new work that generates consumption: agent turns, node actions, automations and hosted integrations. Reads, administration and topping up remain available, and the project is not deleted. Dashboards and pages remain visible; devices keep their local logic, although actions that depend on the Vento runtime may stop running.

In Vento, the credits included in a subscription are granted every four-week cycle. The current catalogue assigns a different amount to Basic, Pro and Max, and each grant can have its own expiry. One-off purchases, if offered, follow a separate policy that is not publicly confirmed. Check Billing and Usage to see the cycle, the credits received and their status in your network.

Credits belong to each network, not to the user's account. A network has its own wallet, ledger, plan and limits. If you are the owner of three networks, you will have three separate balances, and consumption in one does not use the credits of the others. In Vento, the network is the unit equivalent to a project, so billing and metering follow that boundary.

No. Each network has an independent wallet and Vento does not offer a mechanism to split one balance across several. Credits granted or purchased for a network are consumed only there. If you manage several projects, check Usage and the plan of each network separately. This separation also prevents a charge from one project draining another's credits.

No. Vento does not currently have a feature or an API to transfer credits between networks. Each credit stays tied to the wallet of the network that received it. If you have topped up the wrong network, do not try to compensate with technical workarounds: keep the purchase identifier and contact support, since any correction would have to be handled administratively.

Yes. In Vento, each network is linked to its own Stripe customer and subscription; one subscription does not cover several networks. A network without a subscription remains in the Free state and keeps its data, but needs credits to start metered work. If you split projects across several networks, you must manage each one's balance and plan independently.

Partially. Without credits, dashboards and pages can remain visible, data is not deleted and devices keep their local logic. Vento blocks new runs that generate consumption, such as agents, node actions, automations and bots that depend on the runtime. On a self-hosted installation with accounting disabled, that block does not apply. For continuity, identify which parts of your system require metered runs.

Choose your Vento plan based on the credits and storage each network needs.

1. 01Basic, Pro and Max include the same features; what changes is the credits granted per cycle and the available storage.
2. 02Start by estimating how many agent turns, automations, hosted integrations and data you will use, then check real consumption in Usage.
3. 03If the balance or storage proves insufficient, change that network's plan.

There are no different user limits for each Vento plan. Basic, Pro and Max differ in credits and storage, while technical limits apply at platform or network level. Current evidence also does not set a maximum number of members per network. There are roles and permissions to control who can view or modify resources; that is why, when working with a team, configuring access matters more than choosing a plan by number of users.

Vento's plans do not change the number of projects or networks allowed. A network is the connected project you create and operate from the workspace: each user can own up to five networks and take part in a maximum of eight active ones. Each network has its own subscription, credit wallet and limits. These are current platform limits, configurable by the operator, not an exclusive advantage of Basic, Pro or Max.

Vento does not currently apply a different maximum number of automations per plan. Basic, Pro and Max share the same features; what changes is the amount of credits and storage. Each automation run can consume credits, and there are general technical limits (for example, simultaneous nodes or agent concurrency) that the operator can adjust per network. The practical limit depends on consumption and load, not on a fixed automation quota.

"AI agent failed while starting" indicates that the agent never started, but that text no longer matches Vento's current messages. Today, the start can be rejected because Vento is busy, the instance is being deployed or the agent's local tools are unavailable. Wait a few seconds and retry; if it persists, copy the actual message and the run details. The exact text is needed to apply the right fix.

"AI agent execution failed" means the agent's process ended with an error; on its own it does not identify the cause. Open the run details to check `cause`, `reasonCode` or the available output and try the message again. Vento may perform some internal retries or switch provider accounts, but a policy rejection requires changing the request. If the failure repeats, share the run identifier or trace with support. Never share credentials.

In Vento, the error "The active agent executor did not begin steering before its deadline" appears when you try to redirect a running agent and its executor does not acknowledge the new message within ten seconds. That redirection message is cancelled before being sent to the provider, but the original run may still be active. Resend the instruction; if the agent still does not respond, use Stop and start again from the saved progress. There is no automatic retry of that message.

The error "too many concurrent AI agents process" means Vento has reached its limit of simultaneous agents. The current message usually says that Vento is busy; by default it allows up to ten concurrent agents per network and fifty on the instance, although the operator can adjust these limits. New runs are rejected, not queued. Wait for other agents to finish (or stop the ones you no longer need) and try again.

If the Vento agent gets stuck thinking, check whether it is still showing activity and wait for the "Keep waiting" or "Stop" option to appear.

1. 01After ten minutes without activity, Vento asks you to decide whether to continue; if you do not respond, it cleans up the run after a further minute.
2. 02You can use Stop earlier: it cancels the turn and keeps the visible progress.
3. 03Then rephrase the request as a smaller task and, if it happens again, save the run details for support.

If the Vento screen does not update, first save any text you have not yet sent, then reload the page.

1. 01Persisted network resources, conversations and data live on the server, so refreshing should not wipe that state; local drafts can be lost.
2. 02If the run still shows no change after the reload, open its details, check your connection and note the time, network and agent so you can report it.
3. 03Avoid repeating actions with external effects without checking their result.

You can refresh Vento if the agent is not making progress, but first copy any message or form you have not submitted.

1. 01Reloading keeps the network's persisted state and the run's visible progress; it does not necessarily keep browser drafts.
2. 02Before relaunching an action, check in the run details whether it actually ran, especially if it sent messages, modified data or controlled a device.
3. 03If nothing changes, use Stop or report it with the trace.

No, Vento does not currently have a public status page. The platform has internal health and diagnostic endpoints for operators, but these do not give users a public history of availability or incidents. If you need to know whether a problem is general, check the team's communications and report the time and the affected service.

Vento does not currently offer a public uptime guarantee or an SLA on its plans. That means no availability figure should be read as a contractual commitment, especially during the beta stage. If a project needs specific availability, support or recovery targets, talk to Protofy and agree those requirements before using Vento in production. Any future SLA should state scope, exclusions, measurement and remedies, not just a percentage.

Yes, Vento can consume external APIs and expose its own endpoints. You can use the “Call an API” action for GET or POST, write `fetch` in node logic or an automation for other methods, and publish actions through endpoints, public aliases or database APIs. Some routes require a session or token and others can be declared public. Custom API tasks require administration permissions. Before connecting a service, define authentication, limits and error handling.

Yes, Vento can receive webhooks through an action with a custom public route and a regenerable Run Token. There is no specific action called “Webhook”, nor a generic HMAC signing, testing or replay feature. To emit a webhook, node logic or an automation can call the external API. Always protect the route with a token, validate the payload in your logic and test the call before wiring it to an action with side effects.

To authorise an external call into Vento, use the mechanism appropriate to the endpoint: a Bearer token with scopes, an authenticated session or an action's Run Token.

1. 01Tokens are created with specific permissions and must be sent over HTTPS; the Run Token can be regenerated or deleted from the action settings.
2. 02Avoid putting credentials in the URL unless the integration requires it, limit scopes and revoke or rotate access when it is no longer needed.

Yes, you normally need a token to call a private Vento API from outside. You can use a Bearer token with scopes for general APIs or a Run Token limited to an action and its public route. An endpoint configured as public may not require a session, but that must be a conscious choice. Create the token with minimum permissions, store it as a secret, transmit it only over HTTPS and regenerate or revoke access if it is shared or no longer used.

Yes, Vento can currently connect to external PostgreSQL and Google Sheets, in addition to using internal SQLite and JSON. A PostgreSQL connection string lets you work with compatible services such as Supabase, Neon or RDS. There are no verified native connectors for MySQL, MongoDB, Airtable, Notion or Odoo; those systems could only be integrated through their APIs or your own code. The PostgreSQL configuration contains secrets and must be managed by the network owner.

Yes, Vento can use Google Sheets as a data provider for a database. The integration is configured with a service account and the corresponding network keys, so that Vento can read and write to the authorised sheet. Pasting a public link is not enough: you must share the sheet with the service account and limit its permissions. For more complex loads or greater transactional control, consider PostgreSQL.

Vento does not currently have a native connector for Airtable. If your Airtable base exposes the necessary API, you can integrate it using `fetch`, the “Call an API” action or an automation, handling authentication, pagination and errors yourself. That connection will be an integration built inside your network, not a preconfigured feature specifically supported by Vento. For a natively tested database, use PostgreSQL or Google Sheets.

Vento does not currently offer a native Notion integration. You can connect the Notion API from node logic or an automation if you set up your own credential and program the calls, but Vento does not provide a dedicated wizard, automatic synchronisation or support for its data model. The tested alternative for structured data is PostgreSQL or Google Sheets. Also review the Notion API's limits and permissions before automating sensitive information.

Vento does not currently have a native connector for Odoo. It is possible to integrate an Odoo instance through its API from node logic or automations as a custom build, provided you configure authentication, models, permissions and error handling. That solution does not include a predefined wizard or guaranteed compatibility with every Odoo version. For a real project, start with a limited, reversible operation before allowing writes to orders, inventory or accounting.

Vento does not currently have a native Grafana integration. You can send data from Vento to a source Grafana supports (for example PostgreSQL) or expose an API for an intermediate component to query, but you must set up that architecture yourself. Vento can already create its own dashboards inside a network; Grafana can be useful if your organisation uses it as an observability layer. There is no automatically generated Grafana datasource or dashboard wizard.

Yes, Vento can connect to internal tools that expose HTTP, APIs or webhooks. Node logic or an automation can query data, run actions and publish endpoints to receive events; you can also use PostgreSQL or a Node/Python client as a bridge. There is no automatic compatibility guarantee: you must define authentication, networking, data format, permissions and failure recovery. Start with read-only access and add writes only after testing them in a separate environment.

Yes, Vento lets you create recurring tasks with the Automations scheduler. You can schedule them with hour, minute and day helpers or with a cron expression. The helpers have one-minute precision; a cron expression can use seconds. Scheduling is currently written in TypeScript, requires administration permissions and uses the process timezone, with no dedicated selector in the interface. Check the timezone and add error handling before enabling a periodic task.

Yes, an automation or a node's autopilot can query data periodically and trigger actions. The task can read APIs, databases or devices and then update a node, emit an event, send a push notification or call Telegram. Define the frequency with cron, avoid overlapping long runs and decide what to do on errors, because Vento does not add general automatic retries. Scheduled runs can consume the network's credits.

Vento does not currently include a generic, ready-to-enable failure alert system. Errors do emit events, and you can build a rule or automation that turns them into a push notification, a Telegram message or your own email. You must decide which failures to watch, avoid duplicate alerts and test the channel. If the alerting automation itself fails, you will need an external means of supervision.

You can switch off a node's autopilot from Vento. Automations written in TypeScript do not have an individual pause or resume button in the interface: they must stop their job from the code, or be replaced or deleted. The global executor control affects the whole platform and should not be used to pause a single task. Design each automation with its own switch if you need to stop it operationally.

Vento does not have a built-in testing, simulation or dry-run environment. You can reduce risk by using a separate network and enabling “Require Approval” on actions that should wait for human confirmation before running. That approval does not simulate the result: it only blocks the action until it is authorised. For changes with physical, data or external-service effects, prepare test data and a way to revert them before moving to the operational network.

When an automation or action fails in Vento, the run ends with an error and is not generally retried automatically. You can handle the failure in code with `onError`, log context and decide whether to retry, compensate or stop the flow. Actions have configurable timeouts, and a job queue does not by itself provide workers or a dead-letter queue. Design operations so that repeating them is safe and set up specific alerts if the process matters.

Yes, Vento offers process, agent run, browser and node logs, plus business events. In the interface, an agent's Run details keep up to 500 entries; other logs rotate by size and business events are retained for 30 days. Access depends on the `logs.read` permission within the network. Analytics events do not include prompt text, but before sharing logs you should check they contain no sensitive operational data.

Yes, Vento can connect to Telegram through a documented recipe. It is not a native connector: you create a receiving webhook, an action to send messages and a step to configure the Telegram webhook. You need a bot, its secrets stored in Keys and a Vento instance reachable over public HTTPS. It is currently the external chat channel with the most documented flow.

To create a Telegram bot with Vento: create the bot in BotFather and copy its token; store it in Keys together with a webhook secret, never inside the code.

1. 01Then create the recipe steps: receiving with a custom route and manual response, message sending and webhook configuration.
2. 02Run the configuration to register a public HTTPS URL and test a message.
3. 03If it fails, check the URL, tokens, node logs and the network's credits.

BotFather is Telegram's official bot for creating and managing other bots. You need it to register your bot's name and obtain the token that authorises calls to the Bot API. Vento uses that token to configure the webhook and send replies. Store it as a network Key, not in code or a screenshot. BotFather belongs to Telegram; Vento does not create or recover that token for you.

Store the Telegram token in your Vento network's Keys, with a name like `TELEGRAM_BOT_TOKEN`.

1. 01The recipe also uses a separate secret to validate webhook calls.
2. 02Do not paste either of them into node code, a prompt, a shared URL or a screenshot.
3. 03Authorised logic can read the Key at run time without displaying its full value again.
4. 04If the token is exposed, revoke it in Telegram and configure a new one.

Your Telegram bot can keep working with your PC switched off if the network runs on Vento cloud or on an always-on Vento Hub. The bot lives where the Vento instance runs, not in the browser tab. If you have installed the local instance on that same PC, the bot will stop when you shut it down. In every case, Telegram needs to reach a public HTTPS URL; `localhost` does not work as a webhook target.

Yes, a Telegram bot built with Vento can query an inventory. The webhook delivers the message to an agent or another node, which can read an internal database, PostgreSQL, Google Sheets or an API and return the result via Telegram. You must define permissions, validate which queries it accepts and avoid exposing sensitive data in the chat. The technical capability is available, although there is not yet a verifiable public inventory case we can link to as an example.

Yes, Vento can send inventory notifications to Telegram. An automation can check stock levels, detect a condition (for example, low stock) and use the bot's send action to raise the alert. Telegram is integrated through a recipe, not a native connector. Configure thresholds, recipients, deduplication and error handling, and test the flow with non-critical data before enabling it. Runs can consume the network's credits.

Telegram audio is not supported out of the box in the official Vento recipe: the adapter processes text and discards messages without text. You can build an extension that downloads the audio and sends it to Speech to Text; the hosted integration accepts audio up to 40 MiB and returns the transcription. That requires your own logic and does not make voice a native bot feature. To start without extra development, use text messages.

The bot replies to text but not to audio because the official Telegram recipe for Vento only processes updates containing text. Voice notes are discarded unless you have added a step that downloads the file and transcribes it. To support them, extend the adapter: validate the type and size, download the audio with the bot token, pass it to Speech to Text and hand the transcription to the agent. Do not expose the token in that logic.

Yes, you can dictate messages to Vento using the chat's microphone button in compatible browsers. The Web Speech API transcribes your voice into the text box so you can review it before sending; this dictation does not consume credits and uses the browser language. It normally works in Chrome, Edge and Safari, but not in Firefox, and it is disabled in the Electron app. Vento Connect measures audio, but does not currently offer voice chat.

Vento does not currently offer a compatible, supported integration for building WhatsApp bots. The documentation recommends starting with Telegram, which does have a tested recipe. Technically an adapter for the official WhatsApp API could be built, but Vento does not provide the flow, verifications or support required. Do not use unofficial automations as if they were a Vento feature; they may breach the provider's terms.

WhatsApp is more complicated than Telegram in Vento because there is currently no supported recipe or adapter for WhatsApp, whereas Telegram has a documented flow with webhooks and actions. A future integration would need to solve the provider's onboarding and verifications, its costs, templates and policies, in addition to authentication and delivery. For now, Vento recommends Telegram for chat bots.

Yes, you can create an internal assistant connected to Telegram and to your network's data or actions. Vento receives messages through a webhook, queries databases or APIs and returns replies over the same channel. Discord and WhatsApp do not currently have supported adapters, so they require a custom integration. For internal use, limit who can invoke the bot, apply least-privilege permissions and avoid returning secrets or personal data in shared channels.

Yes, Vento works with IoT devices and lets you connect them to dashboards, agents and automations. It has verified support for ESP32/ESPHome, Arduino, Shelly, Raspberry Pi and computers with Desktop Agent, phones with Vento Connect, WLED and Node.js or Python clients. “Supported” does not mean the same thing for all of them: it can include firmware, flashing, telemetry, control or connection via MQTT. For your own hardware, use a programmable client or an API as a bridge.

Yes, Vento works with ESP32 through ESPHome. The tested ESP32 models are the ESP32-S3 DevKitC-1, Protofy ESP32S3 devBoard, ESP32 DevKitC V4 and Seeed XIAO ESP32S3. Vento can generate configuration and firmware, compile, flash from the browser, update over OTA and connect sensors or actuators via MQTT. The ESPHome catalogue also includes the Seeed XIAO RP2040, which is not an ESP32. Other boards require manual configuration and are not considered verified.

Yes, Vento works with the Arduino UNO R3, UNO R4 WiFi and MEGA 2560. Vento Agent can help you create the sketch, compile it and flash it from the browser. Flashing needs a WebSerial-compatible browser, normally Chrome or Edge over HTTPS. Arduino does not have the OTA flow that ESPHome offers, so to update the firmware you must reconnect the board. Always check the model, pins and power supply before uploading.

Yes, Vento works with the 64-bit Raspberry Pi 4 and 5. You can use it as a device via Desktop Agent, as a Python client or as a Vento Hub host to run a local instance. Desktop Agent is available for Linux ARM64 and an ARMv7 build also exists; Vento Hub requires ARM64. Official minimum requirements are not yet published, so for intensive workloads it is worth sizing memory and storage according to the devices, agents, automations and data you will keep active.

Vento does not currently have native PLC support. It includes no drivers, catalogue, discovery or specific configuration for industrial controllers. A PLC could be connected through a gateway or a Node/Python client if it exposes MQTT or a compatible API, but that solution must be designed, tested and maintained for the specific equipment. Do not present such a custom integration as official compatibility, especially where it is involved in machinery control or safety functions.

Vento does not offer native support for Modbus TCP or Modbus RTU. There is no official connector, driver or action for reading registers or writing coils. You can build an external bridge that translates Modbus to MQTT or HTTP and connect it through a Node/Python client, but its security, mapping and recovery remain the project's responsibility. For industrial control, validate the gateway and add independent protections before allowing writes.

Yes, Vento can connect sensors through ESPHome, phones and other devices. The ESPHome catalogue includes the DHT11/22, DS18B20, BMP280, ADS1115, HX711, PIR, ultrasonic sensors, rotary encoders, ADC, GPS and more; Vento Connect adds the phone's sensors. Values arrive in the network via MQTT and can be displayed, stored or used to trigger automations. For a sensor outside the catalogue, you will need manual configuration or a Node/Python client that publishes its data.

Vento can connect to industrial machines if they expose MQTT or an API, or if you add a gateway or Node/Python client that translates their protocol. It does not currently have native support for PLC, Modbus, OPC-UA or SCADA. Monitoring is usually the safest first step; control requires validating states, communication failures, stops and protections outside Vento. Each machine needs a specific assessment before it can be considered compatible.

Yes, Vento can control LED lights through ESPHome, WLED and compatible actuators. The catalogue includes PWM, addressable lights such as WS2812/SK6812 and NeoPixel, plus WLED over IP. You can manage brightness, colour or effects from a dashboard, automation or agent. Use a suitable power supply and driver for the strip, respect voltage and current ratings, and avoid connecting loads directly to a board when they need external power.

Yes, Vento can query production data if it arrives via MQTT, an API, PostgreSQL or a Node/Python client. The data can be visualised on dashboards, stored as time series and queried from agents or automations. There are no native connectors for PLC, Modbus, OPC-UA or SCADA, so many installations need a gateway. Start with reads and validate units, frequency, quality and permissions before automating decisions about the process.

Yes, you can view data from a Raspberry Pi connected to Vento on your phone. The Raspberry Pi and the phone both make outbound connections to the same instance via MQTT over WSS, so with Vento cloud they do not need to be on the same local network. You can open the dashboard on your phone or use Vento Connect as a device. On a Vento Hub without internet, both must be able to reach the local instance.

You do not need to be on the same local network when your devices and phone connect to a Vento instance reachable over the internet: each client opens an outbound connection and does not require exposing ports at home. The connection uses TLS/WSS if the instance serves HTTPS. If you are working with an isolated Vento Hub without internet, clients do need to be able to reach the Hub over the local network. Availability also depends on the instance being up.

Yes, Vento can monitor sensors in real time. Devices publish values via MQTT and dashboards receive push updates; you can also store time series and trigger events or alerts. Latency depends on the device, the network and the instance load, so Vento does not publish a universal figure. Design the system to tolerate disconnections and do not use a web interface as the sole protection for a critical process.

Yes, Vento lets you control devices from a dashboard. A node can display values and expose actions for relays, lights, motors, cameras, phones or other supported devices, and the dashboard presents those controls to the user. Access depends on the network's permissions. For physical actions, add confirmation where appropriate, validate the reported state and design a safe mode in case the internet, the instance or the device fails.

Vento can connect legacy systems if they have MQTT or an API, or through a gateway or Node/Python client that translates their protocol. It does not include native connectors for PLC, Modbus, OPC-UA or SCADA. The integration must map data, authentication, errors and reconnection, and it is best to start in read-only mode. If the system does not offer a documented interface, compatibility cannot be guaranteed and will require specific development and engineering.

Yes, you can upload files to Vento using Files and buckets. That storage accepts bytes in any format, with a configurable per-file limit that defaults to 10 MB. Chat attachments are different: they only accept JPEG, PNG, GIF, WebP, PDF, TXT, CSV and Markdown, with up to five files of 10 MiB per message. For files the chat does not accept, upload them to a bucket and work with their path.

Yes, you can upload many images to a Vento bucket from the File Browser, even by selecting a folder. Files are sent one by one, so a large upload can take a while. Do not use chat attachments for batches: they are limited to five per message. Organise the images into directories, check the 10 MB per-file limit and give the agent the bucket path so it can process the set in a controlled way.

Yes, Vento's File Browser lets you select or drag folders and preserves their structure inside a bucket. The interface walks the directories and uploads each file sequentially; it does not send the folder as a single operation. Names and paths stay within the network and count towards its storage. For a large set, first create a suitable bucket, review the result and give the agent the path instead of attaching all the files to the chat.

Yes, you can upload frames or many files to a Vento bucket, but not as a batch of chat attachments: the chat accepts five per message. Use the File Browser or the API to upload the set, organise the paths and let the agent read the bucket. Each file has a default maximum of 10 MB and browser uploads are sequential. For video, consider extracting only the frames you need to reduce time, cost and storage.

A bucket in Vento is a file container that belongs to a network. It is stored on the instance's filesystem, counts towards the storage quota and can be public or private. It can also be marked as committed to include it in the network's Git. Vento creates a reserved `public` bucket for content accessible without authentication; the others can remain private for authorised members. It is not an S3 bucket or an external cloud service.

To use a private bucket in Vento, an owner must create it and keep it without public access.

1. 01Network members can read its files; writing and deleting are reserved for owners, apart from the special rules of the `public` bucket.
2. 02You can upload from the File Browser and ask the agent to read a specific path.
3. 03A private bucket requires a session with access to the network: do not share its URL as if it were a public link.

Yes, Vento Agent can read files from a bucket. The buckets skill lets it list containers, upload files and work with network paths. To avoid using the wrong destination, state explicitly which bucket and folder it should look in; the agent should not automatically pick the `public` bucket. Access follows the network's permissions. If the format is not suitable for the chat, keeping it in the bucket allows it to be processed with code or compatible tools.

Yes, you can organise files into folders inside a Vento bucket. The File Browser creates directories and preserves paths when you upload a folder or drag in a structure. Use stable names and separate inputs, results and temporary files so that people and agents know where to work. Directories can be downloaded as a ZIP, but uploading a ZIP does not extract it automatically. The whole structure stays inside the network and counts towards its storage quota.

Yes, you can store a ZIP file in a Vento bucket because Files accepts bytes in any format. However, Vento does not extract it automatically on upload and the chat does not accept ZIP as an attachment. If you need to work with its contents, extract the ZIP before uploading the folder or create an automation that processes it in a controlled way. The ZIP must also respect the per-file upload limit, which is 10 MB by default.

Yes, you can upload an XLSX to a Vento bucket, but you cannot attach it directly to the agent chat. The Automations runtime includes the XLSX library to read it with code; node logic and the chat do not have that support. For an agent to analyse a table without extra preparation, convert the file to CSV. Keep the original in the bucket if you need to preserve formulas or formatting, and use a CSV copy for the data flow.

Yes, you can upload JSON to a bucket and Vento uses it natively in databases and exports. The agent chat does not accept JSON as an attachment, so you should upload it to Files and provide its path, import it into a database, or convert it to TXT/Markdown if you only need to discuss it. Always validate the schema and size before replacing data: a storage import can use `replace` mode and overwrite the previous content.

Yes, and CSV is the recommended format for giving tabular data to the Vento agent. The chat accepts CSV, while it does not accept XLSX; an Automation can read XLSX with code. Use CSV when you only need rows and columns, and keep XLSX when formulas, multiple sheets or formatting matter. Check the separator, encoding and headers before uploading, because Vento does not include a platform CSV parser that automatically fixes inconsistencies.

Yes, Vento offers databases inside each network. By default it uses SQLite and supports mutable, versioned and time-series modes; it can also use PostgreSQL, Google Sheets or JSON as the provider. Databases can expose a REST API to read and modify records from node logic, apps or integrations. The owner manages their definition and permissions. Choose time series for sensors, versioned when you need per-record history, and PostgreSQL for an external database managed by your team.

Yes, you can export a Vento database to JSON and re-import it with replace mode. There is no built-in CSV export or SQL dump. If you choose PostgreSQL as the provider, the data already lives on the external server you manage and you can use its own migration tools. Before moving a database, keep a verifiable backup, review relationships and types, exclude secrets and test the import in a separate environment.

Yes, an app connected to Vento can use external PostgreSQL or Google Sheets and store data from external users through the database's REST API. You can expose routes with permissions for the `external` group or use specific endpoints and tokens. You must design authentication, per-user authorisation, validation and privacy: making an app public does not automatically turn the database into a secure multi-user one. For personal data, define a legal basis, retention and deletion before opening up access.

Yes, a website built with Vento can store data in a network database or in external PostgreSQL or Google Sheets. The page calls Vento's APIs or node endpoints to validate and persist the information. You must decide who can write, check inputs on the server and avoid including secrets in the browser's JavaScript. If the site accepts external users, set up authentication and explicit permissions; a public URL on its own does not protect the data.

Vento Files and buckets can store any file format, subject to the size limit. The agent chat only accepts JPEG, PNG, GIF, WebP, PDF, TXT, CSV and Markdown; it rejects JSON, XLSX, ZIP and audio as attachments. Automations can read XLSX with code, and Speech to Text accepts audio up to 40 MiB. So "supported" depends on whether you want to store, attach, analyse or process the file.

Yes, Vento can generate reports as HTML pages, documents or files stored in buckets. An agent or automation can query databases, APIs and devices, calculate results and build a view or file to share. The format and frequency are defined in the project; there is no single report generator with universal templates. Always verify sources, dates and calculations before distributing a report, especially if it drives operational decisions or combines incomplete data.

You can take a Vento app to your own server only partially. The code of a Network App uses Node/Express and the HTML of pages can be copied, but startup, proxying, data, actions and authentication depend on the Vento runtime. There is no deploy-ready download feature. To host it elsewhere you must replace those pieces or keep the app connected via API to a Vento instance.

You need Vento Hub when you want devices, dashboards and automations to work locally without depending on the internet, when you need an always-on gateway, or when you are going to set up a kiosk on a Raspberry Pi or mini-PC.

1. 01It is not required to use Vento cloud or to connect a Desktop Agent.
2. 02Consider it if local continuity and network latency matter, but remember that Claude/Codex agents and some build services still need internet.

Yes, you can build in Vento online and use the system offline if you prepare it for a local instance or Vento Hub. A `.ventopack` carries the network across, and dashboards, automations, pages and devices over local MQTT can keep working without internet. Not every feature works offline: Claude/Codex agents, ESPHome compilation and some external services need a connection. Also bear in mind that the package can contain Keys, and protect it before moving it.

Vento's AI does not work fully without internet. The platform agents based on Claude or Codex need a connection to their providers. However, node logic and automations can call a local model through LM Studio and keep the data on the machine, as long as the model and runtime are installed. LM Studio cannot currently be selected as the agent's global provider, and Vento does not support Ollama. The rest of the local system can keep working without cloud AI.

Yes, you can run Vento on a 64-bit Raspberry Pi 4 or 5 using Vento Hub. The Hub includes the local instance and can use a kiosk mode; you can also connect the Raspberry Pi as a device with Desktop Agent. The Hub build requires ARM64, while Desktop Agent additionally offers ARMv7. There is no public table of minimum requirements, so size storage and memory according to the devices, data and automations you will keep active.

Yes, Vento can run on Linux. Vento Hub provides an AppImage for Linux x64 and ARM64, and the platform can be installed on a Linux server with Node; Desktop Agent also has builds for AMD64, ARM64 and ARMv7. Exact support depends on the modality: Hub, self-hosting or device. There is no public matrix of distributions and minimum requirements yet, so it is worth validating kernel, architecture, memory and permissions before deploying.

Vento does not currently offer a button to download a finished app and deploy it without dependencies. You can copy a page's HTML, export data, take the network's Git repository with you or adapt the Express code of a Network App. However, APIs, authentication, node logic and the connection to devices still depend on the Vento runtime unless you replace those pieces in your own architecture.

Yes. Vento can serve public HTML pages from a network and connect them to data or actions through endpoints and APIs. The page is hosted on the same Vento instance, under a route of that instance, and can be opened without entering the workspace if you configure it as public. There is currently no direct integration to deploy it to Vercel or Netlify; an external deployment requires adapting its Vento dependencies.

You cannot currently assign your own domain to an individual app or network in Vento Cloud. Pages are published under the instance's domain and route. If you operate a self-hosted instance, you can configure a domain for the whole instance and manage DNS and TLS yourself; that option is not the same as having a custom domain per network. Certificate renewal in the documented mechanism is manual.

Yes. Vento lets each network keep a Git history with commits and diffs, and nodes have versions with metadata and a restore option. The Changelog panel lets you review changes to the network. This does not replace a complete snapshot or backup system: databases and other resources have separate export mechanisms, and Git commits are not created automatically for every manual change.

Yes, but currently creating or deleting a Network App requires Platform admin permissions and the feature being enabled on the instance. A Network App is a Node/Express service that lives inside a network; Vento discovers, starts, supervises and publishes it under the same host. The only supported template today is Node/Express.

You can build the interface as a public HTML page of the network and use node endpoints or databases as the backend.

1. 01Nodes can expose actions with public or token access, and databases provide a REST API.
2. 02This architecture covers many dashboards and internal tools without needing a Network App.
3. 03If you really do need a persistent Node/Express service, its creation must be handled by a Platform admin.

Vento does not currently offer a Next.js template or direct deployment to Vercel. Inside the platform you can create HTML pages, custom React interfaces and Node/Express Network Apps; you can also generate portable code, but hosting it elsewhere requires preparing your own project and replacing or connecting the Vento dependencies. If an external app needs data or actions from the network, it can consume its APIs with the appropriate authentication.

Vento does not currently generate its own Expo or React Native app for publishing on the App Store or Google Play. The Vento Connect app, developed by Protofy, turns an Android or iOS phone into a device on a network: it provides sensors, camera, GPS and interactive HTML screens. To create a standalone mobile app you must use another development environment and, if you need to, connect it afterwards to Vento's APIs.

The usual alternative is to combine an HTML page or a React interface in Vento with node logic and databases. The interface shows the information; nodes run actions or expose endpoints; and databases store state through their REST API. You only need a Network App when you require a persistent Node/Express service or server-side logic that this pattern does not cover.

Yes. Vento can create node dashboards, a custom React UI for a node, a React view of the network and public HTML pages. The choice depends on whether the interface should live inside the workspace, be public or run on a device.

Not a compiled mobile app of your own, for now. Vento can use an Android or iOS phone as a device through Vento Connect, read sensors, camera or GPS, and display interactive HTML screens sent from a network. If you need to publish an independent native application on the stores, you will have to develop it outside Vento and connect it via API where appropriate.

Yes, partially. From Vento you can take the HTML of pages, exported data, the network's Git repository and the Express code of a Network App. There is currently no automatic export to Vercel, Next.js or a mobile app.

Yes. In Vento, you can invite people to a network by code, link or email and assign them the owner, member or visitor roles. To collaborate with limited access, use the visitor role and grant permissions only on the resources they need.

Vento has three network roles: owner, member and visitor. The owner manages resources, code, secrets, members, billing and deletion. Platform admin is a global role on the instance, not a normal network role.

Yes. In Vento, assign the owner role only to whoever should administer the network and use member or visitor for everyone else. Granular permissions do not turn the model into per-field editing; they apply to supported resources and actions.

Yes. In Vento, only people who belong to a network can enter its workspace. HTML pages or actions you mark as public are an exception: they can be viewed without an account depending on their configuration. If you share a demo, expose only the page and the endpoints needed, not the network or internal credentials.

Yes. Vento lets you restrict actions by role, give grants on specific resources and configure an action for user or administrator access. The owner should carefully review any public action: a token included in a page can be copied by its visitors and should not replace user permissions when sensitive data is involved.

Vento records events with the associated user and keeps certain execution, browser and agent logs, but it does not currently offer a complete per-user audit module. A network's events are retained for 30 days and can be queried via API with the corresponding permission; the visual events panel is for global administrators only. It should not be treated as an exhaustive audit log or as evidence of regulatory compliance.

Yes. In Vento, you can invite a client as a member or visitor, give them access to specific resources and revoke it when the work is finished. Before sharing, remove secrets from pages, visible tokens and unencrypted packages, and check which actions each person can run.

Yes. In Vento, you can create a public HTML page that shows only the information and actions needed, without opening up the network's workspace. If you publish an embedded chat, treat its URL like a password: whoever has it can use the agent and consume credits until you rotate or revoke the grant.

Yes, through network roles and specific grants. Each user can be an owner, member or visitor; an owner can give a visitor permission to write to or run specific resources without promoting them to member. Granularity depends on the resource type: Vento does not offer a universal per-field permission matrix for all data.

Yes. In Vento, a project is normally organised as a network and you can invite external users by email, link or code. Invitations can have an expiry date and a usage limit. Afterwards you can remove the user, revoke grants or deactivate the invitation link.

In Vento, a network's keys are write-only through the API: the value is never shown again and only owners or authorised processes can use them.

1. 01However, they are currently stored in plain text on the instance's disk and have no automatic rotation or expiry.
2. 02Credentials for hosted integrations do use AES-256-GCM encryption and versioning.
3. 03Do not publish keys in pages, prompts or code; manually rotate any secret that may have been exposed.

Vento combines per-network roles with permissions and grants on specific resources.

1. 01Owner manages the whole network; member works with data and actions without managing secrets, members or runtime; visitor starts with read access and receives specific grants.
2. 02Sessions can be revoked and some actions support public, token or approval-based access.
3. 03There is currently no MFA, SAML/OIDC SSO or configurable enterprise password policy.

Your projects or networks are not deleted automatically when you cancel. You stop receiving the subscription's credits and, when a network's wallet runs out of balance, Vento blocks new metered executions such as agents, actions, bots and automations. Pages, dashboards and reads remain available, and devices keep their local logic. The exact moment the cancellation takes effect depends on Stripe and should be checked in the billing portal.

Yes, but deletion is permanent. Vento stops active executions and removes the network's resources; there is no recycle bin or recovery period for the user. The name is permanently retired and cannot be reused, while the necessary accounting evidence is kept. Before deleting, export the databases, files and history you want to keep and check that no other systems depend on that network.

Yes. In Vento, an owner can remove members, revoke grants, deactivate invitations and rotate or revoke access to an embedded chat. Membership invalidation propagates immediately. You can also close browser sessions. Bear in mind that some long-lived technical tokens have no individual revocation; in extreme cases they are invalidated by recreating the network or suspending the account. Also revoke the external provider's keys where appropriate.

You can work with the Vento agent in Spanish: it replies in the language you write to it in. The main interface, however, is currently in English, and so is the internal documentation. Vento is still in beta and the interface translation is not complete.

Yes. You can write to the Vento agent in Spanish and the system instructs it to reply in the user's language, even though the interface is in English. Dictation is not available in every browser or in the Electron app.

Yes. Vento's main interface is currently in English and does not yet have a complete translation system. Some screens contain the odd string in Spanish, but these should not be taken as a complete localised version.

To learn to use Vento, start with a test network and describe a small goal in the wizard.

1. 01Use a template, ask the agent to propose the architecture and split the work into steps, then review each interface, automation or device it creates.
2. 02As there is no complete public documentation yet, lean on the agent itself and on Discord.
3. 03To learn safely, avoid starting with critical electrical systems or sensitive data.

No. Vento does not currently publish a roadmap with committed features and dates. To find out the status of a specific feature, ask the team and always distinguish between available, beta, in development and roadmap. The FAQ should not turn internal plans into public promises.

ChatGPT is a general assistant for conversing, researching, creating deliverables and performing tasks with tools. Vento is a platform specialised in building and operating connected systems: it keeps data, automations, pages, agents and devices inside a persistent network.

Use ChatGPT when you need a general assistant; use Vento when the result must keep running and connect with hardware. They can also complement each other, and their features evolve quickly.

Claude is a general assistant that converses, analyses and creates artifacts such as documents, code, websites or interactive components. Vento is oriented towards building and operating persistent networks with data, automations, APIs and physical devices.

Use Claude to think, analyse or create a deliverable; use Vento when you need the system to keep its state and continue operating. You can also ideate with Claude and build the system in Vento.

Cursor is a code editor with agents that understand repositories, modify files, run commands and let you review diffs. Vento is not an IDE for developing arbitrary software: the agent builds inside a platform that already runs data, pages, automations and devices.

Choose Cursor when the centre of the work is your own codebase; choose Vento when you want to assemble and operate a connected system inside a network.

Lovable focuses on creating, iterating and publishing full-stack web applications with natural language and editable code. Vento focuses on connected systems that combine agents, data, automations, interfaces and physical devices inside a network. Lovable offers a more direct path to a deployable website, your own domain and GitHub sync; Vento integrates hardware and persistent operation.

For a pure web app, Lovable is usually a better fit; for software plus the physical world, Vento.

Bolt is an AI builder for websites, full-stack applications and mobile apps, with a code editor, database, hosting and domains on Bolt Cloud. Vento builds networks that connect agents, automations, data and interfaces with devices such as ESP32, Arduino, Raspberry Pi or phones. Bolt is more direct if you want to publish a conventional application; Vento fits when the system must observe or act on the physical world and keep operating inside its runtime.

Replit is a cloud environment for creating, editing, running and publishing software with Agent, including websites, apps, bots and various kinds of deployment. Vento is a more specific platform: it organises a system as a network and connects agents, data, automations and hardware. Replit offers more freedom of stack and deployment; Vento reduces configuration when you need devices and operational surfaces already integrated. An external app can also use Vento as a backend.

Retool specialises in internal applications, mobile apps, workflows and agents over business data, with governance controls and a mature visual builder. Vento can also create internal tools, but it adds physical devices, circuits, firmware and an agent that builds inside an operating network. Retool is usually a better fit when SaaS connectors and enterprise governance matter; Vento, when the flow joins AI, software and compatible hardware. Vento is still in beta.

Bubble combines AI and a visual editor to create web and mobile applications with a database, workflows and integrations. Vento builds systems as networks where agents, APIs, automations and physical devices live together.

Choose Bubble if the centre of the project is a visual web or mobile app; choose Vento if it must integrate hardware and operate a physical-digital system. Vento does not currently replace Bubble for creating your own mobile app.

Make is a visual automation platform with thousands of integrations for connecting applications and designing workflows. Vento has a much smaller SaaS catalogue, but it brings agents, your own data, interfaces and physical devices together in the same network, and can build custom connections through APIs.

Use Make if the work mostly consists of orchestrating SaaS tools that are already supported; use Vento if the system also needs hardware, dashboards and persistent agents.

Zapier automates processes between applications through triggers, actions and a very broad catalogue of integrations, and also offers agents, tables, MCP and AI tools. Vento currently has far fewer SaaS integrations; its difference is bringing agents, data, interfaces and physical devices together inside a network. Zapier is a better fit for connecting existing business services; Vento, for building a connected system that includes compatible hardware.

n8n is a workflow automation tool, available in the cloud or self-hosted, that connects applications through nodes, APIs and code and adds AI capabilities. Vento builds a broader network: alongside automations it includes dashboards, pages, data, agents and compatible physical devices. n8n is usually a better fit for flows between APIs and SaaS; Vento, when the automation is part of a physical-digital system that must also be visualised and operated.

Node-RED is a low-code tool for event-driven applications: you build flows by dragging nodes and wiring them together visually. Vento also represents flows, but its main construction interface is an agent you describe the system to; it also integrates multi-user networks, data, pages, circuits and supported devices.

Choose Node-RED if you prioritise visual control and its node ecosystem; choose Vento if you want to build through natural language inside an integrated physical-digital runtime.

Home Assistant is an open source home automation platform focused on local control, privacy and a very broad ecosystem of devices and brands. Vento has narrower home compatibility, but it lets you build, through natural language, systems that combine compatible hardware, agents, data, APIs, dashboards and pages beyond the home.

For home automation that is ready to integrate, Home Assistant is usually more suitable; for building a custom physical-digital system, Vento can be the right fit.

Use Vento when the automation must include physical devices, sensors, actuators, dashboards, your own data or persistent agents within the same system.

Use Make or Zapier when the main goal is to quickly connect many SaaS applications through ready-made integrations. Vento currently has a much smaller connector catalogue and usually requires an API for services that are not integrated. You can also combine them: Make or Zapier orchestrate SaaS and Vento operates the physical-digital part.

Use Vento if the internal tool must connect natively with ESP32, Arduino, Raspberry Pi, sensors or actuators and you want an agent to build the complete system.

Use Retool if you prioritise a mature business application builder, mobile apps, SaaS connectors, governance and enterprise controls. Both can work with data and workflows; the decision depends on whether the centre of the problem is the physical world or the internal application.

Use Vento to quickly validate and evolve a system that fits its agents, interfaces, APIs and compatible hardware. Commission custom development when you need a completely free architecture, your own native mobile app, certifications, SLAs, very specific integrations or full control of deployment. You can also start in Vento and extract or connect pieces later, knowing that there is no automatic export of the entire runtime.

Use Vento when you want to start with a runtime, agents, data, dashboards, APIs and devices already connected, without assembling every service from scratch. Build your own stack when you need technologies, security policies, scaling or deployment outside Vento's model. Vento can complement an existing stack through APIs, PostgreSQL and MQTT; you do not need to replace everything. Also weigh up the beta, the dependency on the runtime and your operational requirements.

No. Vento reduces the work needed to build dashboards, automations, APIs, agents and connections with compatible hardware, and lets a non-technical person get much further. But it does not replace engineering judgement, validation, security or the maintenance of arbitrary software. A developer can review and extend what has been created when the project demands it. In critical systems, or outside Vento's model, technical expertise is still necessary.

Only in some cases. Vento can replace an automation platform when the flow combines AI, your own data, dashboards and the devices compatible with Vento. It is not a direct replacement if you need thousands of ready-made SaaS connectors, mature enterprise governance or specific features of a tool such as Make, Zapier or n8n. In many projects it is more useful to connect them: the traditional platform integrates SaaS and Vento operates the physical-digital system.

Vento can replace an IoT platform in projects that use the currently supported hardware, devices and protocols, especially when you also need agents, dashboards and automations. It does not replace a specialised IoT platform for any fleet, PLC, industrial protocol, certification or scale. Vento does not currently support PLC or Modbus natively. Check the compatibility matrix and test the real hardware before deciding; for other equipment you can integrate a Node/Python client or your own gateway.

Yes. Vento can run agents with Codex and lets you make calls to OpenAI from node logic or automations. Normal agents use accounts managed by the platform, so you do not need to connect your own key to get started. If you write an integration or your own logic that calls OpenAI directly, you can store a key in your network's keys. The available provider and model can vary depending on the instance configuration.

Not to use Vento's agents: they work with AI accounts managed by the platform and consume the network's credits. You only need your own key if you create node logic, an automation or an integration that calls an external provider directly on your own account. In that case you can store it as a network key, but you must manage its cost, permissions and rotation. Local models through LM Studio follow a different configuration.

Yes, with conditions. You can call an external provider from node logic or automations using its API and a network key, and you can use local models exposed through LM Studio. These options serve logic you build inside the system, but they do not currently replace the global provider of Vento's agents. There is no universal model selector, no catalogue of external providers and no native support for Ollama.

Yes, for calls you program in node logic or automations. Store the key as a network key and retrieve it from authorised code; do not include it in a page, prompt or repository. That key does not currently replace the accounts used by Vento's main agent, nor does it enable a global OpenAI selector. Calls made with your credential are billed under your relationship with OpenAI, not as managed agent usage.

Yes, if you run the model locally with LM Studio and call it from node logic or an automation. You need to install LM Studio, load a compatible model and configure its endpoint; the hardware required depends on the model. This integration processes one request at a time and has a two-minute timeout. You cannot currently select that model as the general provider for Vento's agents, and Ollama is not supported natively.

Vento does not currently have a marketplace or a public SDK for installing third-party plugins with one click. You can extend a network with custom node logic, TypeScript tasks, Node/Express Network Apps and skills, but several of those surfaces require Platform admin permissions. Hosted integrations are also published by a global administrator. For a specific need, the most accessible route is to use an API from node logic or an automation.

Yes. In Vento, you can connect an API from node logic or an automation, store credentials in the network's keys and expose endpoints or webhooks to exchange data. It is also possible to develop a hosted integration, but publishing it in the catalogue requires global administrator permissions and there is no public SDK for third parties yet. Start with the generic API unless you need a reusable connector managed by the platform.

Yes. You can write JavaScript logic in nodes, automations and TypeScript tasks, HTML pages or React interfaces, and Node/Express services as Network Apps. Node logic runs in a sandbox and is the usual option for a network's logic. Tasks and Network Apps require administrative permissions. You can also maintain external code and connect it to Vento through APIs, tokens or MQTT depending on the case.

Yes. An external app can call node endpoints, public routes or the REST API of Vento's databases, using public access, a specific token or JWT with scopes depending on the risk. Vento can provide data, actions, agents and devices as a backend. The app will still depend on Vento's runtime and authentication; protect the tokens, apply minimal permissions and do not embed them in public code if they allow sensitive actions.

In Vento you do not need a specific plan to create a bot: the feature is also available in a Free network. The plan determines how many credits that network receives and its storage. An active bot consumes credits when it runs agents, node logic or integrations, so choose Basic, Pro or Max according to the expected usage. Telegram is supported through a documented recipe; WhatsApp and Discord are not bot integrations available today.

In Vento, automations are not gated by plan; you can create them in any network. Basic, Pro and Max differ mainly in credits and storage. Runs consume credits according to the time and CPU used, and TypeScript automations require administrative permissions to create. Start with the tier that covers your trial and review Usage: a frequent or continuous automation will need more balance than an occasional task.

There is no required plan for connecting compatible devices: that capability is available in any network. The plan provides credits and storage; it does not unlock hardware models. Devices can keep reporting and running local logic without credits, but Vento actions, agents and new automations can be blocked if the wallet runs out. First check that your Arduino, ESP32, Raspberry Pi or other equipment is supported.

You do not need a specific team plan: Vento lets you invite members in any network and does not document a different user limit per plan. The available roles are owner, member and visitor. The subscription, credits and storage belong to the shared network. If you need SSO, MFA, full auditing, contractual support or enterprise controls, those features are not part of the current self-service plans and should be discussed with Protofy.

Yes. You can contact Protofy through its contact form; inside Vento there is also an Enterprise form that reaches the sales team. Describe your use case, user profile, data, integrations, hardware and deployment requirements to receive a useful answer. Vento does not yet publish opening hours or a guaranteed response time, so a contractual or urgent need must be expressly agreed.

To create a dashboard with AI without coding in Vento, start by defining what data you need and what decision it should support.

1. 01Create a network and connect the source: a database, API or device.
2. 02Ask Vento Agent to prepare the node and organise tables, charts, maps, cameras or controls in the dashboard view.
3. 03Review data, permissions and actions with real cases.

You can iterate on the design by talking to the agent; a very specific visualisation or piece of logic may need code or technical review.

To create an AI automation for your business in Vento, start with a concrete, measurable process.

1. 01Define the input event, the data needed, the decision, the final action and who steps in if it fails.
2. 02Ask Vento Agent to connect the APIs or databases and build the flow in a network.
3. 03Test with non-critical data, add approval to sensitive actions and log the outcome.

Vento does not include a general dry run or universal retries: you must design those controls deliberately.

To create a Telegram bot connected to a database with Vento:

1. 01Register the bot with BotFather and store the token and the webhook secret as network Keys.
2. 02Create the steps for receiving, replying and configuring the webhook.
3. 03Connect the flow to an internal database, PostgreSQL or Google Sheets and restrict the allowed queries.
4. 04Publish the webhook from an HTTPS instance and test with real messages.

The official recipe processes text; voice notes require an additional extension.

To create an internal app with AI in Vento, first define users, data, decisions and actions.

1. 01Create a network for the team.
2. 02Ask the agent to build the database and a dashboard, HTML or React interface.
3. 03Add the agent that will query information or run tasks.
4. 04Configure roles, permissions and approvals before sharing it.

If you need SSO, a compiled mobile app or an independent web deployment, you will have to consider another tool or an external architecture.

To connect a Raspberry Pi to an AI agent in Vento:

1. 01Add a Desktop Agent to the network and download the Linux ARM64 package.
2. 02Install it on a 64-bit Raspberry Pi 4 or 5 and verify that it appears as a connected device.
3. 03Create a node with the data or actions you want to expose to the agent.
4. 04Grant only the necessary permissions and test each action.

The connection to Vento Cloud is outbound; Claude and Codex need internet access. LM Studio enables local AI from node logic or automations, not as the agent's global provider.

To create an IoT system with AI in Vento, first design what it must observe, decide and act on.

1. 01Choose a compatible board, gateway or device.
2. 02Create a network and ask the agent to prepare firmware, data storage and a dashboard.
3. 03Connect the telemetry over MQTT and add the AI rules or agents.
4. 04Test with safe loads, configure permissions and decide what will happen if the internet goes down.

Vento is in beta and does not offer native compatibility with every PLC or industrial protocol.

To create a sensor panel with Vento:

1. 01Add a compatible device to a network and check that it is receiving the readings.
2. 02Create a node and store history in a time-series database if you need it.
3. 03Organise indicators, charts, tables or maps in the dashboard view.
4. 04Keep actuator controls separate and protect them with permissions or approval.

Data can update over MQTT; the real latency depends on the device, the network and the load on the instance.

To connect an ESP32 to a web dashboard with Vento:

1. 01Choose a verified board from the ESPHome catalogue and define its sensors or actuators.
2. 02Let Vento generate the configuration and the firmware.
3. 03Flash it from Chrome or Edge via WebSerial over HTTPS.
4. 04Show the values the ESP32 publishes over MQTT on a dashboard.

Boards in the catalogue support OTA for later changes. Check the pinout, voltage and power supply; other variants may require manual configuration.

To automate an inventory with AI in Vento:

1. 01Create a database with products, stock and movements.
2. 02Import the initial data and build a dashboard to search, edit and detect minimum levels.
3. 03Connect an agent to query the information and an automation to generate alerts or sync with an API.
4. 04Start with read permissions and require approval for writes.

Vento lets you build the system, but it does not offer a packaged inventory product.

To query production data with an AI agent in Vento:

1. 01Connect a compatible source, such as PostgreSQL, an API, Google Sheets or MQTT telemetry.
2. 02Create a node that normalises the queries and limits the data available.
3. 03Give the agent only the tools it needs and offer access from chat, Telegram or a dashboard.
4. 04Validate units, permissions and answers with real data.

Legacy machines may need an HTTP, MQTT or Node/Python bridge; there is no native integration with PLC, Modbus or OPC-UA.

To create an assistant for internal operations with Vento, start with a bounded responsibility.

1. 01Define which questions it answers, which sources it consults and which actions it can run.
2. 02Create a network and connect the necessary databases or APIs.
3. 03Add an agent and publish it in the internal chat, a web interface or Telegram.
4. 04Separate reading from writing, require approval for sensitive actions and log the relevant events.

Expand the scope only after validating answers, permissions, credit consumption and behaviour under failure.

To turn an idea into a functional prototype with AI in Vento:

1. 01Describe the user, the problem, the inputs, the outcome and the constraints.
2. 02Ask the agent for an architecture and a plan split into small tasks.
3. 03Let it build the interface, data, logic and connections.
4. 04Test the flow with real cases, review what was created and correct it through conversation.

The prototype is the first phase, not the product's ceiling: if it proves its value, you can keep evolving it into a more complete system.

To create an internal tool without initially building a development team, choose a small, well-understood process.

1. 01Describe its users, data, rules and outcome.
2. 02Ask Vento Agent to build the database, dashboard and automations.
3. 03Share the network with appropriate roles and test the flow with the team.
4. 04Measure whether it reduces work before expanding it.

Complex authentication, sensitive data, special integrations and critical production still need technical review.

To connect APIs, databases and devices with AI in Vento:

1. 01Create a network and store the credentials as Keys.
2. 02Connect the API from node logic or an automation and choose an internal database, PostgreSQL or Google Sheets.
3. 03Add the device via MQTT or a compatible client.
4. 04Give the agent access only to the necessary queries and actions, and show the state on a dashboard or another interface.

Unsupported services or equipment need an API or a bridge client maintained by the project.

To use AI to build a connected system, first define what the system observes, what it decides, what it acts on and who keeps control.

1. 01Describe that intention to Vento Agent.
2. 02Connect data, interfaces and devices inside a network.
3. 03Test each action and add permissions, approvals and failure recovery.
4. 04Decide what must keep working without internet or without credits.

AI speeds up building and iteration; the responsibility for validating the system remains human.