Walk into most knowledge-work companies and you will find agents scattered everywhere - except they are not really agents. They are SaaS subscriptions wrapped around simple prompts. An email assistant here, a content tool there, each one a black box the company rents but does not own. And there is no easy path to bring any of it in-house.
That gap is the opportunity. Not selling them yet another prompt-in-a-box, but giving them a way to in-house their agentic workflows with full visibility and full control, sitting under their own GitHub, under their own git. When the definition of an agent is just config in a repo you own, everything changes. You can hit run yourself. You can see exactly what each step cost, what tools it used, what it actually did. You get an audit log so anyone can see who did what on the system. That is the thing a SaaS wrapper will never give you.
The temptation, when a customer says "we want thirty agents for our customer success team," is to just build exactly what they asked for. No framework, hardcoded, done. Resist it. That path produces a horrible user experience because these systems need visibility, control, and continuous iteration. You are far better off building on a platform shaped by ten companies with similar needs than on a one-off you bolted together in a weekend. This is the same reason the real product is what replaces the homegrown build.
And be honest with the buyer about what they are signing up for. These are not traditional software projects you build, hand off, and walk away from. The agents need upgrading. They need cost optimization. New use cases appear constantly. Do not fool yourself that you ship it once and it rains value forever. Commit to a year. Get to a finish line, not yet another POC that dies on the vine.
The operator for all this is not a developer. Because nobody needs to read the code anymore, the right person is a clear thinker who understands the business - an ops person who can direct the work. The IC creative roles are the ones under pressure. The people who direct agents instead of writing every line are the ones who become more valuable, not less.
Key takeaways
- Many AI SaaS products are thin wrappers around simple prompts that companies cannot easily bring in-house.
- Defining agents as plain config in a repo gives the buyer full version control, visibility, and audit logs.
- The right operator for these systems is a clear-thinking ops person, not necessarily a developer.
FAQ
Why would a company want to in-house its agents?
Because the agents they are renting are often just simple prompts behind a SaaS wall. In-housing them under git gives full control, visibility into cost and tool usage, an audit log of who did what, and the ability to iterate continuously instead of waiting on a vendor.
Who operates an in-housed agent platform?
Not necessarily a developer. Because you no longer need to read the code, a clear-thinking operations person can define and refine agents through a good platform. The IC creative roles are more exposed than the operators who direct the work.
Sources
Related Essays
The Real Product Is What Replaces Homegrown
Do not compete with what Shopify is building internally. Build the system that replaces every homegrown agent platform when the engineer who built it moves on.
The Reversion to Internal Software Has Started
Companies are scattering their agents across ten SaaS tools they cannot see, cost, or control. The agentic glue belongs back inside the company.
The Agent Buyer Map: Who Builds, Who Buys
Companies with mature dev tooling build their own agent stack. Companies without it buy off the shelf. That buy cohort is the real addressable market.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.