From Agent to Platform: Why the GTM Is Services-Shaped

Every major lab, every well-funded startup, and every enterprise platform vendor is converging on the same opportunity at the same time. OpenAI announced what is essentially an AI services company, hiring branded engineers to deploy agents inside enterprises. Anthropic's Claude Code is reshaping how developers interact with codebases. Cursor, Devin, Factory, and dozens of others are attacking the coding agent layer from different angles. Underneath all of it, every enterprise leader with a budget is asking the same question: how do we actually operationalize this?

The answer is not as clean as the pitch decks suggest. The agent space is the NBA of startups — fast, physical, and unforgiving. And almost everyone selling into it is making the same set of strategic mistakes.

There Is No Winner-Take-All Platform

The most persistent misconception in this space is that it will consolidate into one or two dominant platforms. I do not believe that. Enterprise AI deployment looks more like services than software. Every organization has different workflows, different compliance requirements, different integration surfaces. The gap between a demo and a deployment is not a product feature — it is understanding the customer's business deeply enough to configure, customize, and operationalize agents that actually deliver value.

OpenAI clearly sees this. Their new services arm is not a product play. It is an acknowledgment that you cannot just hand enterprises software and expect them to figure it out. You need people in the room. You need engineers who understand both the technology and the business context.

We have not once lost a deal in a head-to-head bake-off against Factory. Not because Factory is bad — but because the deals do not work that way. Enterprises are not running RFPs comparing agent platforms feature by feature. They are looking for partners who can help them figure out what to build and then actually build it.

This is the arena of arenas. There is no single board where you win or lose. You are fighting labs trying to own the whole stack, incumbents with distribution, other startups in your exact category, and the customer's own internal builds. The winner-take-all assumption is the thing that gets companies killed in this market — they pick one front and ignore the others.

The Harness Is Commoditized

Research across dozens of companies building agents in production reveals a striking pattern: the agent harness — the thing that actually executes the agent loop — is completely commoditized. With few exceptions, everyone is running Claude Code, Open Code, or some fork of an open-source equivalent. Companies that started with custom harnesses have migrated through multiple tools — homegrown loops to Goose to Aider to Claude Code — before settling on whatever the current best option is.

There is nothing to build here. There is nothing to differentiate on. Even Augment and Poolside, companies that bet heavily on owning the harness, are in an uncomfortable position as the open-source and lab-provided options improve every month. The harness is something you have as a force multiplier for an existing product. It is not something you put out to market as a standalone offering.

The real opportunity lives in the layers almost everyone is still building themselves. Look at any honest survey of how companies are assembling their agent stacks and the pattern is overwhelming. The harness is bought. The LLM gateway is bought. Triggers and services are bought. But context management, memory, skills, orchestration, and session state are almost universally hand-built. The build-versus-buy chart is mostly blue, with very little green.

The existing frameworks at those layers — LangChain, Mastra, the various agent SDKs — are overcomplicated. They started full-featured instead of starting simple. What the market needs is not LangChain with more features. It is something built bottom-up: a few clean abstractions one layer upstream of the complexity, not buried beneath it. The right question for any platform company is: what does that engineer Google when their duct-taped agent breaks at 2 a.m.? That search query is the entry point. That is the wedge.

The Maturity Gradient

Sort companies by the maturity of their dev tooling and a clear gradient appears. Highly mature orgs — Stripe, Spotify, Coinbase — build because they can. Stripe forked Goose, plugged it into existing CI/CD and testing systems, and was off. Less mature orgs buy because they have to. Ramp, despite being a sophisticated fintech company, had dev tooling immature enough that they pulled almost everything off the shelf — sandboxing from Modal, orchestration from Cloudflare durable objects, LLM gateway from a vendor, auth from GitHub.

The expectation is that those green dots slowly turn blue over time. When a core part of how you make money depends on infrastructure, you eventually bring it in-house. Modal's marketing site is not a long-term foundation for your agent platform.

This gradient is the platform opportunity. Catch the buyers before they mature into builders. Make it extraordinarily easy for less mature companies to get started — context, orchestration, and session state already built, with enough flexibility to customize. PostHog's playbook applied to agents: frictionless setup, free to start, grow with them as they scale. You are betting that today's small companies become tomorrow's big ones, and that by the time they could build it themselves, leaving you would cost more than staying.

Background Agents Are the Underbuilt Layer

The market's attention has been captured by coding agents — tools that sit in your editor or terminal and help you write code faster. That is a real and valuable category, and it is also the most crowded one. Every lab is shipping coding tools. Every startup with a seed round is building an editor plugin.

Background agents are different. They run autonomously, in the cloud, on a schedule or in response to events. They produce reviewable output. A human approves before anything executes. This is the pattern enterprises actually need — not a copilot sitting next to a developer, but an autonomous worker handling knowledge work across the organization.

Almost every agent product on the market today is a toy by enterprise standards. There is no hierarchy for organizing agents at scale. No versioning. No audit trail showing who changed an agent, when, and why. No observability for tracking reliability over time. When you have a hundred employees, each with three agents — some public, some private, some critical to operations — the current generation of tools falls apart.

I heard a story recently about a company that spent three days trying to figure out which of their agents was telling prospects they were hosting their next event in London. They were not. There was no way to trace it, no way to query across agent activities, no way to find the source of the hallucination. This is insane, and it is the norm.

Every enterprise deploying agents needs a company-wide, live log of activity. Not just token counts — though you should have those too — but real observability into what decisions agents are making and why. Every agent needs a changelog and a chain of accountability. This is software engineering, not prompt engineering.

Agents Are About to Break Out of Engineering

Here is the prediction that matters most: agents are going to break out of engineering and into the rest of the organization. Every company that has built a capable coding agent is going to look around and ask why their GTM team, their customer success team, their ops team do not have the same capabilities.

The interesting thing is that non-engineering agents are easier to build in many ways. They do not need an environment set up. They do not need to know what stack you are on. They do not need a CI/CD system or a setup script. They can be ephemeral — spin up, do the work, spin down — without any understanding of a test suite or build pipeline.

But they introduce a different hard problem: organizational context. When you build an agent for a customer success team, it needs to understand the company's processes, its products, its customer segments, its standard operating procedures. It needs a living representation of how the company actually works. And it needs to be able to surface disagreements. One person in the org might believe one thing about a process while the CEO believes something different. An agent that detects and surfaces those contradictions is genuinely valuable.

This is not Glean-style organizational search. It is something more dynamic — a knowledge layer maintained through interaction rather than documentation. Companies will want this on their own infrastructure, with their own data, connected to the tools they already have. Nobody wants to force their ops team onto a new platform. The agent has to work with SharePoint, with Slack, with whatever weird stack they have assembled over the last decade.

Glass is the case study that crystallized this for me. Same company, two products. Their engineering-focused agent is heavily bought off the shelf — Modal sandboxes with VNC and Chromium, the full infrastructure stack purchased from vendors. Their non-engineering agent is the opposite: lightweight, built with pre-commit hooks and Slack channels, almost no purchased infrastructure. When you build agents for engineers, you need so much infrastructure that buying makes sense. When you build agents for everyone else, the requirements get so light that purchasing feels like overkill. A Slack channel with a bot and some hooks goes surprisingly far.

That is a different market with different physics, and most coding-agent companies are not architected for it.

The Coding-Agent Pivot

If your entire business is a coding agent, you are about to find out what it feels like to compete on features against companies with ten times your engineering headcount and the labs themselves entering your market as service providers. The question is not whether your coding agent is good. The question is whether a coding agent alone is a business.

It is not.

At Tembo, we have been building coding agents and working with enterprise customers who chose us specifically because we are not a giant company. They picked us because they could influence the product. They could not do that with the larger players — too many customers, too much process, too little willingness to adapt. That is a real advantage, and it comes with a brutal corollary: the same flexibility that lets an enterprise customer shape your product also lets them leave in two weeks. If you have built a platform where nobody is locked in, congratulations — you have also built a platform where nobody has to stay.

So you become something harder to leave. Not through lock-in tricks or proprietary formats, but through genuine, expanding value. The coding agent is the wedge. The platform is the product. And the platform is a mesh of specialized agents — planning, research, review, GTM, customer success — coordinating across an enterprise through one consistent orchestration layer.

The pivot has to happen before the category commoditizes underneath you. Once a customer's coding agent is fungible, the only way to keep them is to be the place where their other agents live too.

The Mesh, Not the Monolith

The future is not a mega-agent. It is a mesh. Single-player, straightforward agent use cases are already solved. If a task is simple and lives entirely with one person, it is done. Commoditized. Gone. But enterprise work is multiplayer, and multiplayer is where everything breaks.

Consider a GTM team with ten salespeople. Each one has a different style, different instincts about follow-up cadence, different opinions about when to double-tap a prospect versus when to wait a week. If you give all ten the same rigidly configured agent, you have given them the worst possible salesperson — one that does not listen, does not adapt, treats every situation identically.

The right model is to give each person their own agent instance. Let them train it through interactions. Let them correct it when it gets things wrong. Let those corrections become persistent context that makes the agent better over time. Then layer above the individual agents a manager-of-managers — something that sees across all ten instances, notices that seven salespeople are coaching their agents to get better while three are coaching theirs to get worse, identifies patterns that work, and locks in company-wide policies when the data supports it.

This is the mesh. Individual agents learning at the edges. Orchestration agents enforcing consistency at the center. The whole system evolving faster than any single agent or single human could alone.

A pattern I keep seeing in production is what I think of as agents-as-org-chart. Instead of one monolithic agent, you create an organizational structure — a CEO agent, a CPO agent, a CTO agent, a CMO agent — each with its own prompt, skills, and scope. The CPO agent knows about pricing and product management. The CMO agent knows about marketing and positioning. When a task comes in, the CEO agent delegates to the appropriate agents, who create subtasks, building a tree of work. It solves the context window problem by scoping each agent to what it actually needs to know, and it creates natural checkpoints — tasks block when an agent has a question for a human, and the human can see exactly why and what action is needed.

If your agent is just a prompt with some tool configs wired together, it is a demo. Production agents are software repositories. They have codebases that evolve. They have version control. They have a diff you can review before changes go live. Would you deploy any other piece of business-critical software without version control, without code review, without a deployment pipeline? Of course not. So why are we treating agents differently?

Forward-Deployed Engineering Is the GTM

The uncomfortable truth about selling enterprise agents is that you almost certainly have to do forward-deployed engineering. You have to embed with the customer. You have to help them raise their agent from infancy.

The Palantir model fits here. You go into a large organization, identify their most expensive knowledge work, and say: we will embed inside your team and build agents that actually work for your specific processes, your specific tools, your specific culture. This is not professional services bolted onto a SaaS product. This is the product. The agent that works on day one hundred is the product. The process of getting there — the training, the corrections, the context accumulation — that is the deployment.

Every interaction where a human corrects an agent should generate two outputs: the fix for the immediate task, and a context update that makes the agent permanently smarter. Every PR should have a shadow PR for learned context. The agent should be writing down what it learned, not just what it did.

There are two viable strategies for an agent platform company, with different time horizons. The bottom-up play targets less mature companies and competes on time-to-value. The top-down play works directly with enterprises that want to self-host and helps them build infrastructure they cannot pull off the shelf. Top-down generates revenue now but is harder to scale. Bottom-up builds a more defensible business but takes longer to monetize. The best outcome is doing both — using enterprise engagements to fund development of the platform that eventually serves the long tail.

This is why the GTM is services-shaped. Not because services are the destination, but because services are how you learn what the platform actually has to do.

Build Fast, Build Well

There is no magic bullet here. No single defensible moat that guarantees survival. The labs have more money. The incumbents have more distribution. The other startups have their own smart, hungry teams.

What you can control is the quality of what you build and the speed at which you build it. The agents space is going to be enormous — every white-collar salary in the world is theoretically in play. Of course there will be hundreds or thousands of companies competing. The question is whether you can build something good enough, fast enough, that customers choose to spend money with you rather than the alternatives.

We have done that against Devin. We have done it against Cursor. Not by having a better brand or a bigger sales team, but by being in the arena, close to the customer, solving real problems with real software.

A general-purpose agents company is a software engineering company with a forward-deployed sales motion and a platform play hiding underneath the wedge. Nobody is fully ready for that. That is exactly what makes it the opportunity.

Move fast. Build well. Stay close to the customer. The rest is noise.

— Ry