← All posts

The cPanel Moment

·3 min read
thesiscloud-historyagent-infrastructuremental-model

The most common suggestion I get from infrastructure people looking at the AI agent space: “We need Terraform for agents.”

They’re not wrong about where this is headed. They’re wrong about where it is now.

Terraform shipped in 2014. It worked because the operational substrate was already mature. AWS had CloudWatch, IAM, CloudTrail, Auto Scaling. Datadog and New Relic existed. Chef and Puppet existed. You could see what was running before you declared what should be running. That’s the prerequisite Terraform took for granted.

Agent infrastructure doesn’t have it. Most operators can’t tell whether their agent’s credentials have expired. Configuration is scattered across eleven-plus files with no diffing, no versioning, no validation. Monitoring means “did it crash.” When something goes wrong you SSH into the container and grep the logs. I spent four years at RightScale and AWS watching the cloud version of every one of these problems.

This isn’t 2014. This is 2003.

What 2003 looked like

Before cPanel, running a web server meant editing Apache configs by hand, restarting services over SSH, and hoping you didn’t fat-finger something that took down every vhost on the box. cPanel didn’t make Apache better. It sat on top of Apache, MySQL, BIND, and sendmail and gave operators a way to see what was running and change it without destroying things. It separated the management layer from the runtime.

That separation is the phase transition that recurs. RightScale did it for cloud. Kubernetes did it for containers. Each time, the separation happened before the declarative tooling arrived — because declaring desired state requires being able to observe current state.

Agents haven’t had that separation yet. The evidence is everywhere: operators editing config files that should be dashboards. Scheduled work held together with cron and webhook glue. Security as a 30-item opt-in checklist that the framework ships without. The community has produced hundreds of personality templates and virtually no operational configuration templates. All of this maps directly to pre-cPanel web hosting, pre-RightScale cloud, pre-Kubernetes containers. I know because I was there for the middle two.

Why the phase diagnosis matters

If you think you’re in the Terraform era, you build declarative config, state management, drift detection. Good work for 2028.

If you recognize you’re in the cPanel era, you build operational visibility. Can operators see what’s running? Can they change configuration without breaking things? Can they tell whether the system is healthy? The declarative layer comes after operators can see what they’re declaring.

The timeline is compressed — the adoption curve that took cloud the better part of a decade is playing out for agents in a couple of years. The phases will overlap. But compressed doesn’t mean skippable. I’ve watched three infrastructure substrates go through this sequence. You don’t get to skip the management layer and jump to infrastructure-as-code. The people who try end up building state management for a system whose operators can’t tell you what state it’s currently in.

We’re in the cPanel moment. The management abstraction is about to separate from the runtime. Build accordingly.