Build and run your agent from a chat

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.