Vatio changelog

Replies never invent a price

Mon, 26 Oct 2026 12:00:00 GMT

Every agent now checks the amounts of money in its replies against what your tools and prompt said. API keys became one concept, quiet hours let you choose when the agent stays silent, and a few surfaces were removed so the CLI and the MCP are the way in.

No invented amounts: a price in a reply must come from a tool, your instructions or a quote that adds up from them, or the agent says it is not confirmed.
Two kinds of API keys, publishable and secret, on one page in the inbox and under vatio keys; secret keys now say live or preview.
Quiet hours: a weekly schedule in which the agent stays silent on every channel, set in the inbox or with vatio quiet-hours.
Tools can send photos on WhatsApp and take the files a visitor sent, and failed WhatsApp sends are retried a bounded number of times.
Export and erase a person from the CLI or the MCP, and safer sign-in: inviting people and minting server keys need two-step verification.

The way in has not changed: npx @vatio-ai/skills and /vatio-init in your app’s project. What is new is a check on every reply: the Safeguards page lists what it catches and what the agent says when an amount is not confirmed.

Keys are now publishable or secret, and the CLI and the MCP are the surfaces to work from: the HTTP developer API behind them is no longer documented, and people’s data is exported or erased with vatio contacts. To choose when the agent stays silent, see Human in the loop; for photos and visitor files, Tools.

0.106.0 — 2026-10-25

vatio chat list no longer talks to your agent. A lone word that reads like a subcommand (list, search, open, history…) is refused and nothing is sent; the error points at vatio chat show [CHAT_ID] and vatio chat export --from DATE. Before, it went to the agent as a message and started a chat.

Secret keys name their environment. A new one is vsk_live_… or vsk_preview_…; keys from before are plain vsk_… and keep working. The inbox creates a secret key as a live and preview pair, for one VATIO_SERVER_KEY variable with a different value per environment. vatio keys create secret --env live|preview still makes one at a time.

The vatio-add-to-app skill is gone (@vatio-ai/skills 1.27.0). To put the agent in your app, ask your coding agent to add the web widget or the iOS, Android or Flutter SDK. Running npx @vatio-ai/skills again removes the old copy.

0.105.0 — 2026-10-25

Agents no longer state amounts nobody gave them. A new safeguard, no_invented_amounts, runs on every reply of every agent: an amount of money in a draft ($25.000, US$49.99, 25 lucas) must be a number a tool returned in the conversation, an amount written in the prompt, or a quote that adds up from those (a quantity times a unit price, plus up to two other amounts, such as shipping). Any other amount sends the draft back to the model, as an unauthorized link does; if the model keeps writing it, the reply says the amount is not confirmed. A price the visitor proposed is never one, a price the owner gives in a conversation with one of the business’s own numbers is. send_image refuses a caption with an invented price. The inbox and vatio chat show name the policy on a discarded draft. See Safeguards.

0.104.0 — 2026-10-25

vatio whatsapp mine: your numbers from the CLI, before a number is connected. vatio whatsapp mine NUMBER... sets the business’s own numbers (the inbox’s Your numbers), --clear empties the list, and with no arguments it prints them; plain vatio whatsapp prints them too. They now belong to the workspace rather than to the connected number, so they can be set first and they outlive reconnecting one. On the preview number the list decides who is the business: list your test phone to try access: owner tools, leave it off to talk to the agent as a customer. See Your numbers.

0.103.0 — 2026-10-25

Owner tools and photos on WhatsApp.

access: owner gives a tool only to the business itself: a WhatsApp conversation with one of Your numbers (Channels → WhatsApp). Anyone else is never shown the tool, a call that names it anyway is refused with owner_only, and in an owner conversation the agent is told it is talking with the business. Run the business from WhatsApp with it: update stock, confirm a payment, add a product from a photo. In preview, while Your numbers is empty, every phone verified on Try the agent counts as one. See Access.
send_image, a new built-in tool, sends a WhatsApp contact a photo one of your tools returned in the conversation, with a caption, right after the reply: a product from your catalog, say. A URL the agent wrote or a visitor typed is refused. JPEG or PNG over https, up to 5 MB and 10 a turn; the photos show in the inbox. See Photos.

0.102.0 — 2026-10-24

Fewer surfaces: the CLI and the MCP. The HTTP developer API behind them (/api/developer/v1, vat_ tokens) is no longer documented and is not a supported surface: it can change without notice. What your own backend calls stays documented and stable: messages with a secret key, webhooks and errors.

vatio contacts export ID and vatio contacts delete ID replace the Contacts API for access, portability and erasure requests. export prints the JSON (or writes it with --out FILE); delete shows what goes and asks you to type the id, and needs --yes without a terminal. See Contacts. The MCP gets the same two as export_contact and erase_contact; erasing needs confirm_contact_id to repeat the id.
Routines are gone. vatio routines and the routine: tool file no longer exist. To hand work to Claude from WhatsApp, use an ordinary tool that calls your own backend, which checks who is asking and fires the routine’s API trigger. See Give Claude a WhatsApp number.
Supabase sign-in is gone. vatio auth --supabase and auth: supabase: in vatio.yml no longer exist, and the widget no longer reads the page’s Supabase session. An app on Supabase signs the visitor token in an Edge Function like any other stack; see Authentication. Nothing in production used it.

0.101.0 — 2026-10-23

One concept, API keys, of two kinds. What was a publishable token and what was a server key are now the publishable key (vatpub_…, for a page or an app) and the secret key (vsk_…, for your backend). The values and prefixes of the keys you already have do not change, and neither do the widget’s data-token, the SDKs’ token or the Authorization: Bearer header. In the inbox they are one page, Settings → API keys, with a single New key button at the top right that asks the kind.

This breaks Vatio’s own commands and REST paths, with no aliases:

vatio tokens is gone. vatio tokens create --env live --label website --origin URL is now vatio keys create publishable --env live --label website --origin URL, and vatio tokens origins PREFIX URL... is vatio keys origins PREFIX URL....
vatio keys create needs publishable or secret. There is no default kind: what used to be vatio keys create --env live is vatio keys create secret --env live. --origin is only for a publishable key.
vatio keys list shows both kinds, with a kind column and the keys Vatio manages marked. --json prints the list.
The developer API replaces publishable_tokens and server_keys with api_keys: GET and POST /api_keys (the body names the kind), PATCH /api_keys/:prefix for a publishable key’s origins and DELETE /api_keys/:prefix. The create response carries the full key once and the new api_key. An unknown kind answers 422 invalid_key_kind. See API keys.

0.100.3 — 2026-10-23

Security fixes.

Signing in from the CLI. The approval page no longer emails a sign-in link. To sign in with your email there, you get the regular code by email, type it in the same browser, and come back to approve the terminal. Google and GitHub work as before.
Inviting from the CLI. vatio team invite now needs two-step verification on your account. Without it, invite from the inbox, under Team.
Two-step verification for the riskiest changes. In the inbox, inviting a member, minting a server key, offering the workspace to a new owner and deleting it now need two-step verification on your account. Security lists who on the team doesn’t have it yet.
MCP tokens. A token issued to an MCP client over OAuth now works only at /mcp, not on the rest of the developer API.
Credentials in the CLI. The file that holds your token is created readable only by you.
Opening your browser on Windows. The CLI no longer opens it through cmd.exe.

0.100.2 — 2026-10-22

Vatio no longer triages or fixes reports itself. It used to read each report as it was filed, say where the fix lived and, for the agent’s instructions or a knowledge entry, change preview and test the change on its own. Every open report is now your developer’s, to fix with their coding agent through /vatio:vatio-improve, and Vatio changes nothing on preview by itself. Continuous improvement lists the reports by state, with the latest test, and vatio flags no longer has a What Vatio did section.

“Connect Supabase” is gone from the inbox. No workspace used it. Your Supabase project is named in vatio.yml (auth: supabase:), and vatio auth --supabase reads it from the .env of your project or from the URL you pass. Nothing changes for a project that already declares it.

The Test page is gone: Try the agent, Tests and versions moved. Try the agent, a button at the top of Conversations, opens the web chat, the shared WhatsApp number and the shared Instagram account over the list. Conversations has a Customers | Tests switch, and Tests holds what the team said to the agent on preview. The version cards are at the top of Continuous improvement, read-only: Publish, Run tests and the knowledge-conflict page left the inbox. You publish with vatio publish, run tests with vatio test and resolve a knowledge conflict by reading the entry from live (vatio kb cat BASE ENTRY --env live) and writing your change on top (vatio kb write), or by asking your coding agent; vatio kb publish publishes knowledge alone. review_url and knowledge_url are now always null. Old /<workspace>/test links redirect, and the link vatio push prints opens Try the agent. On Channels, the packages card became one card that points at /vatio-add-to-app and the documentation.

The Contacts page and the inbox’s contact export are gone. The inbox no longer lists or searches every person, and it no longer exports one. A person is seen and forgotten from their conversation: the contact pane beside it keeps their name, channels, memories and other conversations, and Forget this contact (owner and developers). The per-person export and delete stay in the developer API (GET /contacts/:id/export, DELETE /contacts/:id), with a token and recorded in Activity. Old /<workspace>/contacts links land on Conversations.

0.100.1 — 2026-10-22

vatio share-session no longer sends another session when it cannot find the one it runs in. Run from inside Claude Code or Codex, it takes that session. When that session’s file was not where it looked, it used to fall back, without a word, to the newest session for the directory: another conversation. It now stops and says so, and --list and --id ID pick one. From a terminal it still takes the newest session for the directory.

vatio test no longer fails a case only because a replay is not signed in. A replay never has a signed-in visitor, so an access: private tool it calls for real answers not_authenticated. A case that failed because of that is now marked not tested (a tool needs a signed-in visitor) with the tool, like a case that needed the test phone’s contact, instead of reading as a regression of your agent. Calls the reported turn made still get the answer your backend gave then.

0.100.0 — 2026-10-22

vatio team: see who is in the workspace and invite someone. vatio team lists the owner and everyone invited, and who has not signed in yet; vatio team invite EMAIL --role viewer|supervisor|developer invites them and emails them, the same invitation as the inbox’s Team page. It is the owner’s alone, as there, and the role has to be named. When the owner’s account has a second factor, the invite takes a fresh code from it (--code), as the inbox asks the owner to confirm. Removing someone and changing a role stay in the inbox. See Team.

vatio whatsapp test-phones lists the phones verified on the Test page. A coding agent that needs a number to send a preview message to no longer has to ask the developer for it. Plain vatio whatsapp prints them too, whether or not the workspace has a number of its own. Adding a phone is still only in the inbox. See Channels.

0.99.1 — 2026-10-22

vatio share-session says what to do when you run it after ! in Claude Code. Typed at Claude Code’s ! prompt, it has no terminal to ask from, so it refused with a message addressed to a coding agent, and nothing was sent. It now also tells the person to add --yes. Nothing else changes: it still sends only after a yes, or with --yes.

0.99.0 — 2026-10-22

A push says who can see it, not which environment it landed in. Until someone outside your team talks to your agent the workspace is a draft and live follows every push, so vatio push said to preview about a version that was already answering people. It now says what happened instead: Your agent is answering with this now while the workspace is a draft, and once it is published, which deployment visitors still get and what is left before they get this one. The environment is named only when the push is waiting for a vatio publish. The docs follow the same order: Draft and published comes first, and preview appears where it starts to mean something. staging and sandbox are still accepted as names for preview and are no longer documented.

An unknown command suggests the closest one. vatio puhs offers push, a subcommand on its own (vatio show) lists the commands it belongs to, a sentence (vatio "do you deliver?") offers vatio chat, and the package name used as a command — npx @vatio-ai/cli @vatio-ai/cli push, the commonest way to get the invocation wrong — says so and prints the command to run. It used to answer all of them with the whole help text, which is where the reader had already failed to find what they wanted.

vatio secrets set KEY --from-env takes the value from your shell or the .env beside your vatio.yml and sends it without printing it, so a coding agent can set a secret it is not allowed to read instead of stopping to ask you to run the command. Only the key you name is read. --from-env NAME reads a different local name. See Secrets.

One http://localhost origin covers every port. A publishable token that lists http://localhost:3000 now works on :5173 or whatever port your dev server picked today, the way a loopback OAuth redirect URI already did (RFC 8252 §7.3). A changed PORT was silently a blank widget. Only http loopback: https://localhost:5000 is still its own origin. See Tokens.

vatio test explains how to start a suite. With nothing to replay it pointed at reporting a reply that went wrong, which is no help on a workspace where nothing has gone wrong yet; it now shows vatio chat --new plus vatio test add, which is how a reply that is already right is kept. A test run’s report no longer fails with an uncaught timeout when it takes a while to render: it says the run is still on Vatio’s servers and to ask again.

vatio changelog says what a newer release would bring. It prints which release is current, the headline of every change between the version you have and that one, and the npm command that installs it; --full prints each entry whole. npm still does the updating, so vatio update is still not a command — its refusal names this one now. That refusal was the only answer a coding agent could get, because the “a new release is available” notice prints only to a terminal and an agent has none. The automatic jump to the current release (426 cli_outdated) names the command as well.

0.98.0 — 2026-10-22

The plan belongs to an organization. Every workspace now sits in an organization, and the plan, the subscription and the monthly conversations belong to it: its workspaces share one plan, and the conversations of all of them count against it. Whoever has one workspace sees no difference. The owner of an organization can add more workspaces to it, each one an agent for a different workflow, with vatio init SLUG --org ORG or the create_workspace tool’s organization argument. A workspace transferred to someone else leaves for an organization of its own unless it was the only one in its organization, which then goes along with its plan. Contacts and conversations stay in the workspace they belong to.

0.97.0 — 2026-10-21

Choose when the agent does not answer. A weekly schedule, with any number of ranges per day and a time zone, in which the agent stays silent on every channel. A message that arrives inside a range is not answered afterwards: it waits for your team in the inbox. Set it in the inbox under Channels → Quiet hours, or with vatio quiet-hours. Without one the agent answers around the clock. See Human in the loop.

0.96.0 — 2026-10-20

Tools can send the visitor’s files. A tool parameter declared with format: vatio-attachment takes a file the visitor sent in the conversation, such as the screenshot on a support ticket. The agent picks the file by the attachment id it now sees next to each one. Your backend gets a link that expires after 1 hour, with the filename, type and size. Only files the visitor sent in that conversation can be sent; any other value goes back to the agent as invalid_argument. Each file sent appears on the Activity page. $params.<name>.<field> reads a field of an object argument, such as $params.screenshot.url. See Visitor files.

0.95.0 — 2026-10-19

One request, bounded retries. Vatio retries confirmed WhatsApp send and delivery failures for developer messages in every mode. A request keeps the same message ID and idempotency key through four total attempts; the API and inbox show the attempt count and next retry time. In a conversation, the message’s receipt says which attempt got it through, and its tooltip when each retry ran and after which error. The developer receives a failure webhook when Vatio has no safe attempts left. Opt-outs and uncertain send outcomes stop immediately to avoid unwanted or duplicate messages. vatio messages failed lists final failures; the separate resend command and API are removed.

0.94.0 — 2026-10-19

Review failed WhatsApp messages. The inbox groups failures by cause, the server API and vatio messages failed filter them by error and date, and a channel.issue webhook reports account-level problems. This version also introduced separate resend attempts, which 0.95.0 replaces with retries on the original request.

Build and run your agent from a chat

Mon, 19 Oct 2026 12:00:00 GMT

Vatio is now an MCP server: add vatio.ai/mcp to Claude or ChatGPT and work on your agent from a chat. The way in is still two lines in your app's project, and reported replies now double as a test suite you replay on every version.

Vatio in Claude and ChatGPT: add https://vatio.ai/mcp, sign in, and create, edit, test and publish your agent from a chat.
Reported replies become tests: vatio flags add reports a reply from the terminal, vatio test add keeps one that is already right, and vatio test replays them all on every version.
A Flutter SDK, and a guide to the AI agent runtime that follows one message from your customer to the reply.
vatio pull brings the agent Vatio runs back into your files, and vatio push no longer overwrites edits made outside them.
A new agent's live follows preview until someone outside your team talks to it, so there is nothing to publish at first.
The inbox got simpler: knowledge is read-only there, Test shows the next version only when there is one, and vatio.ai now has a Spanish landing at vatio.ai/es.

The way in has not changed: npx @vatio-ai/skills and /vatio-init in your app’s project. What is new is a second place to work from. Vatio in Claude and ChatGPT explains how to connect, and the Tests from the terminal section shows how a few vatio chat and vatio flags add commands become a suite.

A flag on a preview chat is now a note for your coding agent, not a test: vatio flags lists it and your next vatio push closes it. The tests are the reports on real conversations and the replies vatio test add keeps.

Earlier in the week: the guides by use case for bookings, orders, support and onboarding, vatio test running in the background on Vatio’s servers, and /vatio-analyze, which reads a stretch of redacted conversations and writes up what people ask. For the whole picture of a turn, read the AI agent runtime; for Flutter, an AI agent in your Flutter app.

0.93.0 — 2026-10-17

A flag on preview is a note, not a test. Flagging a reply in a test conversation, or with vatio flags add after a vatio chat (preview by default), now leaves a note for your coding agent: vatio flags lists it and says so, but it is no eval case, Vatio does not triage or fix it, it is not in the daily mail or in Continuous improvement, and your next vatio push closes it. The tests are the reports on real conversations and the replies vatio test add keeps, which now also keeps a reply that is not right yet: it fails until a version gets it right. The case of a preview flag that was already resolved stays, as a test; an open one’s goes.

The business description moved into the instructions. What the business does goes in agent.instructions. vatio business set --description is refused; a workspace that still has one keeps it in the prompt, vatio push and vatio business say so, and vatio business set --clear-description removes it once live runs instructions that say it. The name and brand stay in vatio business set, and in the inbox under Channels → Web widget: the Business page is gone.

The inbox’s Test shows the next version only when there is one. When live runs what preview runs, Test shows live alone; a push newer than live shows as a new version, with its tests and Publish. Test chats is part of Test now and only developers see it. View manifest and Roll back left the inbox: use vatio pull and vatio rollback.

0.92.1 — 2026-10-17

The inbox has no Tools page any more. vatio tools is where each tool’s calls, error rate, timeouts and p50/p95 are read, with the calls that failed and what your backend answered; its help no longer points at the inbox, and console_url in vatio tools --json is now the docs page that explains the numbers. The inbox also lost its environment switch: Conversations is real people’s, on live, and Test chats is the team’s own, on preview. A link with ?environment=preview opens in Test chats.

0.92.0 — 2026-10-16

A test runs the turn it is about, as it happened. A report’s test used to act the conversation out again: every visitor message sent anew, the agent’s earlier replies written again, as your test phone, today, with writes simulated. A reply whose cause was that world (your backend answering “this number has no account”) failed whatever the fix. Now a test is a photo of the turn, taken when it is made: the conversation as it happened up to the visitor’s message, who they were, when they wrote, and what your backend answered on that turn. vatio test writes only that turn’s reply, on the version under test. A tool call it repeats gets the answer your backend gave then when asking again would ask about somebody else (the tool’s request names the visitor) or would not be sent (a write with no test value); any other call goes to your backend again, so a fix there still shows, and the report says which answers came from the photo. See Eval runs.

vatio test add "NOTE" keeps a reply that is right. It replaces vatio flags add --passes: a reply that is already right is a test, not a report, so it has no report for Vatio to triage or fix and is not in the inbox. vatio test list lists them and vatio test rm ID removes one; their ids start with C-. The ones made with --passes are tests now, with their ids. See Tests from the terminal.

A 4xx your backend sends on purpose is an answer, not a failure. A report whose turn got “HTTP 404, this number has no account” reads Your agent: “Your backend answered HTTP 404 to get_context”, with the fix in what the agent does with that answer, and Vatio can try an instructions fix for it.

0.91.0 — 2026-10-16

Report a reply from the terminal. vatio flags add "NOTE" does what the inbox’s Report does: it reports the agent’s last reply in the chat vatio chat is in, or --chat ID’s, or any reply by --message ID, with what should have happened. It is a test case right away, so a few vatio chat --new "…" + vatio flags add "…" are a test suite vatio test replays on every version. --passes keeps a reply that is already right: the case is filed resolved in the version that gave it, Vatio does not triage it, and it is not pending in the inbox. See Tests from the terminal.

vatio chat show prints each message’s id, as [assistant #4821], the id vatio flags add --message takes.

0.90.0 — 2026-10-16

vatio share-session sends Codex sessions too. From inside Codex it takes the session it runs in (Codex names it in CODEX_THREAD_ID), and from a terminal the newest Claude Code or Codex session for the directory; --list shows both and says which is which. A Codex session is cleaned the same way: Codex’s system prompt, events, token counts and encrypted reasoning stay behind, images are dropped, and anything that looks like a secret, an email or a phone is replaced. --should-ask now answers from Codex as well, so a Codex that reads the docs offers to send its session when it finishes. See Share a session.

Codex is recognized on Windows. The CLI tells Vatio which coding agent ran each command; on Windows, Codex was reported as unknown.

0.89.0 — 2026-10-16

Vatio is an MCP server. Add https://vatio.ai/mcp to claude.ai, Claude Code, ChatGPT or any MCP client, sign in with your Vatio account, and build and run your agent from a chat: create a workspace, write its instructions, tools and knowledge, talk to it, run the tests, publish, roll back, read conversations and report replies. Signing in is OAuth on vatio.ai, with your second step if you have one, and each connection shows up, named after the app, under Account → Sessions in the inbox, where you can disconnect it. Signing the CLI in again no longer closes those. See Vatio in Claude and ChatGPT.

The agent can change outside your files. An edit from the MCP lands in preview as a deployment of its own, built on what preview ran. vatio push no longer replaces those edits without saying so: while preview carries edits your files have not seen, it is refused (preview_edited_outside) with the list of them, and vatio push --force overwrites them on purpose. vatio status and the manifest endpoint list them too.

vatio pull is back. It writes the agent preview runs (or --env live) into your files: each tools/NAME.yml exactly as deployed, and only the agent: block of your vatio.yml, key by key, so comments, workspace: and auth: stay as you wrote them. It wants a clean git tree, so git can give back what it replaced; --force writes anyway. After a pull or a push, the CLI remembers which deployment your files match, and the next push sends it.

Conversation exports carry message ids, so a reply found in vatio chat export can be reported by id.

0.88.0 — 2026-10-15

vatio push signs you in before it creates anything, again. The trial workspaces 0.83.0 deployed from a machine with no account are gone: the first vatio push opens the browser to sign in (email, Google or GitHub), then creates the workspace on your account, as it did before 0.83.0. Every workspace has an owner from the moment it exists. vatio init still asks for no account, and the trial on vatio.ai’s landing stays as it is.

A trial you already kept is an ordinary workspace and stays. One nobody kept is deleted tonight with the landing’s trials; its link to keep it works until then. vatio-init (skills 1.20.0) says the first push signs the developer in.

0.87.0 — 2026-10-15

The model’s reasoning no longer reaches the visitor. Now and then the model wrote its own thinking as the text of a tool call, in English, mid-conversation in Spanish (“wait, I should call knowledge_lookup”), and a turn that ended on that row sent it on Instagram; the web showed it too. Vatio now clears that text on every channel when it names one of the agent’s tools, talks about the visitor in the third person, or is in English while the visitor writes in another language. The tool call still runs. vatio chat show marks the row with no_interim_reasoning. See Safeguards.

vatio publish names a tool that failed every call on preview. A version went live calling a backend route that was not deployed yet, and nothing said so. Now, once a publish goes through, a notice names any tool whose calls on preview since that version was pushed (up to the last 24 hours, at least 3) all failed, with how the latest one did, and what to run next. It is a notice, not a refusal: a released CLI already prints it. See The publish gate.

0.86.1 — 2026-10-15

vatio share-session hides passwords in .properties files. A line like storePassword=… or android.injected.signing.store.password=…, as gradle.properties and an Android key.properties write them, went out as it was: only upper-case names such as DB_PASSWORD= were caught. Any key=value line whose name has password, secret or token in it now becomes [REDACTED], with or without a line number in front. --save still shows exactly what goes.

vatio tokens create --json prints the new token as JSON, and vatio tokens list --json the list. A script that hands the token to a secrets store reads it from there instead of grepping the text, so a failed command stops the script rather than storing an empty value. Publishable tokens has an example. The skills (1.19.0) tell your coding agent to use it, and to write npx @vatio-ai/cli@latest rather than vatio in any command it hands you to run yourself: the vatio installed on your machine can be too old for Vatio to accept.

Supabase now says what to check before rotating to an ES256 key (code that verifies tokens with the legacy secret, and Edge Functions with Verify JWT on) instead of promising nothing changes, and what to do if you are not ready to rotate: sign the visitor’s token yourself, from an Edge Function. vatio auth --supabase points there.

Claude Code’s auto mode refuses fewer Vatio commands. The Claude Code page has two settings for it. A rule in the project’s .claude/settings.json lets Claude Code run vatio and still asks you before publishing, rolling back, secrets and server keys. An entry in your own Claude Code settings tells auto mode that vatio.ai is yours, so vatio share-session is not taken for sending data out. vatio-init offers to add the project rule once the agent is pushed.

vatio whoami says which account this machine is signed in as. An email, a Google sign-in and a GitHub sign-in are separate accounts unless they share the address, and a workspace belongs to one of them, so a workspace_forbidden was often the other account signed in, with nothing to tell which. vatio whoami prints the account’s email and the workspaces it reaches, vatio doctor adds an Account: line, vatio login ends with the account it signed in as, and a workspace_forbidden error names it. The hint for workspace_not_found now says vatio push creates a missing workspace, and that vatio init is for a directory with no vatio.yml yet. See Workspace and account.

0.86.0 — 2026-10-15

Export a stretch of time’s conversations, redacted. vatio chat export --from 2026-09-01 --to 2026-09-30 prints what people said and what they were answered between two dates, one conversation per line as JSON, for reading them in bulk with a coding agent. Vatio redacts it before it leaves: names, emails, phone numbers, handles and Chilean RUTs read [FILTERED], and a person value counts people without naming them. Anyone on the team can run it, viewers included, and every page is in Activity. Reading a visitor’s chat with vatio chat show is now in Activity too, as opening it in the inbox is. See Reading conversations in bulk.

A skill that analyzes them. /vatio-analyze (skills 1.18.0) exports the dates you ask for, counts and reads every conversation, and writes a report: the topics people bring up with their counts and their own words, what the agent could not answer, and the content to write from it. Update the skills with npx @vatio-ai/skills. See Claude Code.

0.85.0 — 2026-10-15

A tool knows which channel it was called from. $chat.channel is where the visitor is writing — whatsapp, instagram, ios, android, widget, web or cli — and $chat.environment is live or preview. A backend shared by your app and your WhatsApp number can now tell them apart from the request alone, for example to look up only the account open in the app, without asking Vatio for the chat. Only whatsapp and instagram cannot be faked; see Tools.

0.84.1 — 2026-10-14

A Flutter SDK. flutter pub add vatio puts the agent in a Flutter app on iOS, Android and macOS. VatioChat is a ChangeNotifier holding the same conversation the iOS and Android SDKs give — messages, typing, connection, files and voice notes, the feedback moment and signed-in users — and the widgets are yours. The app sends ios-app:// plus its bundle id or android-app:// plus its package name, whichever platform it runs on, so its token allows both. See the Flutter SDK, and an AI agent in your Flutter app for a whole app.

vatio-add-to-app (skills 1.17.0) adds it to a Flutter app, with a chat screen written from the SDK’s example, instead of saying there is no SDK yet.

0.84.0 — 2026-10-14

The agent asks for a person with a tool of yours. The built-in handoff marked a conversation as waiting for someone and told nobody, so it waited. It is gone, with the business hours that decided when it muted the agent. To have the agent ask for a person, give it an HTTP tool that calls your backend, and alert whoever you want from there, with the two new placeholders: $chat.url opens the conversation in the inbox, and $chat.id is its number. The person who opens it and answers takes the conversation over, as before. The agent reads its own earlier calls on every turn, so it knows it already asked; your endpoint gets $chat.id to skip a second alert. See Human in the loop. vatio-init (skills 1.16.1) writes that tool for a new agent.

handoff: in vatio.yml is ignored with a warning, like hours:. Its when: list belongs in the new tool’s when_to_use. vatio business hours is gone, the inbox’s Business page no longer has hours, and the agent no longer gets them in its prompt: write them in the business description if customers ask.

0.83.0 — 2026-10-14

vatio push works before you have an account. On a machine with no account, the first push deploys the agent to a trial and prints two links: one to try it, which anyone you share it with can chat on, and one to keep it, which makes it yours once you sign in or create an account there. Until then you work as usual: vatio chat, vatio diff, vatio status and vatio kb work on its preview, and every push gives it another 7 days; one nobody keeps is deleted 7 days after its last push. Publishing, rolling back, secrets, tokens, keys, webhooks, routines and the channels need an account, and say so with the link to keep it.

Before it is kept, a trial’s tools make GET calls for real and simulate any other method, and it has no secrets: vatio push warns about a tool that reads $env.KEY. A trial takes up to 100 messages a day (the terminal and its try link together), 50 pushes, 200 tool calls and 3 knowledge bases with 50 entries and 1 MB.

Keeping it hands the terminal nothing. The next vatio command in that folder notices, signs the terminal in with the same browser code as vatio login and carries on, on your account. The workspace takes the slug your vatio.yml names when it is free; when it is not, the CLI updates workspace: to the one it got. Already signed in, with a trial left in the folder, vatio push goes to your account as before and reminds you of the link to keep the trial. vatio doctor shows the folder’s trial and when it is deleted.

vatio-init (skills 1.16.0) has your coding agent hand you both links.

Taken out in 0.88.0: pushing needs an account again.

0.82.1 — 2026-10-14

Your coding agent now puts the agent in your app. vatio-init stopped at the preview: putting the agent where your users talk to it was left to you. A new skill, vatio-add-to-app (skills 1.15.0), picks up there. In a web app it adds the widget; in an iOS or Android app it adds the SDK and writes the chat screen in your app’s style, from the example in each SDK’s repository. It creates a publishable token for development builds, which talk to preview, and one for release builds, which talk to live, each with your app’s origins, and passes your signed-in users along, from Supabase or from your backend. vatio-init offers it once you have tried the preview, and the procedure it follows is in the docs, under Putting the agent in the app. Update the skills with npx @vatio-ai/skills, or the plugin with claude plugin update vatio@vatio.

vatio auth --supabase ended by linking to a docs page that does not exist; it now links to Supabase.

Which phone the replays are. vatio test’s report says which test phone the replays talked as, by its last four digits: what a tool sent your backend as $contact.phone_number. vatio flags says it before you start, when a tool names the contact, or that there is no test phone and those tools cannot run in a replay.

0.82.0 — 2026-10-14

Vatio only takes calls from the current CLI. A coding agent drives the CLI from whatever is installed, and the notice of a new release prints only in a terminal, which an agent never has: one ran eight releases behind for days. A call from a CLI older than the release on npm is now refused before it does anything, with 426 cli_outdated and the version to run. From this release the CLI then runs that version through npx, with the same arguments and stdin, and says so on stderr; an older CLI prints how to update. The release before keeps working for five minutes after a new one is published, and vatio feedback, vatio share-session and vatio logout work from any version. See Current release only.

vatio flags rm ID removes a report and its test case, open or resolved, as Remove in the inbox does. It is the developer’s call: the flags digest and the vatio-improve skill (skills 1.14.0) tell a coding agent to propose it and run it only when asked.

A turn that runs out of tool calls answers. Vatio allows 12 tool calls per reply, then tells the agent to answer with what it has. A model can ask for several tools at once, and when such a request ran past the twelfth call, its remaining calls were refused one by one and the third refusal ended the turn with “I couldn’t generate a response”, before the agent had read the stop: turning seven expenses into fixed ones created four and told the person nothing. Refusals now count the agent’s requests, not its calls, and the request the budget ran out in does not count, so the agent answers with what was done and what was not.

Vatio’s apology goes out in one message. On WhatsApp and Instagram a reply is split into short messages, and so was “I couldn’t generate a response. Try again…”. The second half was an ordinary agent message: a supervisor could flag it, and its diagnosis blamed whatever else the turn did instead of saying Vatio wrote it. It is no longer split, and a flag on the second half of an older one is diagnosed as Vatio’s apology. A flag diagnosed as Your backend also says when the turn ran out of tool calls.

0.81.0 — 2026-10-12

vatio eval is now vatio test, and it runs in the background. vatio test starts the runs on Vatio’s servers, prints each run’s id and returns, so a coding agent no longer has to remember to background it. vatio test --wait waits for the judge, prints the report and exits 1 when a case fails, for CI and before vatio publish; it joins a run of the same version already going. vatio test --show RUN_ID prints a run so far. vatio eval still works as before, waiting by default, with a warning that it is deprecated: the name read as the shell’s eval to coding agents’ command guards, which refused it. The publish refusals, the flags digest and the vatio-improve skill (skills 1.13.0) now say vatio test.

Test runs say where to read a failing case. Each run’s id is printed as it starts, so vatio test --show RUN_ID works however the command ends. The report lists every case that did not pass with the vatio chat show CHAT_ID of its replay, earlier attempts included: what the agent said and every tool it called, not just the judge’s sentence. The help and the docs now say that vatio test --env live resolves the open reports it passes.

--help after a command prints help. vatio chat --help sent “—help” to the agent as a message, and other commands ignored it and ran: --help on the test command started a run. --help or -h anywhere after a command now prints the help and does nothing else.

Replays talk as your test phone. An eval replay had no contact, so a tool that identifies people by $contact.phone_number refused in every case, and a WhatsApp agent’s flags that needed one could never pass or resolve. A replay now talks as the phone you verified on Test → WhatsApp in the inbox (the newest, if there are several). A case the judge fails because a tool could not run without the contact’s phone, email or name is reported as not tested (no test contact for a tool), names the tool, and is not retried. See Eval runs.

A push says it is not live yet. Once a workspace is published, vatio push prints a notice: which version live still runs, and that visitors get the push, and the reports it fixes are resolved, only once it is published, with what to run first. In the inbox, the owner and developers get a Publish button on Continuous improvement next to the fixes waiting for it, even while other reports are still open, and a banner once preview has held a version live does not run for a day. Both go through the same checks as vatio publish, and Publish asks first, saying how many open reports the version does not fix. See Publishing.

0.80.0 — 2026-10-12

Is it your agent, your backend or Vatio? Every flag in vatio flags now starts with a Diagnosis that says whose it is to fix, read off what the turn did: a tool call to your backend failed, everything answered and the agent still got it wrong, or the model provider or Vatio failed. The digest opens with how many are each, and its instructions tell your coding agent not to change the agent for Vatio’s own. See Your backend, your agent or Vatio.

A reply Vatio wrote says why. When a turn produces no reply, Vatio still sends the visitor an apology. That reply now records the cause: the model provider was down, slow or refused, the model came back empty, Vatio failed, the agent kept calling tools, or a safeguard removed all it wrote. A request the provider rejects for what Vatio sent counts as Vatio failing, not the provider. The inbox says so on the reply and does not let a supervisor flag one of Vatio’s own.

vatio chat show says whose a problem is. A [your backend] line under each tool call is how your backend answered it. A [safeguard] line names the check that discarded or rewrote a draft, and a [vatio] line says why Vatio wrote a reply. vatio flags lists the safeguards too.

Eval errors name their cause. A case Vatio could not replay or judge is marked not tested (Vatio’s side), with the cause in words instead of a Ruby class. When it passes on live, vatio publish still waits for it, and now says it is untested rather than broken: run vatio eval again. The inbox’s Continuous improvement page says the same.

vatio status lists the replies Vatio wrote. A new vatio key counts the replies Vatio wrote in this workspace in the last 7 days, by cause, with the latest 5 and the chat to open. When there are any, it also says so on stderr. See Status.

Skills 1.12.0. vatio-improve reads each flag’s diagnosis first, leaves Vatio’s own alone, and runs vatio eval again for a case that was not tested.

October 5–11, 2026: Vatio 0.62.1, 0.63.0, 0.64.0, 0.65.0, 0.66.0, 0.67.0, 0.68.0, 0.69.0, 0.70.0, 0.71.0, 0.72.0, 0.73.0, 0.75.0, 0.76.0, 0.77.0, 0.78.0 and 0.79.0

Mon, 12 Oct 2026 12:00:00 GMT

0.79.0 — 2026-10-11

The console is part of the inbox now. Its pages moved to inbox.vatio.ai, one app with sections by role: Start, Test, Channels, Tools, Outreach, Team, Security and Account. The links the CLI prints (Try it: after vatio push, vatio env, vatio tools, vatio whatsapp, vatio instagram) open there, and vatio login lands there after you sign in at vatio.ai. Older CLIs keep working: the platform sends the new links and old console URLs redirect. JSON field names, console_url included, did not change.

The CLI names the inbox’s sections. vatio whatsapp and vatio instagram point to the Test page before you publish and to Channels after. vatio init --name before signing in says to set the name with vatio business set --name or on the Business page.

Skills 1.11.0. vatio-init hands over the inbox’s Test page, and a teammate who is not in the workspace yet is invited from Team in the inbox.

0.78.0 — 2026-10-11

A routine is a tool the agent decides to use. Give the agent a routine with tools/NAME.yml and routine: NAME, and add it to agent.tools. The agent calls it once the request is complete, asking first when it is not, and tells the person whether Claude has it in the same turn. A message from a routine’s number no longer starts the routine by itself, and --quiet is gone with it. The tool exists only in WhatsApp conversations with the routine’s numbers, so nobody else can talk the agent into it, and evals never start a real session. vatio routines create prints the tool file to add. See Routine tools.

0.77.0 — 2026-10-11

The agent can answer only some numbers on your WhatsApp number. vatio whatsapp only +56912345678, or The agent answers next to the Live switch in the console, makes the agent answer only those numbers; everyone else’s messages still reach the inbox, for you to answer. The numbers of your routines always count. vatio whatsapp everyone goes back to answering everyone, the default, and vatio whatsapp shows which it is. Set the list before switching Live on, and the agent never answers anyone else. See Who the agent answers (removed in 0.107.0).

A routine’s token is checked when you save it. Anything that is not a sk-ant-oat01-… token is refused right away, instead of failing with a 401 on the first message. Pasting the wrong thing from the clipboard is the usual cause.

0.76.0 — 2026-10-11

A WhatsApp message can start a Claude Code routine. vatio routines create connects a routine’s API trigger to the numbers that start it: when one of them writes to your number, Vatio waits for them to finish and starts the routine with where the conversation is, never what it says. The agent waits while they write and answers once, saying whether Claude has it or the routine could not be started. vatio routines runs shows each run with the link to its Claude session. Only WhatsApp starts one, because only there does Meta vouch for the number. See Claude Code routines.

A server key reads a conversation: GET /api/server/v1/:slug/chats/:id/messages, newest last, with what was forwarded, voice notes as text and signed URLs for files. It is how a routine catches up, and every read is in the workspace’s Activity.

0.75.0 — 2026-10-10

vatio share-session leaves out the people a session is about. Email addresses and phone numbers written with a country code become [EMAIL] and [PHONE], next to the keys and tokens that were already [REDACTED], and the summary says how many. The customers that come up in a database query are the team’s least useful part of a session, and what made Claude Code’s auto mode refuse to send one. Names, and numbers without a +, still go: --save shows exactly what would.

A shared session is deleted 30 days after it arrives. vatio share-session says so before it asks, and prints the date once it is sent; the row saying who sent one, when, and the feedback with it stays. Only the Vatio team reads a session, and every read is logged. The privacy policy lists it.

vatio share-session --list marks the sessions already sent, with their number and when. When a permission check stops the coding agent and you send the session from your own terminal, the agent checks there that it went.

Outside a workspace, the error says where one is. A command run one directory above a vatio.yml (vatio chat show, push, kb …) now names the nearby workspace and the cd to it, instead of asking for an API url.

Skills 1.9.0. When a permission check refuses to send the session, vatio-share-session gives you the command to run yourself instead of retrying, and checks with --list that it arrived. Before asking, it tells you how the session is treated: who reads it, that reads are logged, and when it is deleted.

0.73.0 — 2026-10-10

vatio flags and vatio eval say when the Vatio skills are out of date. They compare the Claude Code plugin’s version, or the copy npx @vatio-ai/skills made in the project, with the latest published skills (asked of npm at most once a day) and say how to update: claude plugin update vatio@vatio, or running npx @vatio-ai/skills again. Claude Code does not auto-update plugins from other people’s marketplaces unless you turn it on; see Keeping them up to date.

Skills 1.7.0. vatio-share-session offers to send the session with Claude Code’s own question (send it, send it with a comment, not now, don’t ask again) instead of a message, and npx @vatio-ai/skills leaves the version it installed next to each copy.

0.72.0 — 2026-10-10

vatio flags and vatio eval say when the Vatio skills are missing. Without the Claude Code plugin or the skills npx @vatio-ai/skills copies into a project, Claude Code has no /vatio:vatio-improve, so both commands end with one line on stderr saying how to install them. At most once a day per directory, never in CI; VATIO_NO_SKILLS_HINT=1 turns it off. See Improve.

The inbox’s Continuous improvement page is simpler. One box says what is next (reports open, with the command for the developer; fixes waiting to be published; a fix that broke something; or all resolved), reports are Pending, Resolved or All with one latest result each, and a report can be removed from its row.

0.71.0 — 2026-10-10

One loop: your coding agent fixes, Vatio verifies. A supervisor reports a reply in the inbox and writes what it should have said. One session of your coding agent takes every open report: vatio flags, fix, vatio push (updates preview, runs no tests), vatio eval (tests every report on preview), then vatio publish. In Claude Code, /vatio:vatio-improve (skills 1.6.0) runs it, with vatio eval in the background. See Improve your agent from flags.

vatio publish checks preview first. Once the agent is published, publish is refused until vatio eval has tested preview’s current version (evals_missing), while its tests are still running (evals_running), and when a report that passes on live fails on preview (evals_regressed, listed by id and title). Reports that still fail on both do not block, so a partial fix can ship. When it goes through, the reports preview passed are resolved with the version that fixed them, without testing again. vatio publish --force publishes over a regression anyway, failing results included. The console’s Publish button goes through the same check and publishes directly. See The publish gate.

vatio push does not overwrite an unpublished push from another branch. Once the agent is published, a push is refused when preview holds a version that is not live, pushed from another git branch (preview_has_unpublished_push). Publish it first, or vatio push --force to replace it.

Only preview and live. There is no environment per git branch and there are no named environments: --env takes preview or live (staging and sandbox still mean preview), and any other name is an error. Commands no longer pick an environment from the git branch, and vatio env rm is gone.

Proposals are gone. vatio propose, the inbox’s proposals and an owner accepting a change were removed; vatio propose now says so, and the proposals endpoints answer 410 proposals_removed. Test with vatio eval and publish with vatio publish.

The GitHub App integration is gone: pull request previews, publishing by merging, comments and checks on pull requests, the vatio-flags issue and connecting a repository. Signing in with GitHub stays.

“Ask for an improvement” and the Learning view are gone. A report’s state now shows on the reported reply in the conversation: open, fixed in preview, or resolved with the version that fixed it. The inbox’s Continuous improvement page lists every report with its latest tests and what vatio publish would say, with the prompt /vatio:vatio-improve; the daily email to the workspace’s developers links there.

Every report with a note is a test, wherever it was made, live or preview. A report made on preview after the first publish used to be a note with no test.

Evals run five cases at a time. A run of 27 cases takes 3 to 4 minutes instead of about 15.

0.70.0 — 2026-10-10

vatio logout revokes the token. It used to delete the token from this machine and nothing else, so a copy of the config file kept working. Now the token is revoked on Vatio first; offline, the local copy is still removed.

CLI tokens expire after 90 days without use. Each command slides the expiry forward, so a machine in regular use never notices. One left alone needs vatio login again. Every token alive today starts with the full 90 days.

Two-step verification. Passkeys, an authenticator app and recovery codes, in Settings → Security, which also lists every console browser, inbox device and CLI token signed in to your account and closes any of them. A workspace marked as holding sensitive data requires it from its whole team; for those workspaces the API answers two_factor_required until the account has it. See Two-step verification and sessions.

0.69.0 — 2026-10-09

base_url keeps its path. A tool’s path is appended to the base URL’s own path: https://<ref>.supabase.co/functions/v1 plus /my-tools/check_stock calls .../functions/v1/my-tools/check_stock. Until now the base URL’s path was dropped without a word and the call went to /my-tools/check_stock on the host. A path that already repeats the base URL’s path, the way around it, is not prefixed twice. See Declarative HTTP tools.

A reply makes at most 12 tool calls. After the twelfth, or after the same tool fails three times with the same message, the agent is told to answer with what it has and say what it could not do; a call after that is refused, so a tool that keeps failing no longer leaves the person without an answer. vatio chat show marks it with a [tool limit] line. See Tool results.

A failing tool’s own words reach the agent. On a non-2xx, a body with no message but a string error ({ "error": "...", "hint": "..." }) uses it as the message, instead of a bare “HTTP 422”.

A typed phone number is not asked for. Off WhatsApp, a tool that requires contact.phone_number used to tell the agent to ask for it, but a number typed in the chat never fills $contact.phone_number: only WhatsApp or the visitor’s sign-in do. The agent is now told not to ask and to say it cannot be done from that chat. See Required values.

vatio secrets list shows every environment. Each secret on its own line with its scope (every environment, only preview, tests), so a value set from a branch or with --env is never missing from the list; --env NAME still shows only what that environment reads. set and rm say which scope they touched. A key starting with VATIO_ is refused with a message that says so, instead of “Translation missing”.

0.68.0 — 2026-10-09

Start by installing the skills. The prompt on vatio.ai now has the coding agent run npx @vatio-ai/skills in the project first and follow the vatio-init skill it installs, and installing them is step one of Starting a new agent and of the quickstart. The skills stay in the repository, so the next session — or a different coding agent — finds how to start and improve the agent without being told again.

vatio-new is now vatio-init, and it looks first. Before creating anything it searches the whole repository for a vatio.yml, reads the app (its API, how its users sign in, its docs) and says what it found and what it recommends. With no agent it builds one, asking the owner only what the code does not answer. With one, it follows Joining an existing workspace: it never runs vatio init there, compares the folder with live, explains the agent and points at open flags and failing tools. npx @vatio-ai/skills removes the old vatio-new copy when it installs vatio-init.

vatio share-session: send the Vatio team your Claude Code session. When a sentence in vatio feedback is not enough, vatio share-session sends the session the coding agent is in (or the most recent one for this directory): what you asked, what it ran and what it was shown. Feedback in your words is optional: vatio share-session "what got in the way". Images and Claude Code’s own bookkeeping are left out, anything that looks like a key, token, password or private key becomes [REDACTED], and it shows which session goes and asks before sending; a coding agent sends only with --yes, after asking you. --save FILE writes exactly what would be sent instead, --list and --id pick another session. It needs you signed in, and only the Vatio team reads it. See Share a session.

A third skill, vatio-share-session. Say “send this session to Vatio” or run /vatio-share-session: Claude Code shows you what would go, asks, suggests adding feedback in your words, and runs vatio share-session. npx @vatio-ai/skills (1.5.0) installs it with the other two. When vatio-init or vatio-improve finish, Claude Code offers to send the session, with three answers: send it, not now, or don’t ask again. vatio share-session --should-ask decides whether to offer — at most once a week, never twice in a session — and vatio share-session --never stops it. See Claude Code.

0.67.0 — 2026-10-09

Tool metrics for your coding agent. vatio tools prints the console’s Tools page as a document a coding agent works from: each tool’s calls, error rate, timeouts and p50/p95 latency, then the calls that failed with what your backend answered and the vatio chat show that opens the conversation. --json gives the same as data. It reads the branch’s environment on a branch and live elsewhere (--env), over the last 7 days (--period). A failing tool seldom gets flagged, because the agent apologizes and moves on: this is where your agent finds it. See Tool metrics.

The last hour. The Tools page and vatio tools read the last hour as well as the last day, 7 and 30 days: enough to see whether a fix you just published stopped the errors.

Each tool call in vatio flags says how it went: the HTTP status, outcome and duration of the call to your backend, next to its arguments and response. The vatio-improve skill (1.4.0) and the AGENTS.md section vatio init writes point at vatio tools too.

0.66.0 — 2026-10-09

Publish through your tests. The console’s Publish buttons (the Test page and Environments) no longer publish at once: they propose the environment and take you to it in the inbox, where every eval case is replayed on it and the owner or a developer publishes it. preview can be proposed now, and deciding never removes it. Accepting an improvement publishes the version that was tested and takes its results live with it, instead of replaying every case on live again. vatio publish and a merge to the default branch still publish directly. See Eval runs.

A failing case is retried. The same case can fail once and pass the next time on the same version, so a case the judge fails is replayed again in a fresh chat, up to 3 attempts; only one failing all three counts as failing. One that passed on a later attempt says how many it took, in the report (F-7K2QX (2 attempts)), on the improvement and in Learning: it is unstable.

Test values for secrets. vatio secrets set KEY VALUE --tests sets the value every environment but live uses, and every eval replay, live’s included: one staging URL for everything that is not a visitor on live. list marks it (tests). A replay’s tool calls carry an X-Vatio-Test: 1 header, and a write (any method but GET) whose URL has no test value is not sent: the agent gets a success, and the judge still checks the call and its arguments. See Secrets.

Tests come from live. A report made on live is a test, and so is one made before the agent’s first publish. After that, a report from a preview or a branch is a note for whoever fixes the agent: it is in vatio flags, with Eval case: no, but nothing replays it.

Learning, simpler. The inbox lists each report as solved or not, under one card with what to do next. Asking for an improvement, and accepting one, happen on live only. Nobody overrules the judge any more: a supervisor who disagrees rewrites the note, which starts the case over.

0.65.0 — 2026-10-08

The docs live at vatio.ai/docs. Same pages, same Markdown contract, now under the main domain:

/docs/docs.md is the whole contract, and every page is also at its path plus .md, indexed in /docs/llms.txt.
Every docs.vatio.ai address answers with a 301 to the same path under vatio.ai/docs, so existing links keep working.
vatio docs fetches the same file as before, and any version of the CLI follows the redirect. This release only updates the URLs the CLI prints.

The widget is on npm, and open source. npm install @vatio-ai/widget mounts the same widget from your app’s code with mountVatioWidget(), returning identify and unmount — see From your app’s code. Its source is public under MIT at github.com/vatio-ai/widget. The script tag at cdn.vatio.ai/v1/widget.js is unchanged.

The skills are on npm. npx @vatio-ai/skills copies vatio-new and vatio-improve into a project’s .agents/skills/ and .claude/skills/, so Codex, Cursor, Gemini CLI, GitHub Copilot and Claude Code pick them up without the plugin. See Claude Code.

The browser SDK is back on the CDN as a classic script, cdn.vatio.ai/v1/sdk.js, which leaves the SDK on window.Vatio for a page without a bundler (Without a bundler). The old vatio.ai/vatio-widget.js and vatio.ai/sdk/1.js redirect to the CDN again.

0.64.0 — 2026-10-07

vatio propose: a fix the owner accepts from the inbox, without GitHub. On a workspace with no repository connected, push the fix to the branch’s environment and run vatio propose --title "What it fixes" (plus --summary or --summary-file for why). Vatio replays every eval case there and mails the workspace’s owner when the replays finish. In the inbox, under Learning → Improvements, the owner sees why, every case on live next to this version, what changes line by line against live, and a link to try it, then accepts (which publishes the environment, prompt, tools and knowledge together) or discards it. Accepting is refused while the replays run, when the environment was pushed again after proposing, and when a case that passes on live fails there. Either way the environment is removed and the proposal keeps its record. Proposing the same environment again updates it and replays the evals; vatio propose --list shows where each one stands. preview and main cannot be proposed: they are shared. See Without GitHub: propose it to the owner.

Ask for an improvement, from the inbox. On Learning, the owner and developers can have Vatio review the open flags. It reads each conversation, what every tool answered and how the agent is set up, and sorts the flags by cause. A fix in the agent’s instructions or knowledge it writes itself and opens as a proposal, tests running. A missing tool or one that fails (an error, a 500) it never works around in the prompt: Vatio has no access to your backend’s code, so it gives you a prompt for your coding agent instead. One review at a time, up to ten a day. See Ask for an improvement.

0.63.0 — 2026-10-07

Create WhatsApp templates from the CLI, and test them before you have a number. vatio templates create submits a template for Meta’s review on Vatio’s test number, so your coding agent no longer stops at the console to write one:

vatio templates create order_shipped --language es \
  --body "Hola {{1}}, tu pedido {{2}} va en camino." --example Ana --example "#1042"

Once Meta approves it, a preview key sends it to your test phones when the 24-hour window is closed — before, a preview key could not send a template at all. When you connect your own number, Vatio moves your templates to it under the same names, so the template your backend sends does not change when it goes live, and removes them from its test number. From then on your backend sends from your number with a live key: a preview key is refused with 409 use_live_key, and templates create submits straight to your number.

The template is checked before Meta sees it — the name’s format, {{1}}, {{2}}, … in order, one --example per placeholder, and no placeholder at the very start or end of the body. utility is the default category; pass --category marketing for promotions. vatio templates list --env preview shows the ones on Vatio’s test number, and vatio templates list tells a workspace with no number of its own where its templates are.

0.62.1 — 2026-10-05

vatio whatsapp and vatio instagram link to a page you can see. Before your first publish the console shows only the Test page, so they now print its WhatsApp or Instagram tab, where you verify a test phone or account and talk to your agent. After you publish they print that channel’s page under Integrations, where you connect your own number or account. vatio status reports published, plus whatsapp_url and instagram_url next to integrations_url, which also points at the Test page until you publish.

September 28 – October 4, 2026: Vatio 0.48.0, 0.48.1, 0.49.0, 0.50.0, 0.51.0, 0.52.0, 0.53.0, 0.54.0, 0.54.1, 0.55.0, 0.56.0, 0.57.0, 0.58.0, 0.58.1, 0.59.0, 0.60.0, 0.61.0 and 0.62.0

Mon, 05 Oct 2026 12:00:00 GMT

0.62.0 — 2026-10-04

Sign in with Supabase, with no code. If your users sign in with Supabase Auth, vatio auth --supabase names the project in vatio.yml (auth: supabase:) and stores its URL and anon key as secrets. Then:

Web: the widget reads the Supabase session already on the page and follows sign-in, sign-out and token refreshes. Nothing to add to the page.
WhatsApp and Instagram: the Sign in button opens your login page, and the widget on it hands the session to Vatio once the person is signed in.
Tools: forward $auth.token to the project’s REST API and your Row Level Security decides what the visitor sees.

Or skip the command: Connect Supabase in the console (Channels) signs in to Supabase, picks the project, sets the secrets and shows the auth: line; vatio auth --supabase then uses that project, and vatio diff warns when vatio.yml names a different one.

Vatio verifies against the project’s public keys, so the project has to use JWT signing keys (ES256 or RS256); a push with a project still on the legacy HS256 secret is refused with the fix. See Supabase.

0.61.0 — 2026-10-04

Send WhatsApp messages from your backend. Your backend calls POST /api/server/v1/:slug/messages with a number and what to tell them, and the agent keeps answering when the person replies:

text goes out exactly as written, when the person wrote in the last 24 hours.
brief has the agent write the message itself.
template is the approved template to send when the window is closed, which is the only thing WhatsApp delivers then.

The request answers 202 at once and Vatio sends right after. The agent is shown the brief when the person answers. Around it:

Idempotency-Key, so a retry never messages anyone twice.
identity, a JWT your workspace signed, so private tools run when the person answers.
Signed webhooks: message.sent, failed, delivered, read, delivery_failed and replied, with a delivery log and a ping.
GET /messages and GET /templates, with each template’s parameter count.

Server keys. The server API takes a server key (vsk_…), not your CLI token. A key belongs to the workspace and one environment, and survives vatio login.

New commands.

vatio keys list|create|revoke.
vatio templates list.
vatio webhooks list|create|test|deliveries|enable|rm.

0.60.0 — 2026-10-03

Signing in works when a coding agent runs the CLI. vatio push (the first time) and vatio login open the browser on Vatio’s sign-in page for that terminal and print the terminal’s code; on a machine with no browser they print the link, and tell a coding agent to show it to its human. There you sign in with your email — Vatio mails a link that signs you in on any device, creating the account if there is none — or with Google or GitHub, check that the page shows the same code, and confirm the terminal. After vatio push, the page then waits for the push and turns into the console’s Test screen. If the wait is cut off, running the same command again picks up the same sign-in page instead of starting over. The CLI no longer asks for an email. The device authorization start endpoint takes an optional workspace slug.

The hosted pages at vatio.ai/w/ are gone. Try an agent in the console’s Test screen — web chat, WhatsApp and Instagram — at the link vatio push and vatio env print after Try it:. To put it in front of customers, embed the widget on your own site, connect WhatsApp or Instagram, or use the SDKs. vatio env no longer prints a page link, and page_url is gone from the environment API.

The Test screen handles several numbers and accounts. Its WhatsApp and Instagram tabs list and verify up to five test phones and five test accounts, instead of only the latest one.

0.59.0 — 2026-10-03

vatio feedback. Tell the Vatio team what got in the way, in a sentence: vatio feedback "push said the tool was invalid but not which field". Coding agents are asked to run it when an error or the docs left them guessing; it arrives with the commands the session ran before it. See Feedback.

Errors say what to do next. API errors now carry a hint when there is a known next step, and the CLI prints it as Next: along with the error code and request_id. See Errors.

Telemetry. The CLI now reports how each command ended — its name, exit code and, on failure, the error it printed — with its version, the coding agent running it and a session id. Arguments, file contents and secrets are never sent. The first command on a machine says so once, and VATIO_TELEMETRY=0 turns it off. See Telemetry.

0.58.1 — 2026-10-03

A flag’s note is what should have happened. Supervisors write more than the sentence the agent should have said: an action, a tool it should have used, a handover. The inbox now asks for What should have happened, and vatio flags, the GitHub issue and the daily mail say the same.

The judge sees tool calls. Eval replays now show the judge every tool the agent called, so a note that asks for a tool passes when the agent calls it. An answer the judge could not read is an error, no longer a fail against the agent.

Analytics and Learning in the inbox. Analytics shows conversations per channel, handoffs, open flags and visitor ratings over 7, 30 or 90 days. Learning shows what became of every flag (pending, in testing, fixed, failing again) with every replay of its case, and lets a supervisor overrule the judge. A person’s verdict wins, and on the newest live replay it decides whether the flag is fixed.

0.58.0 — 2026-10-03

The brand belongs to the business too. The logo, the brand color and the widget’s “about” are set on the inbox’s Business page, next to the name and hours, and no longer on the console’s Widget page, which keeps the rest of the widget’s look. From a terminal: vatio business set --logo FILE | --remove-logo, --color #RRGGBB | --color default and --about TEXT. PATCH /business takes about, accent_color and logo (base64). See Business.

0.57.0 — 2026-10-03

The business and its hours belong to whoever runs it. The business name, description and opening hours live on the workspace and are set on the new Business page of the inbox — a time zone and shifts per day, or someone always available. They apply to every environment as soon as they are saved. The agent now also gets the weekly hours, so it can tell a customer when you are open.

hours: is ignored in vatio.yml. A push that still has it succeeds and prints a warning with a link to the inbox page; existing hours were carried over to the workspace. handoff: stays in vatio.yml. The console’s Widget page no longer edits the name and summary; it links to the inbox.

vatio business. Read and set the same business from a terminal: vatio business, vatio business set --name … --description …, and vatio business hours --timezone … --mon 09:00-18:00 … or --clear. See Business.

0.56.0 — 2026-10-02

One agent per workspace. agents: and entry: are gone from vatio.yml; a workspace runs one agent:, and private tools behind auth: cover what a second, signed-in agent was for. A push that still has them fails and says what to change.

vatio issue is gone; report on GitHub. Bugs and feature requests now go to the public repositories: cli, sdk, ios and ruby. Running vatio issue says where to go, and so does an older CLI that still has the command.

A smaller CLI. It now keeps only the commands a developer runs to build and ship an agent:

vatio chat is two commands. vatio chat "message" [--new] talks to the agent, and --new starts over as a visitor it never met. vatio chat show [CHAT_ID] prints the chat you are in, or any chat, with every tool call. transcript, debug, reset and destroy are gone, and each one tells you what to use instead.
vatio tools check is gone. vatio push validates before it deploys, and vatio diff validates without deploying.
vatio widget is gone. vatio env prints the snippet and its token, and the look is edited on the console’s Widget page.
vatio mcp is gone. Point your coding agent at vatio docs --save.
WhatsApp and Instagram are set up in the console, on the Channels page: your own number or account, test phones, and test accounts. vatio whatsapp and vatio instagram print that link. Older CLIs get the same answer.

Every API is named after who calls it.

The developer API (what the CLI uses) lives at /api/developer/v1.
- Its routes read like the CLI: /:slug/deploy/* is now /:slug/check, /push, /publish, /rollback, /status, /manifest, /env and /secrets.
- Signing in and creating a workspace move from /cli/* to /api/developer/v1/device_authorizations and /api/developer/v1/workspaces.
- /deploy/revisions is gone.
The visitor API (the widget and both SDKs) lives at /api/visitor/v1. The JavaScript SDK 3.3.0 and the iOS SDK 0.3.0 call it there.

/api/v1, /cli/* and /api/public/v1 keep answering, for clients released before these.

Server-to-server is removed. None of it was in use:

The phone verification API, along with agent: false.
Conversations over the API with no visitor (the api channel).
The identity mint, and auth.mint in vatio.yml. WhatsApp and Instagram visitors are anonymous, and only public tools run for them. Signed-in visitors on the web work exactly as before. vatio-identity 0.3.0 signs and verifies the JWT, and no longer mounts a mint endpoint.

The widget is a bubble only. data-display="page" and data-mount are gone.

Agent modes are removed. modes, initial_mode and mode_reset_after in vatio.yml, and the switch_mode tool, no longer do anything. A push that still has them succeeds and warns that they are ignored; each agent works from its own tools and knowledge.

Knowledge is what you write. vatio kb follow, unfollow and refresh are gone, and Vatio no longer reads or re-reads websites. Pages it had already read stay as ordinary entries you can now edit (vatio kb cat / kb write).

Console notices show their message again. Inviting, resending or removing a team member, and registering, verifying or moving a test WhatsApp number, showed “Translation missing” instead of the confirmation or the error. They read correctly now.

0.55.0 — 2026-10-01

Flagged replies become work your coding agent can do. vatio flags prints every reply a supervisor flagged in the inbox as one document for a coding agent: the conversation, each tool call of that turn with what your backend answered, and what the reply should have been. Each flag is now an eval case, and vatio eval replays every case against an environment — the branch’s by default — with a judge comparing each reply to the supervisor’s note; it exits 1 when a case fails. Evals also run on every pull request preview, commented on the pull request, and after every publish to live, which is what marks a flag fixed in the inbox. The judge is a model from a different family than the agent’s, and replay chats stay out of the inbox and out of the conversation count. vatio init now adds a short Vatio section to the workspace’s AGENTS.md, and the Claude Code plugin at github.com/vatio-ai/skills adds two skills: vatio-new to build an agent from scratch and vatio-improve to work through flags. The docs’ For coding agents section now spells out how to start a new agent, so any coding agent reading vatio docs follows the same steps. Every morning, workspaces with new flags get a mail and, with GitHub connected, one issue labelled vatio-flags holding the digest, ready for a coding agent on GitHub to pick up. See Improve your agent from flags.

0.54.1 — 2026-10-01

Source and issues are public. The CLI, the JavaScript SDK, the iOS SDK and the vatio-identity gem each have a public repository under github.com/vatio-ai, where you can read the code and open issues. Swift packages now install from https://github.com/vatio-ai/ios, and the gem installs with gem "vatio-identity", git: "https://github.com/vatio-ai/ruby". Nothing else changed.

0.54.0 — 2026-10-01

Every git branch is an environment of its own. On a branch other than the default one, the CLI works in that branch’s environment without --env — fix/pagos is fix-pagos — and says so on stderr: push, chat, kb write, secrets set, tokens and publish all use it. The branch’s pull request deploys to the same environment instead of a separate pr-N, so what was tried there before the pull request existed is still there. On the default branch and outside a repository, every command keeps its old default. Several people or coding agents can now fix several conversations at once, each in a worktree, without their changes meeting before they merge.

Knowledge changes belong to an environment, and go live with it. The entries are what live answers from; a supervisor’s edit in the inbox, the console and a site re-reading a page change live directly. On a branch, vatio kb write makes a change only that branch answers from, and publishing the branch — vatio publish, or merging its pull request — takes the prompt and the knowledge live together. When live changed an entry the branch also changed, publishing is refused and names it; rewriting the entry on top of live clears it. Each environment has a page in the console with the diff of every entry it changed, where a conflict is resolved in place — keep the branch’s version, take live’s, or combine them. Pull requests get a vatio/knowledge status that turns red before the merge and links to that page, and a comment listing their knowledge changes. Today’s unpublished draft became the changes of preview.

A deployment is a snapshot of the whole agent. Once live, it records the version of every knowledge entry written by hand it answered from. Publishing, and a supervisor’s edit in the inbox or console, leave a new snapshot; vatio rollback moves live back one, prompt and knowledge together. Pages a site reads are not part of it. Environments other than live are disposable, with everything in them.

vatio env. Shows the environment you are in: its publishable token, the widget snippet, the link to try it, its knowledge changes and any conflicts. vatio env list shows every environment and vatio env rm NAME removes one. An environment with nothing left to publish is removed after 14 days idle.

A secret can have its own value in one environment. On a branch, or with --env, vatio secrets set sets the value only that environment uses, so a branch’s tools can call staging while live calls production.

A simpler console. Its menu is now Environments, Test and Channels. Environments lists live, preview and every branch, each with its deployment, agents, knowledge changes and conflicts, and secret names; GitHub is connected there too. Under Channels, the Widget page holds the install snippet, the brand settings and the tokens with their allowed origins, which used to be three pages. Knowledge is edited in the inbox (or the CLI); the console keeps each environment’s knowledge review. The public page, /w/<slug>, is live’s: the business with the widget’s bubble, no longer a full-screen chat. Each other environment has the same page at /w/<slug>/<environment>, for the workspace’s members; push, vatio env and pull request comments link to the console’s Test screen for it, and the /w/<slug>/p/… share links are gone.

Every channel can point at a branch. Each test phone on the shared WhatsApp number and each test account on the shared Instagram one reaches the environment it points at — vatio whatsapp numbers point PHONE --env NAME, vatio instagram accounts point ID --env NAME, or a selector in the console — instead of always preview. With the CLI on the branch, the widget and SDKs on its token, and /w/<slug>/<environment> for the workspace’s members, a branch is tried on every surface without touching live.

Breaking

Preview share links (/w/<slug>/p/…) no longer open: try an environment in the console’s Test screen, signed in. The API’s share_url now points there.
vatio kb rollback and the knowledge publications behind it are gone. vatio rollback now takes the knowledge back with the prompt; to go back on one entry alone instead: vatio kb history BASE lists what reached live, vatio kb cat BASE ENTRY --version N prints one, and writing it again with --env live restores it. The API’s snapshots paths answer 410.
vatio kb publish no longer takes -m, and publishes the current environment’s changes to one base.
Pages a site reads go live as soon as they are read, instead of waiting for a publish.

0.53.0 — 2026-09-30

The workspace’s brand is edited in the console, not in vatio.yml. The business name and summary, and the widget’s look (accent color, about, logo, locale, greeting, suggestions and the rest), live on the workspace’s new Brand page. They are one setting for every environment and apply as soon as you save. business:, widget: and root allowed_origins: in an existing vatio.yml still push, but they are ignored: vatio push, vatio check and the GitHub pull request comment print a warning with the console link. Remove them when convenient.

Allowed origins belong to each publishable token. A token works only from the origins listed on it, plus Vatio’s own pages. Every token started with the origins your workspace had, so nothing stops working. Edit them on the console’s Tokens page (the install snippet’s token is there too), or with vatio tokens create --origin URL (repeatable) and vatio tokens origins PREFIX URL.... vatio tokens list shows each token’s origins, and vatio init no longer writes business:.

0.52.0 — 2026-09-30

With GitHub connected, live changes only by merging. A workspace bound to a repository publishes when a commit lands on its default branch, and nowhere else: vatio publish is refused with a message naming the repository and the branch, and so are vatio push --env main and vatio push --env pr-N, which belong to the integration. vatio push to preview or another named preview still works, and vatio rollback stays as the emergency button.

Every GitHub deploy shows on its commit. Previews and publications post a commit status (vatio/preview (workspace), vatio/live (workspace)), green or red, linking to the preview, live or the console. A failed publication used to leave no trace outside a server log. Deploys to one workspace now run one at a time, and a merge that finishes late never replaces a newer one already live.

vatio publish without GitHub prints a notice. It works as before; the notice says publishing from the CLI will soon require a connected repository.

0.51.0 — 2026-09-30

Knowledge has a draft, a live version, and history. Every write to a base — vatio kb write, a site re-reading a page, an edit in the console or the supervisor inbox — lands in the base’s draft and is kept as a numbered version of its entry. Preview answers from the draft; live answers from what was last published. vatio kb status BASE shows what live does not have yet, vatio kb publish BASE -m NOTE takes it live, vatio kb history BASE lists every publication, and vatio kb rollback BASE NUMBER points live back at one instantly. Everything a base held before this release is already published, so live answers exactly as it did.

Supervisors can edit knowledge from the inbox. Written entries can be created, edited and deleted there, each entry shows its history with a diff and a restore button, and “answered from” in a conversation now links to the exact version the agent had.

0.50.0 — 2026-09-29

vatio secrets set KEY asks for the value. Leave VALUE out and the CLI prompts ? Paste your secret: and echoes a * per character, so the value never lands in your shell history. Off a terminal it reads stdin instead: op read op://Vault/item/field | vatio secrets set KEY. set KEY VALUE works as before.

The CLI tells you when a new release is out. After a command, if npm has a newer @vatio-ai/cli, you see the version and the command to upgrade. It checks the registry at most once a day, only when stderr is a terminal, and never in CI or under vatio mcp. VATIO_NO_UPDATE_NOTIFIER=1 turns it off.

0.49.0 — 2026-09-29

The identity token can enrich the inbox. Add a metadata claim to the JWT you already sign, and the inbox shows it in the conversation header:

"metadata": {
  "profile": "https://acme.com/admin/users/42",
  "badges": { "plan": { "value": "Premium", "tone": "green" }, "country": "CL" }
}

profile becomes a Profile ↗ link to the person in your own admin. If it is not an http(s) URL, the header shows a quiet “Invalid profile link” warning instead. Each entry in badges is a chip, and an optional tone (green, amber, red, gray) colours it. Nothing changes for tokens without metadata. vatio auth --new-key now lists the claim. See Enrich the inbox.

0.48.1 — 2026-09-28

vatio update now points to the correct npm package. The command recommended vatio@latest, which returns a 404 from npm. The package is @vatio-ai/cli; the executable it installs is vatio. The message now recommends npm install -g @vatio-ai/cli@latest for a global install and npx @vatio-ai/cli@latest to run the latest release directly.

0.48.0 — 2026-09-28

A bare vatio publish promotes your latest push. It used to promote whatever the preview alias pointed at, so vatio push --env pr-42 followed by vatio publish re-published the old preview and live never changed. Now it takes the most recent deployment, whichever preview it landed on, and says which one: Published live deployment #80 from pr-42. --env NAME still promotes a specific preview.

vatio chat show CHAT_ID reads any chat in the workspace. A visitor’s chat on the web or WhatsApp, not only the one your CLI opened: the channel, the environment and deployment that answered it, every message and every tool call. --json prints the raw payload.

September 21–27, 2026: Vatio 0.33.0, 0.34.0, 0.35.0, 0.36.0, 0.37.0, 0.37.1, 0.37.2, 0.38.0, 0.39.0, 0.40.0, 0.41.0, 0.41.1, 0.42.0, 0.43.0, 0.44.0, 0.45.0, 0.46.0, 0.47.0 and 0.47.1

Mon, 28 Sep 2026 12:00:00 GMT

0.47.1 — 2026-09-26

The README this package publishes was describing a runtime that no longer exists. It said tools/, lib/ and auth/ next to vatio.yml were “plain JavaScript the agent runs”; tools have been one HTTP request in YAML for a while now, and there is no JavaScript runtime. Its command list was also nine commands short — chat, kb, docs, mcp, issue, whatsapp and instagram among them.

Nothing in the CLI changed. The version moves because the README ships inside the tarball, and npmjs.com is where most people meet this package for the first time — a wrong README there is wrong in the one place it is read most.

0.47.0 — 2026-09-26

init no longer asks for an account, and push asks by email.

vatio init used to stop and wait for a human to approve a code in a browser before it would write a file. That put the one step only a person can do at the very front — before your coding agent had built anything, and before you had any reason to care.

Now docs, init and tools check never touch the network. Your agent can write the whole workspace before an account exists. vatio push is the first command that makes something run on a server, so it is the one that asks who you are:

$ vatio push
  Before I can push this, I need to know whose it is.
  Your email (we send you a link): you@example.com

  We emailed you a link.
  This terminal is HXKT-4820 — check it matches before you approve.

One click on that link creates your account if it did not exist, authorizes the terminal, and drops you in the console. No password, no separate sign-up, no code to retype — the device code is still there, but you compare it instead of typing it. It has to match what your terminal printed.

Signing in to the console with an email we have never seen now creates the account too, which is what Google and GitHub always did here.

The console opens as your agent exists. Before your first push it is one screen with one command. After it, it is the screen you test on: your agent behind three doors — web, WhatsApp, Instagram — and beside them what the terminal cannot show you. Which tool it called with which arguments and how long each took, which knowledge it read, whether a handoff rule fired, tokens and latency. That panel keeps its shape whichever channel you pick, because it is one agent with three entrances.

WhatsApp and Instagram verification happens on that same screen now, as three steps, instead of being a detour to another page.

Publishing lands on one question — where will people write to it? — with what WhatsApp and Instagram each need from Meta listed before the button rather than halfway through their popup.

Breaking

The push response field whatsapp_preview_hint is now first_push_hint, and it points at the test screen. A CLI older than this one stops printing that one-time nudge after a first push; nothing else changes.
The Widget page, the Usage page and the full-window preview visitor page are gone. Installing the chat on your site is part of Integrations, testing is the test screen, and usage comes back as analytics when there is something to analyse.

0.46.0 — 2026-09-25

The docs are their own site: docs.vatio.ai.

They used to be one 1,700-line page built into the platform’s Docker image. That cost two things worth losing. Fixing a typo paid for an image build and a rollout, and every reader — person or agent — got all of it or none of it.

Now there is a page per topic, with a search field, four tabs — Documentation, CLI, SDK, API Reference — and Spanish alongside English. Everything that pointed at vatio.ai/docs still works: it redirects, including the anchors of the old single page.

For agents, the contract is still one fetch. vatio docs is unchanged and still prints the whole thing, because vatio.ai/docs.md redirects to docs.vatio.ai/docs.md — no upgrade was needed for that. What is new is that every page is also Markdown on its own path plus .md, indexed at /llms.txt, so an agent working on one thing can read the one page about it instead of spending a context window on the whole contract.

Where the CLI prints a docs link — vatio --help, vatio auth --new-key, the message when vatio docs cannot reach the host — it now names the new site.

0.45.0 — 2026-09-25

vatio issue sends the workspace, not just the sentence.

Run from a workspace, the command now attaches the directory — the same files vatio push sends. A report about a tool arrives with the tool, and a report about a manifest that will not push arrives with the manifest that will not push, which is precisely the one Vatio could not see before: what it held was the last version that pushed successfully.

Vatio keeps vatio.yml and everything under tools/, lists the rest of the directory by name, and records what its own checks made of it at that moment. Anything a check complained about comes along too, so the tools/*.js and lib/*.js that 0.42.0 stopped accepting arrive with the report that asks how to port them.

Hidden files are never included, so .env and .git/ stay where they are. The command prints what it is attaching before it sends, and --no-source sends the report on its own.

0.44.0 — 2026-09-24

vatio issue list shows your issues. It reported that you had sent none while vatio issue show <id> returned those same issues, because the command read the wrong key off the response and got an empty list every time. list is the only way back to a report whose number you did not keep, and an empty one reads as “it never went through” — which is how the same problem gets filed twice.

Each row now says where the report stands — sent, in progress, with us, answered or closed — and prints the pull request when there is one, so a coding agent can watch the fix land instead of waiting to be told.

vatio kb create takes several names. A first push that declares two knowledge bases refused twice and cost a round trip per name. It now refuses once, for all the missing bases at once, and names the single command that creates them:

knowledge: no knowledge base named "docs" or "policies" on this workspace.
Create them with `vatio kb create docs policies`, then push again.

Still nothing implicit: a base exists because someone typed its name. That is what keeps knowledge: [defualt] a failed push rather than an empty base the agent searches forever, quietly answering with nothing.

Docs: the root-key table listed identity, knowledge and links, all three of which were removed in 0.41.0 and 0.43.0 and now fail the push. It lists auth, agents and entry instead.

All three were reported through vatio issue.

0.43.0 — 2026-09-24

A workspace can run several agents, and the manifest says which one answers.

Key them under agents: instead of agent:, and add an entry: table:

agents:
  home:
    name: Ana
    instructions: Answer product questions. Nobody here is signed in.
    tools: [knowledge_lookup]
  portal:
    name: Ana
    instructions: You are talking to a signed-in customer.
    tools: [my_orders, knowledge_lookup]
    knowledge: [portal_kb]

entry:
  - { authenticated: false, agent: home }
  - { claims: { role: staff }, agent: staff }
  - { agent: portal }

The table is ordered and the order is the rule: the first row whose conditions hold wins, and the last row is the fallback. Letting each agent declare its own entry condition was the other design, and it loses on precedence — two agents that both say “authenticated” need a specificity rule nobody wants to reason about. Here the whole policy reads top to bottom in one place, and a reviewer can check it without knowing how Vatio works.

This is for the marketing site and the customer portal that embed the same widget. The anonymous visitor asking about prices and the signed-in customer asking about their own records are not the same conversation, and one set of instructions serving both serves neither. Until now that meant two workspaces: two manifests, two knowledge bases and two tokens to keep in step.

agent: still means exactly what it did — one agent, keyed main.

knowledge: and links: move onto the agent. They used to sit at the root and apply to the workspace; now each agent states its own, and there is no inherited default. A manifest that still declares either at the root fails the push and says where to put it — one edit, and vatio diff shows nothing else changed.

The repetition is the point. What an agent knows and which urls it may hand out are the two things you check when it answers wrongly, and an inherited value means looking somewhere else and then working out whether this agent overrode it. It also matters in the prompt: every declared url is listed there, so a portal agent would otherwise carry a marketing agent’s whole link list around without ever handing one out. Duplication you can see beats inheritance you have to reconstruct.

Which agent you get is settled before the first reply, on every channel: Vatio verifies the token as the conversation opens, so the choice happens before the first message is answered rather than after. Sign in mid-conversation and identify() runs the table again — same thread, same history, and from the next message on, the agent for who you now are.

entry: is not a security control and is not built as one. A visitor with no valid token has no verified identity, so no access: private tool runs for them whatever agent they land on: a wrong row shows the wrong prompt, never someone else’s data. Protect data with access: private on the tool, as before.

No migrations. A workspace with one agent needs one edit: move knowledge: and links: inside the agent: block.

0.42.0 — 2026-09-24

A tool is one HTTP call to your backend. JavaScript tools are gone.

tools/*.js ran in a sandbox Vatio operated, and lib/*.js were the helpers bundled with them. Both are removed, along with the runtime behind them.

The reason is the same one that removed auth/*.js in 0.41.0: the file you wrote was never really the point. Every JavaScript tool deployed on Vatio was either a call to a backend the workspace already ran, or the scaffold nobody edited. Meanwhile the platform was carrying a bundler, a sandbox, a deploy step and a second execution model so that code with somewhere better to live could live here instead.

So it lives there. Describe the call in tools/<key>.yml with request: and respond:, and put whatever the call needs to do — branching, a second request, composing a response — in the endpoint it hits. That endpoint is yours: it can already read your database, and it does not have to be redeployed through us to change.

vatio push and vatio tools check refuse a tools/*.js or lib/*.js and name the file. Nothing else in a manifest changes, and access: private, $auth, $env and the result contract all work exactly as they did.

Also gone: the 301 from /vatio-widget.js to the CDN, which no page still used, and a route: field documented on tool results that was never implemented.

0.41.1 — 2026-09-23

vatio auth --new-key told you to keep identity.pem secret and stopped there, which left the one question a developer actually has unanswered: secret where. It says it now, and so do the docs — the private half goes into your own backend, because your backend is what signs, and then out of the workspace directory.

Explicitly not into vatio secrets. That store is read by Vatio, and a private key in it would let Vatio mint tokens for your users rather than only check them, which is the property the whole design is built around.

0.41.0 — 2026-09-23

Authentication is one JWT you sign, on every channel.

There used to be two ways to tell Vatio who a visitor is: an identity: block that verified a token your page signed, and auth/*.js — a JavaScript file you wrote, deployed and maintained, whose whole job turned out to be one HTTP call. The second existed because WhatsApp carries a phone number and nothing else, so someone has to ask your backend whose it is. Asking is fine. What was wrong is what came back: a plain answer Vatio then asserted to your own API. The platform ended up being something you had to trust about identity.

Now it carries proof instead. You sign a JWT, Vatio verifies it with your public key, and your tools get it as $auth.token. On the web your page puts it on the widget. On WhatsApp Vatio posts the phone number to your mint: endpoint and you sign one back — the same token, verified the same way. Vatio holds only a public key, so it can check a token and never mint one, and that is now true on every channel rather than only on the web.

auth:
  public_key: identity.pub
  mint:                                  # only for channels with no session
    url: $env.API_URL/api/vatio/identity

vatio auth --new-key generates the pair, gitignores the private half, and prints the exact claims to sign.

Also: the token’s expiry means something now. The old design resolved a visitor once and cached the answer for the life of the conversation, so a twelve-hour token stopped being checked after the first minute of a chat that ran longer. Verifying a signature costs microseconds, so it happens on every tool call. On WhatsApp an expired token re-mints itself and the conversation carries on.

Signing in no longer costs you the conversation. Someone asks a question, the agent tells them to sign in, they do, and they come back: the chat they already had is still there, now with a name on it. Whether they signed in through identify() or by navigating away and reloading the page with a token makes no difference.

It used to start over — and a visitor who was already signed in lost their conversation on every page reload, because the SDK’s session key was computed over the whole token and a backend signs a fresh one on each render. The key is the subject now.

What is never carried over is somebody else’s conversation: a chat that belonged to sub A never passes to sub B, so signing in as a different person looks exactly like arriving for the first time. The server decides that, not the page.

Breaking. identity: is auth:. authentication.schemes and auth/*.js are gone, and so are scheme names: a tool is access: private or public. audience is no longer declared — it is your workspace slug, and it is now required in the token, so a JWT you signed for something else cannot be replayed as an identity. A private tool that declares user_id (or customer_id, account_id, member_id, patient_id, subject) as a parameter now fails the deploy instead of warning: the model fills parameters, so that one was always a way to ask for someone else’s data. Every error names what to do instead.

0.40.0 — 2026-09-23

A knowledge base holds entries, and an entry is Markdown.

It used to hold “sources”, and a source was either a crawl — which produced documents you could not open, let alone fix a typo in — or an upload, which kept only the chunks it was cut into. Three words for two things, and you had to know which was which to read the screen. Now there is one kind of content: an entry, written by you or written by a site.

A site is one URL. No include or exclude lists: the URL says it, and a URL is that URL while a pattern is every page that matches it.

What you write	What it reads
`acme.com`	the home page, and only it
`acme.com/help`	that one page
`acme.com/**`	every page of the site
`acme.com/help/**`	that section, however deep

Vatio reads each site again every night and rewrites the entries it owns, so a base keeps up with the pages it mirrors without anyone pressing a button. A page whose Markdown has not changed costs one request and nothing else — it is not re-indexed and not re-embedded. An entry a site wrote is not editable: the next read would overwrite it without a word, so you change the site.

Same actions everywhere. vatio kb write BASE ENTRY [FILE] puts Markdown under a name — creating it or replacing it, reading stdin when no file is given — vatio kb cat prints exactly what Vatio holds, and vatio kb follow, unfollow and refresh manage sites. add-source, upload, rm-source and reindex are gone, along with the two kinds of source they addressed. In the API, entries live at /knowledge_bases/:name/entries/:entry (PATCH to write, GET for the Markdown) and sites at /knowledge_bases/:name/sites.

Redirects are followed. A site that answers 301 or 302 — an apex sending you to www, a / sending you to /home — used to index nothing at all and report that it had completed. So did a sitemap behind a redirect. And a page that produces no text now says why, instead of disappearing from a run that claims success.

Accents survive. A page whose charset lives only in its HTTP header was parsed as Latin-1, so “Narváez” was indexed as “NarvÃ¡ez” and nobody searching for the name would find it.

0.39.0 — 2026-09-23

One API, one view, and environment said out loud.

The docs used to describe two chat APIs under one heading, as though you got to pick. You never did: one is you holding a vat_ token, the other is a stranger’s browser. The browser one is now documented as what it is — methods of the SDK, its only client — and the API section is what your developer token opens, each group naming the vatio command that does the same thing.

view is gone from the chat endpoints. It took visitor or developer and quietly turned anything else into visitor, so view=debug — the guess almost everyone made — returned a smaller payload with no error and looked complete. Holding the developer token is the developer view, so both reads now answer in full: deleted messages, tool calls with their results, attachments, delivery receipts, and the identity block. Print what you need. vatio chat transcript is unchanged for you; it filters the visitor’s half of the thread itself now instead of asking the server for less.

environment is required on POST /chats and POST /chats/:id/reset. It was the one field in the API that defaulted to live — leave it out of a hand-written request and you were holding a real conversation with your published agent: billed, in your inbox, tools running against live secrets. A missing or unparseable environment is now 422 and creates nothing. The CLI always sent preview, so nothing changes if you talk to Vatio through it.

0.38.0 — 2026-09-22

The SDK is on npm, and the widget is the only thing you paste into a page. Two changes with one shape: everything Vatio ships is now either a package you install or a page you visit, and the list of scripts that go into somebody else’s HTML is one item long.

npm install @vatio-ai/sdk

import { Vatio } from "@vatio-ai/sdk";

cdn.vatio.ai/v1/sdk.js is gone, and so is the /sdk/1.js redirect to it. Nothing fetches the SDK at runtime any more: widget.js bundles it, which is a little larger and one whole failure mode smaller. That mode was worth losing — a dynamic import() is a module fetch, so it was a CORS request from every page that wasn’t vatio.ai, and when it failed all the browser said was “Failed to fetch dynamically imported module”, which reads like a 404 and never was one. It cost a production afternoon once.

No bundler is still fine — https://cdn.jsdelivr.net/npm/@vatio-ai/sdk/+esm serves the same module. Pin the major the ordinary way, "^2.0.0": a semver range in your package.json is what the /v1/ in the old URL was reaching for, and says it better.

The inbox is a page in Vatio, and there is no credential anywhere near it. It used to be a second embeddable script (inbox.js) you mounted in your own product and authenticated by signing a JWT against an inbox: block in vatio.yml. All of it is gone: the script, the block, and the API behind them. vatio push refuses inbox: now, so delete it and the key file it names.

Invite supervisors from Team in the console. They sign in with a code to their email and land on /workspaces/<id>/inbox — every conversation, replies, human takeover, ratings, the runtime trace. Remove them from the same page and the next request they make is refused, including a socket they already had open.

That is the whole access model, and it is deliberately the smallest one available: being signed in to Vatio, as someone this workspace invited. No token to mint, nothing to sign, nothing that expires on its own schedule, and no second place that can grant access to a conversation.

The old design asked every developer to build and run a small authentication system — generate a keypair, guard the private half, pick an algorithm, pick an expiry, remember to rotate — to answer a question Vatio can already answer, and the answer granted read-and-reply on every conversation in the workspace. The version that replaced it had Vatio issue the credential instead, which was better, and it was still a credential, an exchange endpoint, a token table and a CLI command in service of a supervisor UI nobody outside Vatio had built. Withdrawing the option is what actually removed the cost.

Building a supervisor UI inside your own product is not supported for now. If that is something you want, say so — reopening it means adding a credential back to a client that already works, not rebuilding the feature.

https://vatio.ai/vatio-inbox.js no longer redirects anywhere, because there is no longer anything to redirect to. vatio-widget.js still does, and will.

0.37.2 — 2026-09-22

The package is @vatio-ai/cli. The command is still vatio — a package’s name and the binary it installs are separate things:

npx @vatio-ai/cli init my-agent           # nothing installed
npm install -g @vatio-ai/cli && vatio push

Two reasons for the scope. The first is forced: npm will not publish a package called vatio, because it reads as a typo of valtio, an unrelated state library, and the registry refuses names close enough to an existing one to be mistaken for it. That rule is worth respecting rather than routing around.

The second is the one that decided it. The CLI will not be the only thing Vatio publishes — a frontend built on the SDK wants npm i @vatio-ai/sdk, not a script tag — and a scope claimed now is one name that stays coherent instead of two that have to be reconciled later.

Nothing else changed: same commands, same flags, same ~/.vatio/config.json.

0.37.1 — 2026-09-22

vatio whatsapp connect opens the browser too. It printed the link and stopped, while vatio instagram connect printed it and opened it — two sibling commands behaving differently for no reason a developer could see.

The link is still printed first and still printed in full, so nothing is lost where there is no browser to open: over SSH, in a container, on a headless machine, the call quietly does nothing and the URL is there to paste.

0.37.0 — 2026-09-21

vatio whatsapp connect prints a link, and pasted credentials are gone. The command took --phone-number-id, --waba-id and --token. It takes no flags now: it prints a URL and stops, the same shape as vatio instagram connect and vatio login.

This is not a CLI preference, it is what connecting a number actually is. Meta’s Embedded Signup is a consent screen a person has to read, and the three ids the flags wanted only exist after it has run — so for the case that matters most, a number sitting in the WhatsApp Business app on someone’s phone, the flags could never have worked at all. That number can now be connected and stay in the phone app, which only this flow can do.

The form in the app is gone with it, along with “Enter details manually instead”. An expired access token is renewed by running the same connect flow again: Meta hands back a fresh token for the same number and it replaces the old one in place. Connecting a different number still has to be a disconnect first.

If you were scripting vatio whatsapp connect with flags, it now exits telling you the option is unknown. Everything else about the command group — status, check, activate, deactivate, disconnect, and all of numbers — is unchanged.

0.36.0 — 2026-09-21

The CLI is an npm package now. There is nothing to install:

npx @vatio-ai/cli init my-agent
npx @vatio-ai/cli push

If you have Node 20 or newer you have the CLI. The Ruby one that curl … /install.sh | bash put in ~/.vatio-cli/ is gone, and so is /install.sh itself.

Why: Node is the runtime this audience already has, and Ruby is the one some of them do not. A CLI that asks you to find a runtime before it can help you is a CLI that loses the people it was written for.

What carries over: your login. It is the same ~/.vatio/config.json, with the same keys — run npx @vatio-ai/cli push and you are already authenticated. Every command keeps its name, its flags and its output.

To migrate: delete ~/.vatio-cli/ and the vatio symlink in ~/.local/bin/, then use npx @vatio-ai/cli (or npm install -g @vatio-ai/cli). Nothing else to do.

vatio update is gone with it: npx @vatio-ai/cli runs the current release every time, so there is no version of the CLI that can fall behind the platform. A global install updates with npm install -g @vatio-ai/cli@latest.

vatio pull is removed. It overwrote your local files from a deployed manifest, and the reason to stop is that it could never tell you anything your repository did not already contain.

A deployed manifest is only ever produced by a push. Nothing else writes one — no screen in the Vatio app edits your agent, your tools or your widget, because vatio.yml owns all of it. So what pull handed back was your own repository, one round trip later, and less: the logo it admitted it could not restore, because a revision keeps that file’s name and digest and never its bytes.

If you want to see what is actually deployed:

vatio diff --env live    # what your directory would change there
vatio diff --full        # both manifests in full

And the manifest itself is one request: GET /api/v1/:slug/deploy/manifest.

The CLI test suite is removed too, along with the Ruby 2.6 CI job that ran it. It tested a CLI that is being replaced, and the drift guard it carried — the one that reconciled the command dispatch against vatio help and against these docs — is gone with it. Adding or renaming a command now needs those three read against each other by hand.

0.35.0 — 2026-09-21

A chat is you, and vatio chat can talk to live. vatio chat --channel whatsapp --from +56912345678 let you arrive at your own agent as a simulated WhatsApp visitor. It is gone, on both sides — the CLI no longer sends it and the platform no longer accepts it.

It was a fake version of something that exists for real. The shared WhatsApp preview number and Instagram test accounts put a genuine message through a genuine channel, with the real verified phone number attached; the simulation only ever produced something channel-shaped, and it had to be kept in step with the real path forever. It drifted instead: the same module decided which contact a chat attached to, in two places at once.

What replaces it: nothing, for identity. A chat belongs to the token you are holding, on the cli channel. What you gain instead is the deployment:

vatio chat "Hi"              # preview, as before
vatio chat "Hi" --env live   # the published agent
vatio chat reset             # a visitor this workspace has never met

A chat against live is a real conversation. It lands in your inbox next to the ones visitors started, and nothing downstream knows it came from a terminal. The CLI says so when it opens one; it does not ask twice.

Breaking

vatio chat --channel and --from are removed, and so are vatio config set channel / from. A config file carrying them is cleaned up on next use.
--sandbox-url is now --api-url, and VATIO_SANDBOX_URL is gone. Nothing else is called sandbox any more: the word was already preview everywhere else.
.vatio-sandbox.json is now .vatio-chat.json, and holds one open chat per deployment instead of one overall — switching to --env live and back no longer loses your place. The old file is deleted, not migrated: half of what it stored was the simulated identity.
POST /api/v1/:slug/chats and /reset take environment and nothing else. channel, from, session_id, reply_style, email, phone_number and as are all refused with removed_field and a message saying to run vatio update. A CLI older than this one sends channel and session_id on every chat, so vatio chat stops working until you update — deliberately, rather than accepting fields it would ignore and letting the next request, the one that actually meant something, be the one that breaks.
Nothing is called sandbox any more. Instagram’s shared test surface now reads the way WhatsApp’s always did: the shared Instagram preview, not “the sandbox”. Same change in the CLI help, the docs, the console labels and the API error messages. The JS sandbox that tools run in keeps its name, because that is what it is.

Also fixed

The one-time nudge after a workspace’s first push — the one pointing at the free WhatsApp preview number — never printed. The server renamed the field to whatsapp_preview_hint when sandbox became preview and the CLI kept reading whatsapp_sandbox_hint.

0.34.0 — 2026-09-21

One flag picks the deployment: --env. Saying which deployment a command was about used to depend on the command. push and publish took --as NAME, pull took --preview, tokens and widget took --environment or -e, and diff took nothing at all — it compared against preview and there was no way to ask it anything else.

Now every command that touches a deployment takes --env NAME, where NAME is live, preview, or a named preview like pr-42:

vatio diff --env live           # what would publishing change?
vatio pull --env pr-42          # bring that preview's manifest down
vatio tokens create --env pr-42 # a publishable token for it

Two things this unlocks that were not possible before:

vatio diff --env live. The question “what does publishing actually change” had no CLI answer; you had to push, then read the console.
Named previews outside push. tokens and widget rejected anything but live or preview, so a workspace could deploy to pr-42 and then have no way to mint the publishable token that makes it embeddable. The CLI refused a name the platform had just accepted.

Nothing is removed. --as, --preview, --environment and -e all still work, and every default is the one it was: push writes a preview, pull brings down live.

0.33.0 — 2026-09-21

The CLI stopped parsing your workspace; Vatio does it. vatio tools check, vatio diff and vatio push used to read vatio.yml, your tools/, auth/ and lib/ files and build the manifest on your machine, against rules compiled into whichever CLI version you happened to have installed. They now send the directory to the platform, which builds the manifest, validates it and answers with the errors, the warnings and the diff.

What this fixes: the rules are the platform’s, so a workspace that checks clean is a workspace that deploys, and a contract change reaches you without an upgrade. vatio diff and the console no longer disagree about links: — they were two implementations of the same comparison, and one of them had drifted.

What it costs, and you should know before upgrading:

vatio tools check and vatio diff need the network and a login. They were local commands; they are not any more. Run vatio login first, and expect a round trip where there used to be none.
They also need the workspace to exist on Vatio. vatio push still creates it for you; a check before your first push will say the remote is missing.

Nothing about vatio.yml, tools/, auth/ or lib/ changed. The same directory that deployed on 0.32.0 deploys on 0.33.0.

Your workspace is sent as files, so the usual exclusions apply: anything hidden (.env, .git/) and node_modules/, tmp/ and log/ are never uploaded. A workspace is capped at 500 files, 2 MB per file and 8 MB in total.

September 14–20, 2026: Vatio 0.27.0, 0.28.0, 0.29.0, 0.30.0, 0.31.0 and 0.32.0

Mon, 21 Sep 2026 12:00:00 GMT

0.32.0 — 2026-09-20

vatio.yml owns the whole widget, and the snippet drops to two attributes. The widget: block set the accent, the logo, the locale and the about text; everything else about how the widget looked — its corner, its colour scheme, its radius, its font, its greeting, the suggestions on the empty state — could only be said as a data-* attribute on every page that embedded it. A workspace with the same widget on five pages repeated the same ten attributes five times, and changing one meant a website deploy.

All of it is widget: now:

widget:
  accent_color: "#2563eb"
  position: right
  scheme: light
  font: inherit
  radius: 20px
  greeting: What can I help you with?
  suggestions:
    - Where is my order?
    - How do returns work?

The precedence is the host page’s data-*, then vatio.yml, then the platform default — field by field, so a page that has to differ still can, and the snippet only carries what is specific to it:

<script async src="https://cdn.vatio.ai/v1/widget.js"
        data-workspace="acme" data-token="vatpub_..."></script>

data-display and data-mount have no widget: key on purpose: they say where the widget goes in one page’s DOM, which is the part a page really does own.

A key widget: does not recognise fails the push. possition: right validated, pushed, exited 0 and did nothing — the only signal was a bubble that had not moved. It is an error now, and the message names what the block accepts.

0.31.0 — 2026-09-20

A source name belongs to one kind of source, permanently. An upload whose filename matched an existing crawl used to win, without saying so: the crawl’s site_url and globs were overwritten, the pages it had already indexed stayed underneath answering lookups for a source that no longer said where they came from, and the command exited 0. Declaring a crawl over an existing upload did the same in reverse, which is worse — a crawl can be rebuilt from the site, an upload is the only copy of what it holds.

Both directions are refused now, and the error names what is already there:

$ vatio kb upload default kb/ayuda.md
Error: default already has a source named "ayuda", and it is a crawl of
https://home.saludtech.cl include=/ayuda/pacientes/**. An upload cannot
take over a crawl -- rename the file, or drop the crawl first with
`vatio kb rm-source default ayuda`.

Refusing beats merging or renaming for you: upload ayuda.md onto a crawl named ayuda reads as both “replace my crawl” and “I did not realise the names collide”, and only you know which one you meant.

A batch upload is all-or-nothing. vatio kb upload BASE kb/*.md now checks every file against the base before it sends the first one, so a collision on file twenty no longer leaves nineteen uploaded and the rest refused.

0.30.0 — 2026-09-17

vatio issue --template is prompts now, not a form. A written-up issue used to have to carry four headings — Motivation, Proposal, Open questions, Prior art — and a document that skipped one came back rejected. That asked for an RFC. It mostly produced either an RFC-shaped wrapper around one real sentence, or nothing at all, because the person with something to tell us did not feel like filing a proposal.

There are no required sections any more. --template prints prompts you are free to keep, delete or answer out of order, and the platform asks only for a one-line title of your own and a body that says something — so a document that came back untouched is still refused, and a rough one is not:

vatio issue --template > issue.md   # prompts, not a form
vatio issue --file issue.md

“I don’t know what the right fix is” is a fine thing to send.

The mail around an issue says less, and the thread says it instead. The acknowledgement used to promise that a person reads every one and invite a reply — which made the inbox look like the channel when it is not. It is now a short confirmation that the issue was submitted, plus where to read it. Two mails go out per issue, submitted and answered; the notes while it is worked on and the pull request are posted to the thread and never mailed, and a reply to either mail does not reach the thread. vatio issue show prints the whole of it.

0.29.0 — 2026-09-17

An issue is now a conversation, and it lives in the CLI. vatio issue was one-way: you sent something, we replied by email, and the reply landed in a mail client — the wrong place for it, because the thing that has to act on the answer is the coding agent in the repo the issue came from.

vatio issue list                     your issues, and who owes a reply
vatio issue show 4                   the whole thread, as markdown
vatio issue show 4 --save            write it beside your code, for your agent
vatio issue comment 4 "still broken" add to the thread

show prints the same document our own triage reads — the problem, the diagnostics the CLI attached, and every message either side has written — so your agent can pick up the answer and implement it without anyone retyping a summary. comment adds to it; a person reads it and answers into the same document. Replying to an issue we already handled reopens it.

Comment rather than opening a second issue: a follow-up that arrives as a new report throws away everything the first one established. You see your own issues and nothing else, and email still carries every message — it is a mirror of the thread now, not the only copy.

links: now survives a push. A block the platform could not store used to be dropped in silence — a successful push, a vatio diff reporting it as added forever, and an agent behaving as if you had never written it. links:, identity: and inbox: were all affected. They now deploy, and a root block the platform does not understand fails the push instead of vanishing.

0.28.0 — 2026-09-16

An unknown key in vatio.yml is now an error. Before this, a key the CLI did not recognize was dropped on the way to the platform: a typo deployed a workspace missing whatever you meant to configure, and a block from a newer version of the manifest deployed as if you had never written it. Both were silent. Now the push stops and names the key, and says to run vatio update if the key is one you expect to exist — which is the case this is really for:

vatio.yml: unknown key `links:`
If this is a newer manifest feature, your CLI is behind — run `vatio update`.

vatio update says what it is about to install. It prints the changelog entries between the version you have and the one being installed, so an update is a decision rather than a version number going up.

0.27.0 — 2026-09-16

links: — the URLs your agent is allowed to share. A URL written into instructions: never reached a visitor: the no-unauthorized-links safeguard allows only URLs the agent was actually given, and instructions: is text the model may rephrase, so the draft was discarded and the link stripped. links: is where a URL is given:

links:
  login: https://saludtech.cl/login
  agendar:
    url: https://saludtech.cl/{especialidad}
    when: The visitor wants to book an appointment
    values:
      especialidad: [nutricion, kinesiologia, psicologia]

A {placeholder} always lists the values it can take, and a deploy expands the link into one concrete URL per value. Those are what the agent is shown and what the safeguard allows: it copies one, it never assembles one. Leaving values: out is an error — an open template would have the agent fill in the slug itself, and nothing downstream could tell a real one from a plausible one.

See Links for the full field reference.