For most of the last decades, this question answered itself. If you had a problem, you wrote a ticket, you pushed, you waited and someone in IT built the solution if you were lucky. Building software required engineers, engineers were scarce, so a gate made sense. You couldn't let everyone build.

That gate is not only cracking but diminishing rapidly. Building an agent is now cheap enough, and close to plain language available, that the person staring at the problem can often prototype a fix themselves. It only takes an afternoon or some minutes, without a ticket, without asking permission. Meaning, the question is now "If the person with the problem can build the agent, should they?"

This matters to me for a specific reason. Most organizations run on non-engineers, and we already don't have enough engineers to go around all problems we and an organization is having. If we want speed and if we want solutions shaped by the people who actually understand the problem, then we have to lift the capability of everyone else, not just guard the gate. So I want the answer to be yes, but wanting it doesn't make it easy and simple.

The trap in the question

Here is the thing I had to work through: "should they build it" is the wrong question, because it hides three different questions inside one word. Building is not owning. Owning is not maintaining.

When we argue about "who should build agents," we usually collapse all three into a single decision. That is in my head the main mistake. You can, and I would argue you should, let different people hold different parts.

The tensions don't care who builds

I made two lists while thinking about this today. One for "yes, the problem-owner builds it," one for "no, engineering, or something similar should do it." Then I noticed something uncomfortable: most of the hard problems showed up on both lists.

Prioritization. Ownership. Capability. Who runs it after launch. How leadership keeps sight of what is being built. None of these are solved by deciding who holds the keyboard and tools. They are the permanent tensions of building things inside an organization, and they are yours, dear leadership, regardless of the path you pick.

Only one tension is genuinely unique to the problem-owner path: capacity and will. Does the person actually want to fix it, or are they stuck in delivery mode with no room to breathe? That asymmetry is real — and it is the actual cost of decentralizing. But notice it is a cost about people and time, not about who is allowed to build.

So here is where I land

The person with the problem should build the first version. They hold the knowledge you cannot easily transfer: the limitations, the workarounds, the unwritten rules, the difference between what looks good in a spec and what actually works on the floor. That knowledge decays every time it is handed to someone one step removed. It is also often hard to make explicit in specifications. For the prototype — the messy, revealing first version with core specifications — proximity beats polish.

But ownership, operations and prioritization need a home from day one. Not eventually. From the start. Someone has to be accountable for this agent existing, for keeping it safe, for deciding when it grows and when it is retired. And that someone can be the one that builds it initially, but it is rarely the person who built it in an afternoon. Building that home is not the builder's job. It is leadership's job.

The gate didn't disappear — it moved

So we don't actually get rid of the product development gates. We just moved it.

For twenty years it stood in front of one question: who is allowed to build? That gate is gone; the tools took it down. But another gate takes its place: who is accountable for what gets built? And that is not a gate the person with the problem can stand at. That one belongs to leadership.