Assembled by Your Team, Owned by Your Team, Forever

Thread AI Editorial · October 29, 2026

The firm’s engineers traced the failure and fixed the prompt in minutes, but the fallout is lasting: the new executives’ pay is now common knowledge inside the client.

This is the third time this quarter a limit has slipped in the firm’s hiring-plan reports, each at a different client. In all three cases, the methodology within the product worked as designed. Each failure came from how the limits were set, since they told the agent what not to touch instead of stopping it from reaching that data at all.

The consulting firm behind those reports advises companies on how to pay their people. From the beginning, the firm’s pay-benchmarking methodology lived with a few senior partners. These experts knew which peer groups held up for a given role and how to adjust when one job didn’t map cleanly to market data. Clients paid for this judgment, and demand for it eventually eclipsed availability on the partners’ calendars.

That prompted change. Two years ago, the firm encoded the methodology into an AI agent and packaged it as a product sold alongside its engagements. The product soon became a core offering, with 40 clients now using it to shape their growth and hiring plans. Each client sees the product’s suggested pay ranges for each role, refreshed against its own HR data, while partners spend their hours on engagements that still need them in the room. Product and people sell together.

Who Runs All This?

The firm built the product on a capable open-source framework and cloud services, with a separate environment for each client. Compensation data is sensitive client data, and walling each client off from the others was a necessary call.

Walling off the first client was a design decision. Walling off the 40th was a staffing one. Come planning season, the second-order question lands: Who runs all this? The firm has 40 environments to patch and 40 sets of limits to maintain, so every model update or patch could change how an agent behaves somewhere. Each client also has its own bounds. One client’s HR system can be read but never written to, and another’s agent is never supposed to touch executive pay.

That firm’s work piled up with every onboarding, since each new client meant a new environment, a new connection to its HR system, and a new set of limits defined and deployed. Most of this work fell to the handful of people who understood both the methodology and the setup, and some of them are the same partners the product was supposed to free up.

When the firm’s own hiring plan for next year circulates, it calls for more platform engineers than consultants. The firm set out to productize a playbook and ended up staffing itself like an infrastructure company.

The Question That Keeps Coming Back

The same week the hiring plan goes around, the client from that Monday morning follows up. Before renewing, its new CISO wants an answer to one question about its HR systems: “What can this agent access and do?”

The firm can’t answer quickly. Each client’s limits were set by hand at onboarding. For the Monday client, the rule against touching executive pay was a line in a prompt. For another, “read only” is a setting in a config file that only the engineer who set it up knows is there. It’s the Monday morning problem again, 40 times over. Client by client, nobody can say what the agent is allowed to touch, or what the next model update could change.

Before launch, a question like this decides whether a product ships. After launch, it comes back with every renewal and every new security lead. With 40 clients, that means the firm has to answer the question 40 times.

The Parts Are Free

The pieces were never the hard part. Servers, logins, permission tools, and agent frameworks are easy to get, and most are cheap or free. The cost comes after assembly, when the firm has to keep them running for every client, indefinitely. Each new client adds upkeep that never ends, and over time the upkeep becomes the business.

The framework and cloud services did what they promised, and the methodology passed every capability test the firm gave it. The harder questions are about what it takes to keep the product running and whether anyone besides the handful of people who built it can do that work.

A firm in this position should own its methodology without having to manage all the machinery. Two conditions make that possible:

1. 01Each client’s limits are written into the system, where the firm and the client’s security team can both check what the agent can read, what it can change, and who signed off

2. 02The methodology is saved in a portable format, so the firm can switch platforms or models without rebuilding the compensation advisory expertise the partners spent years refining

The first turns the CISO’s question into something the firm can look up. The second keeps the methodology the firm’s asset, one that grows more valuable with each client.

This is how a firm can own the playbook forever and leave the plumbing to the platform.

Built In

With both conditions in place, the firm’s 41st client is onboarded with bounds set and visible from Day One. Limits are enforced outside the prompt, where a model update can’t override them. And later, when a CISO asks what the agent can access and do, the firm answers by showing the record, and the partners get back to the methodology.

That is what productizing the playbook requires: people and product selling together, with the methodology reaching clients the partners will never have time to serve.

The Series

This is Post 5 of six, and the first of two about productizing the playbook. Read the thinking behind this series in the manifesto.