Most SaaS products these days are building some sort of AI agent embedded into their own product.
In theory this is a great idea because a) you retain full control over the harness and have complete observability into how people are using it; and b) you cater to folks who would find it too much friction to connect using an MCP or CLI.
At Railcode, we don't offer an in-product agent at all, and don't intend to. We believe the best harness is your own harness, and we'd rather not compete with it.
A lot of companies are nice enough to give you a choice: you can use their in-product agent or their MCP, whatever's best for you.
We don't give you a choice. BYOH. Bring Your Own Harness.
My view is that offering a choice would lead to a worse product, so I thought I'd share a bit about why.
In-product AI is convenient at best
An AI agent embedded into your product is really convenient.
It's convenient for your users, because it requires no setup and everybody knows how to use a chat.
But above all, it's convenient for you.
You have full control and can tailor the agent to work well with your product. You have logs and can use them to improve the agent and understand user needs better.
When someone connects over MCP, there's a lot that can go wrong that won't be your fault, will affect the user's experience with your product, and you won't get a chance to fix because you won't hear about it!
It's easier to ensure a good experience when you own the environment. But insisting on owning the environment prevents you from offering a great experience for users.
Your agent will always be better than mine
Last week I gave a talk titled "Why your agent is better than mine" (that in turn led to this article), where, rather than convince the audience that we have the best agent of them all, I was actually trying to convince them that we could never offer them an agent inside Railcode that's better than something they already have.
Unlike your harness of choice (e.g. Claude Code or Codex), most in-product AI agents will not:
- Run on frontier models
- Be able to schedule tasks
- Allow you to connect to MCPs
- Have features like subagents
And even if they do, they will not have your skills, your memories, or access to your local environment. They will also feel different than the tool you're accustomed to using every day.
On the other hand, connecting to a product over MCP or with a CLI gives you complete flexibility, connectivity to other services, and fits right into your existing workflows. It's a lot more powerful and feels better too.
Why not both?
Even if you accept that BYOH offers the best possible experience to users, you might still think that there's no harm in offering users the choice.
Particularly because not everyone is as well-versed with AI tools as those likely to read this article, so having to connect an MCP might be a legitimate showstopper for a lot of users.
If you're building for a traditional industry, I totally get it. But even a lot of the "AI-native" products still offer an in-product AI agent, and actively push you towards it.
The reason we don't offer the choice at all is that making your product work seamlessly on a non-deterministic environment you don't control is hard. And were we to spend time perfecting our own harness, we'd be taking away time that should be spent making it work well in user harnesses.
Were we to build it, our harness would get comparatively worse over time as we'd fall behind the edge that Anthropic and OpenAI are pushing forward, while user harnesses are actively getting better.
That means we better invest our time in working well with how people will want to use software in the future, because it's coming at us fast.
Plus, more and more people are using coding agents, even if they're non-technical, and even if they don't realize they're doing so. That means you might be turning away some users today, but that should be temporary. And if you're trying to build at the frontier of AI, maybe you don't actually want to optimize for those users today?
Letting go of control is hard work
You might be wondering to yourself what's all this hard work I'm talking about. Can't you just vibe code an MCP wrapper over your API and call it a day?
Well, that's definitely the start, but you'll quickly face a lot of issues now that users can use any model <> harness combination they want, with each behaving slightly differently.
Users will have bad experiences and attribute them to your product, even if it's not your fault at all.
You'll be flying half-blind because your logs will be missing a lot of context, especially in the case of CLIs.
CLIs and skills might be on outdated versions, and you need to make sure new features and changes don't break things for those who are behind.
Overall, there are a lot more possible edge cases, you have poor observability into them, and limited tools for addressing them.
By not offering an in-product agent, we've been forced to work on providing an amazing experience for users in their own harnesses, and have learned a ton in the process. I'm planning on sharing more about this in a dedicated article.
I'm confident that if we had our own agent it would have been prominent in our onboarding, we'd spend a lot of time optimizing it, and user harnesses would have taken a backseat. But shouldn't the best possible experience for users be the priority?
