A GTM Guy Built 40 Agents on His Laptop. He's Not Firable — Until He Quits.

He Built Forty Agents Off His Laptop

Last week, someone described his agent setup to me like he'd just discovered fire. He runs a GTM team, and over the past year he's built somewhere between thirty-five and forty agents — one that qualifies inbound leads, one that drafts follow-ups, one that keeps the CRM honest, a dozen more stitched into gaps nobody else on his team had noticed. Every one of them runs through his personal laptop. He walked me through it with the pride of someone who'd built something real, because he had. I told him: you're not firable. Not yet.

I've Seen This Movie Before. I Named It.

Years ago, I coined a term that got used against the company I was building. At CloudBees, I ran the Jenkins product line, and Jenkins had gotten so good at its job that you could find it running somewhere on the laptop of nearly every developer at nearly every company — unowned, unversioned, nobody accountable for any of it. I called the resulting mess "Jenkins Sprawl." Competitors picked up the phrase and threw it right back at us. Agent Sprawl is the same disease, just faster and with higher stakes.

The Numbers Are Already Low

Gartner estimated last year that large organizations will eventually run 150,000 agents. I think that number is already too conservative. Huawei, more recently, put a figure on the whole category: 900 billion agents globally by 2035. Whatever the real number turns out to be, it will not look like a handful of pilot projects quietly running in a corner of IT. It will be every function, in every company, independently building its own population of software that nobody is counting.

Building the Agent Stopped Being the Hard Part

My first agent took six months to build, and it was for a master's thesis. Every line of its behavior had to be coded by hand; nothing about it would be recognizable as an "agent" today. Contrast that with now — LLMs, coding agents, MCP, APIs, and no-code tools have collapsed what used to take a development team down to something one person assembles in an afternoon. I've written about how a release-reporting agent for our own GitHub repo took fifteen minutes end to end, and about what it takes to hand that kind of agent to an entire team without an engineer anywhere in the loop. None of that is the hard part anymore.

Three Questions Nobody's Asking

An agent isn't software you use. It's software that acts on your behalf — sends messages, changes records, triggers work downstream — and almost nobody has decided how much of that behavior they're actually comfortable with.

Ownership. Who owns this agent. Is it in production, or does "production" not even mean anything for it yet. Can it be found, or is it buried on somebody's laptop and three SaaS tools nobody inventoried. Who's allowed to change it — and what happens to that answer the day its creator leaves, which is exactly the question the GTM guy hasn't asked himself.

Authority. Access has to be earned, the same way it would be for a new hire, not granted by default because the demo worked. Picture an agent driving you from San Francisco to LA. One day it goes straight through with a single fuel stop — fine. The next day it decides, on its own, to route you through Las Vegas and Tahoe. That's the difference between something you trust and something you don't.

Evidence. If software is doing the work, you need a record of what it did and why — not "we made fifteen calls to GitHub and the API didn't respond," but what it actually decided, what it used, and why it chose to deviate. The question you need to be able to answer afterward is simple: what did this agent actually do, and can I reconstruct it.

Right now, for almost every agent running inside almost every company, the honest answer to all three is: nobody knows.

Democratization Always Builds a Platform on Top of It

Every time software got easier to create, something else had to get built to manage what got created. Git made version control trivial, and GitHub showed up to handle collaboration, review, and permissions. Containers solved packaging, and Kubernetes showed up to run them reliably at scale. Scripts could automate anything, and Jenkins showed up because nobody could run thousands of them by hand. Agent builders are about to be everywhere — dozens of good ones, in every tool an organization already uses — and none of that changes the pattern. The winning agent platform will not be another agent builder. It will be whatever brings an agent into an organization: ownership, credentials, review, authorization, and a path from someone's laptop into something the company actually depends on.

Why We're Building Joystream

Models will change. The framework you built your agent in probably won't be around in two years. The person who built it might leave. What has to survive all of that is the organization's own definition of the work — its ownership, its history, its evidence, its lifecycle — and that's the thing we think needs to outlast any individual model, builder, or employee. It's the actual bet behind Joystream: not another place to build an agent, but the place an agent becomes something a company can trust, inspect, and keep running after the person who built it is gone.

So back to the GTM guy and his forty agents: the interesting question was never whether he could build them. It's what his company does on the day he quits — and whether anyone bothers asking that before it's forty agents, not four.

Building the agent was never going to be the hard part. Making it organizational always was.