Your Web Portfolio Needs an Operating Model

I’m optimistic about the future of the web. In the early 2000s, Facebook and Google were supposed to make websites an afterthought. Now it’s agents. The web lasted then because it is the one medium an organization can own, in its own words, and that holds as AI changes how people reach it. What grows is the operational load: more sites, more changes, and more kinds of traffic for the teams keeping the web secure and maintained.

That is why we have been rebuilding Pantheon around the whole portfolio. It is the thinking behind Agentic Fleet Management, our approach to seeing, operating, and governing many sites as one system. It is also why we made the platform programmable: the Pantheon Public API and MCP Server, now in public beta, let your own scripts and the AI tools your team already uses work directly with your sites.

I lead the product, design, and engineering teams building these capabilities. A capability tells you what is possible. The question I care about more is how your team works once agents can take part in running your sites. In many ways, the fundamental problem is the one web teams have always had: fleet-level responsibility, site-by-site work. What has changed is the rate.

That calls for an operating model. I would describe it in four parts:

• A shared understanding of what is running and what needs attention.
• Clear ownership and decision rights for the fleet and for each site.
• A repeatable way to prepare and coordinate changes.
• An explicit path for deciding what reaches production.

Dashboards inform that model. Agents can help carry it out. The decisions behind it still belong to people.

Decide what belongs to the fleet and what belongs to the site

A university department serves a different audience from admissions. A regional brand may need its own integrations and release schedule. The leadership task is to separate useful differences from accidental inconsistency.

I see a version of this in engineering teams right now. AI makes it so easy to build a new tool that one team can end up with five ways of doing roughly the same thing, with little established practice to settle on. Web portfolios drift the same way: a slightly different deployment script here, a one-off configuration there.

Take a shared software update across a university’s sites. The fix is the same everywhere. One site is in the middle of an admissions campaign, another is ready for maintenance, and a third has a customization that needs extra testing. A good operating model lets the team prepare the shared change once and still account for local timing and risk.

So make the choice deliberately. Which standards belong to the fleet, such as how updates are tested, reviewed, and promoted? Which decisions belong to the people closest to the audience?

Make visibility useful to the person doing the work

Suppose a traffic pattern appears across several websites. Which sites are affected? Is the activity expected? Is it affecting visitors? Who should look into it?

A central team may spot the pattern. A local team may know a campaign explains it. The value comes from connecting those perspectives. When the investigation starts over in a ticket, a spreadsheet, or a chat thread, the team loses most of what the portfolio view gave them.

I measure useful visibility by how much uncertainty the team can remove before acting.

Give agents a defined job

Agents can now take part in real operational work. With the Pantheon MCP Server, compatible AI clients can inspect sites and environments, retrieve logs, investigate build failures, and perform supported actions such as creating a Multidev environment or rolling back a deployment. Those requests use the connected person’s existing Pantheon permissions, and state-changing actions require explicit approval in the AI client.

The Public API lets teams connect their own scripts, integrations, and automation to supported platform operations. It checks the caller’s identity and permissions on each request. API automation has no built-in per-action approval prompt, so teams design the right authorization and review into their own workflows.

Before giving an agent a task, define its scope. Which sites and environments are involved? What may it inspect or change? What evidence should it return? Which decision stays with a person?

The bigger risk, in my view, is an explanation nobody checks. AI can produce a detailed, confident account of what went wrong. If someone approves a rollback on the strength of that account, and others build on the decision, a small misunderstanding compounds. An approval prompt is a control. The judgment still comes from the person approving.

Keep review from becoming the next bottleneck

If AI helps a team prepare more changes and each one waits for a single person to reconstruct the context, the bottleneck has simply moved. For a consequential change, the reviewer should be able to see:

• What problem the change addresses and which sites are in scope.
• What changed, where it was tested, and what the checks showed.
• Which exceptions or unresolved risks remain.
• Who can approve the next step and how the team would recover if needed.

That evidence should travel with the change, whether a developer, a script, or an agent prepared it.

The industry talks a lot about guardrails. I think of them as the last line of defense. Teams need structure that keeps the work on the road in the first place: scaffolding that lets people and AI work together with confidence. Part of that is deciding in advance which routine operations can run within established rules and which need explicit approval.

Start with one recurring piece of work

The tools are just tools. Pick a shared update or a recurring maintenance task and follow it from discovery through release.

Can the team identify every affected site without rebuilding the inventory? Is ownership clear? Can it reuse the common work while handling exceptions? Does the reviewer receive enough evidence to make a decision? Can everyone tell what happened afterward?

Where those answers break down, you have found your starting point. Faster tools matter. A team that knows how to use them together matters more.

Explore how Pantheon’s MCP Server connects your existing AI tools to your sites and environments.