AI-painted vs AI-native: most companies bolted a chatbot onto the website and called it done
There's a test for whether your company is actually AI-native or just AI-painted. Most fail it. Here's the test — and what passing looks like.
Somewhere right now, a leadership team is congratulating itself on its AI strategy because the website got a chatbot.
That's not AI-native. That's AI-painted — a thin coat over the same company, applied where visitors can see it.
I build rysh, a platform whose whole reason to exist is closing this gap, so yes, I have a horse in this race. But the distinction I'm about to draw is useful whether or not you ever touch our product. It's the difference between companies where AI compounds and companies where it decorates.
The paint test
Ask these five questions about the AI in your company:
- Does it do real work, or answer questions about work? A bot that explains your refund policy is paint. An agent that processes the refund, logs it, and drafts the customer reply is native.
- Can anyone see what it did? If the answer lives in a vendor's dashboard you check quarterly, that's paint. If every action is observable by the team, as it happens, that's native.
- Who approves the dangerous parts? If the honest answer is "nobody, we just hope," you don't have governance — you have liability with a friendly avatar.
- Where does the logic live? If your "AI workflows" are configuration inside someone else's SaaS, you don't own them. You're renting behavior. Native means the logic is in your repo, in files you can diff, review, and revert.
- How many times did you build the same assistant? If the website bot, the Slack bot, and the internal helper are three separate implementations on three vendors — that's the clearest paint signature there is.
Most companies fail at least four of five. Not because their engineers are bad, but because the tooling they were sold is designed to fail these questions. Point-SaaS AI wants to be a silo. Silos renew contracts.
What AI-native actually looks like
AI-native means agents do real work across the whole company:
- writing, reviewing, and shipping code
- running ops and incident response
- handling customer conversations on every channel
- automating browser and back-office tasks
- calling your internal APIs — safely
…while your people can observe every action, approve the dangerous ones, and own the logic and the data. No black boxes. No re-implementing the same agent five times for five channels.
Notice what's not in that definition: a bigger model, a moonshot budget, a Chief AI Officer. AI-native is an architecture decision, not a headcount decision.
The architecture that makes it real
Here's how this cashes out concretely in rysh — because "be AI-native" without mechanics is just another slide.
An agent is a markdown file. Persona, tools, and channel wiring in one versionable artifact:
##agent spawn code-reviewer.md
@code-reviewer review the diff in pane 3
That file lives in git. Your agent workforce gets code review, history, and rollback — the same discipline as the rest of your engineering.
One engine, every surface. The same definition that answers a developer in a terminal pane can be wired — as a humanoid — to email, website chat, and Slack (WhatsApp and phone are roadmap). Your customer-facing bot and your internal agent stop being strangers; they're the same engine with different contact cards.
Observability is the default, not the add-on. Every tool call renders in a pane. File edits show a diff before touching disk. Mutating shell commands wait for explicit approval. For customer channels, draft-and-confirm mode means a human okays every outbound reply until you decide the agent has earned autonomy (live for email and website chat today).
Ownership is literal. rysh is self-hostable, running on your machines with your own Anthropic key — rysh runs on Claude, and your data path stays yours.
That's questions one through five, answered by architecture instead of policy documents.
"We'll get there eventually"
The most common objection isn't disagreement — it's sequencing. We'll do the chatbot now, the real thing later.
The problem: paint creates debt. Every silo you deploy today is a migration you'll fund tomorrow. Every workflow encoded in a vendor's config UI is logic you'll re-write when the contract sours. Meanwhile, the compounding that matters — agents that share context, definitions that improve in git, a team that actually trusts automation because it can see it — never starts.
The companies that get this right won't be the ones with the biggest AI budgets. They'll be the ones that picked an architecture where every agent added makes the next one cheaper.
Start smaller than you think
The honest pitch is not "transform your company this quarter." It's:
brew install rysh-ai/rysh/rysh
rysh
One binary. Spawn one agent from one markdown file. Let one team watch it work — every tool call visible, every risky action gated. Then wire that same agent to one external channel and see the paint/native difference for yourself: not a new bot, the same agent, on a new surface.
We're early-stage and building this in the open, which means the roadmap is genuinely up for grabs.
We're recruiting design partners — teams that want to be AI-native in practice, not in the deck. Hands-on access, direct line to the founder, your feedback steering what ships: rysh.ai/design-partner
Related: Meet rysh.ai · What it actually means to be an AI-native company