The thing that happened
I needed to set up a Postgres database, a Redis cache, a Docker container, and some environment variables on Railway. Their product has an AI assistant. I typed what I wanted and it configured everything. The database spun up, the environment variables populated, the container connected to both services. Maybe two minutes of typing.
Then I went to Google Analytics to add a team member. I spent ten minutes navigating through Admin, then Property Access Management, then figuring out which role mapping applied, then backing out because I was in the wrong property. Standard GA4 experience.
The contrast was jarring. Not because Railway's AI was doing anything exotic, but because it made me realize how much of my time in SaaS products is spent navigating, not doing.
Railway's assistant is running Claude Sonnet 3.5. Not even the latest model. Some prompts, some API integrations. And it made their entire navigation layer optional. That's the part worth thinking about.
What actually changed
Railway didn't add a new feature. They changed the interaction model. The product is the same product with the same capabilities. But instead of navigating to Settings, then Databases, then New, then PostgreSQL, then Configure, you type “add a postgres database.”
The AI didn't make the product smarter. It made the product usable.
The traditional SaaS interaction model is: learn the product's structure, then navigate to the right place, then perform your action. The conversational model is: state your intent. The product figures out the rest.
Think about what that means for the economics of product design. Companies spend enormous effort on information architecture, navigation patterns, onboarding flows, tooltip tours, help documentation. All of that effort exists because the user needs to find things. If the user can just ask, the entire findability problem evaporates.
Where it broke
After setting up Postgres and Redis, the Docker container couldn't connect to the database. A standard connection issue. Could be a dozen things: network configuration, port binding, connection string format, service discovery, DNS resolution within Railway's internal network.
I asked the assistant to help troubleshoot. Its solution was straightforward and confident: delete the Postgres service and recreate it.
That's not troubleshooting. That's the equivalent of a tech support rep telling you to reinstall Windows. When I pushed back, the assistant suggested disabling the database entirely.
This is the gap between a chatbot and an agent. A chatbot has a model and some API access. It can translate natural language into API calls. But when things break, you need something different. You need methodology. You need a system that knows: when Postgres can't connect, you check the network first, then the port binding, then the connection string, then DNS resolution. You don't delete the database.
Every SaaS product has this problem
Railway's UI confusion is not unique. Every complex SaaS product has the same fundamental issue. The product is capable, but the UX is a maze.
Salesforce, Jira, AWS Console, Google Analytics, HubSpot, QuickBooks, Workday, ServiceNow, Zendesk, Datadog, Segment. The list goes on. These are products that took decades to build, that serve millions of users, and that most users navigate using the 20% of features they've memorized. The other 80% might as well not exist.
A conversational layer also unlocks features that product teams built but nobody uses. Every mature SaaS product has a graveyard of well-designed features that failed because users never found them. The feature adoption problem is a discoverability problem, and natural language solves discoverability.
The build-it-yourself reality
The best-funded, most technically sophisticated companies will build their own. Railway has great engineers. They picked a model, wrote some prompts, connected their APIs. V1 shipped fast and the happy path is genuinely impressive. But look at what the V1 is missing.
Model selection. They're on Sonnet 3.5. Staying on it when better options exist is leaving quality on the table. But switching models means re-testing every prompt, every API integration, every edge case.
Guardrails. The assistant suggested deleting a production database as a troubleshooting step. There is no system preventing that suggestion.
Learning loop. When I got the bad suggestion, that knowledge went nowhere. The next user who hits the same Postgres connection issue will get the same bad advice.
Observability. Railway's VP of Product cannot see how often the assistant suggests destructive actions.
Methodology. The assistant has prompts and API access. It does not have structured knowledge about how to troubleshoot Railway infrastructure.
The math
There are roughly 30,000 B2B SaaS companies. Of those, maybe 200 have the engineering capacity to build and maintain what Railway built. That leaves 29,800 companies whose users are about to expect a conversational layer.
Those 29,800 companies have three options:
- Build it. Hire an AI team. Pick a model. Write prompts. Build integrations. Maintain it forever.
- Ship a chatbot. Wrap an LLM API, add some system prompts, call it an “AI assistant.” Fails catastrophically on anything complex.
- Use infrastructure. Adopt a purpose-built runtime that handles model management, guardrails, learning, observability, and methodology.
Option 1 is expensive and distracting. Option 2 is worse than nothing. Option 3 is the only one that scales. The same way most companies do not build their own database, their own authentication system, or their own payment processing.
What doing it right actually requires
Model selection and testing
Not just “pick Sonnet.” The ability to run the same prompts against multiple models, measure response quality, compare latency and cost, and switch models without rewriting integrations.
Methodology, not just prompts
Prompts tell the model what to say. Methodology tells the model how to think. When a user reports a Postgres connection error, a prompt might say “help the user fix the connection.” A methodology says: check the network configuration first, then verify the port binding, then validate the connection string format, then check DNS resolution. Never suggest deleting a resource as a troubleshooting step.
# Connection Troubleshooting Methodology ## When: User reports a service cannot connect to a database ## Steps (in order): 1. Check network configuration 2. Verify port binding 3. Validate connection string 4. Check DNS resolution ## Never: - Suggest deleting a resource as a troubleshooting step - Skip diagnostic steps to jump to "recreate it" - Assume the database is the problem without checking the client
Guardrails
The agent cannot suggest deleting production resources as a troubleshooting step. The agent cannot execute write operations without explicit confirmation. These constraints are not limitations. They are what makes the system trustworthy.
The learning loop
When a user hits a bad suggestion, that feedback needs to flow back into the system. Not through model fine-tuning. Through knowledge base updates. Session 51 is materially better than session 1.
Observability
Product teams need to see every suggestion the agent makes. Filter by failure mode. Identify patterns. Without observability, the AI layer is a black box.
Permission boundaries
The agent can read everything. But writes require confirmation. Destructive operations require explicit approval with a clear description of what will happen.
The window
The companies that ship a conversational layer in the next 12 to 18 months will define the UX standard for their vertical. The ones that wait will play catch-up against competitors whose products simply feel easier to use.
And like mobile, the gap between “we have it” and “it's good” is enormous. A bad conversational layer is worse than none at all. It teaches users that the AI button is unreliable, and they stop clicking it.
What we're building
This is what Amodal is for. We build the infrastructure layer that makes reliable conversational AI possible for the other 29,800 companies. Skills that encode domain methodology. Guardrails that prevent destructive suggestions. A learning loop that gets smarter with every session. Observability that gives product teams visibility into every interaction.
Railway showed that the conversational layer works. The question for every other SaaS company is not whether to add one, but how to build it right.