Your team asks. Your app answers.
Support, ops, and finance ask your Avo app about your data in their own words, change records, and run the actions you already wrote. It runs inside your Rails app under the policies you already have, and nothing changes until someone clicks Confirm.
In beta. Bring your own OpenAI, Anthropic, or Gemini key.
ai, built in
Ask it, connect to it, or build with it.
Avo comes with AI built in, in five places. Your team asks in plain words, your AI client and your coding agents connect under the rules you already wrote, and the agent that writes your code already knows Avo.
AI chat
for your team
Ask about your data in plain words, change records, and run the actions you already wrote. Nothing changes until someone clicks Confirm.
MCP server
for the AI client you already use
Connect Claude, Cursor, or ChatGPT to your app. From your laptop, your coding agent reads the production record behind a bug report, with no database dump, and it starts read-only.
CLI
for your terminal
Read and change records with one command each, for you, your scripts, and your coding agent, on a token that reaches only what you granted.
REST API
for what you build next
Every model you add gets a documented JSON API, so your integrations and your own agents work under the same policies as your team.
Agent skills
for writing the code
Your coding agent writes the Avo you have installed: more than 30 skills ship inside the gem, pinned to your version.
what they can ask
Plain questions, answered from your real data.
Press Cmd+J on any page of your Avo app and ask the way you would ask a colleague.
It reads your resources, columns, and scopes at the moment you ask, so your team's words work:
"the published posts" runs your own published scope instead of a guessed filter.
Find and count
“Who signed up last?”
One record, named inline as a chip you can click.
“How many posts per status?”
A count per value, taken from the real total, never from the rows on screen.
“Which teams have no members?”
Checked against the association, scoped to the records you're allowed to see.
Change and run
“Set the Orbit project's status to active”
A card with each field's before and after value, and a Confirm button.
“Archive the Orbit project, reason: budget cut”
Your own archive action, its fields on the card, prefilled and editable before you click Run.
“Undo that”
A card describing the undo, for you to confirm.
Work with files
“Which of the emails in this CSV are signed-up users?”
The file read a window at a time and matched against your records, matches and misses reported.
“Create users from this CSV”
One card with the column mapping and a preview of the first rows. Nothing is created until you confirm.
“Any orphaned uploads?”
Files attached to nothing: the count, the bytes, and the oldest one.
About the page you're on
“Who owns it?”
Asked from a record's page, "it" is that record for the whole conversation.
“How many of these are unpaid?”
Check rows on an index and "these" means exactly those records, with no second search.
Write the prompt your team repeats every week once, as a skill, and anyone drops it into a chat
with /. The full list, with a sample prompt for everything, is in
What you can ask.
why it's safe on real data
It sees what they see, and it waits for a yes.
The assistant can't see your database. It learns about your data only by calling tools that run inside your app, as the person who is chatting, through the Avo policies you already wrote.
Permissions hold on every call
Every read and write goes through your policies for the signed-in user, per resource and per field. A resource they can't list is invisible to it, and a record outside their reach reports as not found, never as not allowed, so the chat can't be used to probe for what exists.
Changes arrive as a card
Updates, deletes, action runs, CSV imports, and downloads from a link wait on a card until someone clicks Confirm or types "do it". It works one record at a time and asks you to pick when a name matches three. New records are created straight away, since there is nothing to preview yet.
Every write can be traced, and undone
"Undo that" restores the values an update overwrote, re-creates a deleted record, or removes a created one. An action that emailed a customer is marked not undoable rather than pretending. With audit logging, the record's timeline reads "Ada Lovelace through AI chat", linked to the conversation.
Text in your data stays text
A sentence in a file or a record addressed to the assistant can be reported, never acted on. The acting user is set in Ruby, not passed by the model, so there is no argument it could invent to act as someone else.
You pick its tools
Take delete_record away in one line of config and the model never learns it existed.
Add tools of your own for the workflows your team runs every day, reaching data through the same
authorization helpers the shipped tools use.
It can propose a write. It can't perform one.
Your confirmation applies the change, not the model, and it can't talk its way past a Cancel.
your agents, too
Connect Claude, Cursor, or ChatGPT under the same rules.
The MCP Server add-on turns your Avo app into a remote MCP server. An admin pastes its URL into Claude Code, Codex, Cursor, Amp, VS Code, or ChatGPT, approves a consent screen served by your own app, and from then on the client acts as that admin, through the resources, policies, and field visibility you already have.
claude mcp add --transport http acme-admin https://app.example.com/avo/mcpReal records, from your laptop
Connect the coding agent on your machine to production and it reads the order behind a bug report, instead of guessing from your seeds. There is no database dump to pull and no database credentials to hand out, and the connection starts read-only.
They choose what it may do
The consent screen offers Read, Read & write, or a choice per resource, with running actions as a separate switch. Write and actions start unticked, because over MCP the consent is the confirmation: an agent granted delete deletes without asking again.
It can never outrank its admin
The admin is looked up again on every call. Demote them to read-only and their connected client
stops writing on its next request, with nothing to revoke. A field your visible: block hides from
them is hidden from their client too.
You can see every connection
Each connection gets a three-word name from the avocado's own vocabulary,
creamy-golden-hass for one, and the session announces it, so you know which row is which. Its page
logs every request it made, and Revoke takes effect on the next call.
A tool you wrote for the chat can be served over MCP as well, gated by the capability you declare. Setup and the client recipes are in the MCP Server docs. Weighing it against a server you write yourself? Add an MCP server to your Rails app compares the two.
and the terminal
Script your records from any shell.
avo-cli is a free gem that talks to your app's API. Log
in once and every command has the same shape, so a cron job, a CI step, or the coding agent in your terminal can
read and write records without an HTTP client of its own. Log in to production and that agent looks up the exact
record behind a bug report from your laptop, with no database dump and no console session.
avo login # once: host, token, API version
avo schema # what this token may reach
avo list users --sort name --dir desc
avo get users 5 --format json # the body, and only the body, on stdoutA token reaches only what it was granted
Every command runs on an API token you create in your app and can revoke from its API tokens
screen. avo schema lists exactly the resources and verbs that token may use.
Failures a script can act on
Exit code 2 means the CLI refused before sending anything, so nothing changed. Exit code 1 means
the request went out and the app refused it or never answered, and the message names what to change. One caution: avo delete asks
nothing first, because the line already names the record.
turn it on
A gem, a migration, and your key.
Avo AI needs Avo 4, PostgreSQL, and an API key for any provider RubyLLM supports. It is in beta, and the installation guide tracks it.
Add the gem
gem "avo-ai", source: "https://packager.dev/avo-hq/"Run the installer and load the models
bin/rails generate avo:ai install
bin/rails db:migrate
bin/rails ruby_llm:load_modelsSet your provider key in config/initializers/ruby_llm.rb from the environment or
your credentials, restart, and the chat bar appears on every Avo page.
Teach it your app
It knows Avo out of the box, not what a "booking" or a "client" means in your business. With the Avo skills installed, tell your coding agent the line below: it interviews you in short rounds and writes that down in one prompt file you review and commit.
Onboard the Avo AI assistant onto this app.Frequently asked questions
- Can the AI assistant see data a user isn't allowed to see?
- No. Every read and write the assistant makes goes through your Avo authorization policies for the signed-in user, per resource and per field. A resource they can't list is invisible to it, and a record outside their reach reports as not found rather than not allowed. See How the assistant works.
- Does the assistant change records without asking?
- Updates, deletes, action runs, CSV imports and downloads from a URL all arrive as a card and apply only when someone clicks Confirm or tells it to go ahead. Creating a single record applies straight away, since there is nothing to preview. Every executed write is recorded and can be undone from the chat.
- Which LLM providers does Avo AI work with?
- Any provider RubyLLM supports, including OpenAI, Anthropic and Gemini. You bring your own API key, and a policy method can offer your team a shortlist of models to pick from.
- Can I connect Claude, Cursor or ChatGPT to my Avo app?
- Yes, with the MCP Server add-on. An admin adds your app's MCP URL to their client and approves a consent screen served by your app. The client then acts as that admin, under the same policies and field visibility, with only the capabilities they granted. See the MCP Server docs.
- Where does the assistant run?
- Inside your Rails app. Its tools run in your application against your models and policies, and the conversations are stored in your own database. What a tool returns is sent to the model provider you configured, so a custom tool should return only what the question needs.
Your team has questions. Your app can answer them.
Add Avo to your Rails app, let your agents write the resources, and hand support, ops, and finance a place to get answers without asking you. Every change still waits for someone to click Confirm.