Build on the Stack You Have: The Rollout Pattern That Makes AI Compound

The fastest way to waste a year with AI is to treat it like a set of clever tools that individuals can “try out.” You get a burst of energy, a handful of impressive prompts, and a quiet mess: scattered data access, inconsistent answers, and a security team that finds out after the fact.

The phrase “build on the stack you have” keeps showing up because it is the opposite of that. It is a constraint that forces focus: use the systems people already live in, and make the improvement feel like a workflow upgrade, not a new job.

That idea came through clearly in the SaaStr writeup on a shared playbook across very different leaders, from Atlassian, Anthropic, and Scale, all converging on building AI into the tools and processes companies already run on. I agree with the direction. But I think most teams fail in translation.

So here is the translation: “build on the stack you have” is an operator’s rollout pattern. It tells you what to standardize, what to shut down, and how to set up a small group that turns pilots into compounding workflow assets.

The tension: pilots feel cheap, but the mess is expensive

Pilots are seductive because they are easy to start. Someone adds a copilot extension, signs up for an LLM workspace, pastes a few documents, and declares a win. No budget meeting. No integration work. No tough conversations.

Then the bill arrives in a different currency: rework, distrust, and hidden risk.

• Rework: people cannot reproduce each other’s results, so every “win” is personal craftsmanship, not a repeatable capability.

• Distrust: when two assistants answer the same question differently, the organization learns the wrong lesson: AI is random, so ignore it.

• Hidden risk: access paths multiply. Data moves through unmanaged tools. Nobody can explain what was used where.

The fix is not “more governance” as a vibe. The fix is a small set of standards that create a shared control plane, and a willingness to remove alternatives that bypass it.

Standardize four things early (or pay forever)

If you want AI to compound, standardize what makes it controllable. You can let teams vary on prompts and UI experiments. Do not let them vary on identity, permissions, documentation, and evaluation.

1) Identity: one user, one trace

Every interaction that matters should be attributable. Not for policing, for learning. If you cannot tie a result to a user and context, you cannot debug failures or spread what works.

Identity is also how you keep AI inside your stack. Single sign-on is not a checkbox. It is the difference between “this is our tool” and “this is something people do on the side.”

2) Permissions: least privilege, workflow-aware

Most permission models are built for humans clicking screens. AI shifts the shape of access because it can traverse and summarize across systems.

So the question is not “can the assistant read the folder?” It is “can the assistant perform this action in this workflow, with this audit trail?” If the permission model does not reflect workflow boundaries, you will either block everything or leak everything.

Practical rule: start restrictive, then open based on observed value and controlled pathways. It is much easier to add access than to unwind it after content has spread into prompts, notes, and exports.

3) Documentation: treat prompts and workflows like product

Documentation is where pilots go to die, which is exactly why it must be standardized.

You need a place where a workflow improvement becomes legible to the next team. Not “here is my prompt,” but “here is the job to be done, here is the input contract, here is the expected output, here is the failure mode.”

Make the unit of reuse a workflow card:

• Trigger: when do you use it?

• Inputs: which systems and fields does it rely on?

• Output: what does “good” look like?

• Escalation: when should a human take over?

• Owner: who updates it when the process changes?

This is the same muscle as shipping features: clear contracts beat tribal knowledge.

4) Evaluations: a simple harness beats arguments

Without evals, every debate becomes taste. With evals, you can improve the workflow the same way you improve software: measure, change, re-measure.

Keep it simple at first:

• Golden set: 20 to 50 real examples from the workflow.

• Scoring rubric: what correctness means (and what is unacceptable).

• Regression checks: when prompts, retrieval, or models change, re-run.

If you already ship software, this should feel familiar. In fact, the fastest adoption I have seen came when teams stopped talking about “AI quality” and started treating it like a testable system.

Kill two things decisively: shadow copilots and private knowledge hoards

Standardization is only half the job. The other half is subtraction. If you want a shared AI capability, you cannot keep parallel tools that undermine it.

Shadow copilots: the quiet fork of your org

A shadow copilot is any assistant that sits outside your identity and permission model. It might be well-intentioned. It might even be approved “for now.” But it creates three forks:

• A fork of data paths (what got pasted where).

• A fork of user behavior (teams learn different habits).

• A fork of truth (answers differ, and nobody knows why).

Be explicit: which assistants are sanctioned, in which contexts, and which are not. If you do not draw the line, your best people will build around you, and your most cautious people will opt out entirely.

Private knowledge hoards: stop rewarding “prompt whisperers”

Every organization produces a few power users who get great results. The common failure is to celebrate them without extracting the asset.

If a prompt or workflow trick is valuable, it belongs in the shared library with an owner and an update cadence. Otherwise, you have created a new class of key-person dependency, dressed up as innovation.

This is also where incentives matter. If you praise heroics, you get more heroics. If you praise reusable workflow cards that others adopt, you get compounding.

The org design that turns pilots into compounding assets

Most “AI task forces” fail for a simple reason: they are staffed to explore, not to integrate. Exploration is necessary. Integration is what changes the business.

You want a small enabling group with a narrow charter: turn proven pilots into reusable workflow assets inside the stack you already run. Think of it as productizing internal workflows.

Here is a structure that holds up under pressure:

• Workflow owner (from the business): defines what “good” means, chooses the first use cases, owns adoption.

• Platform integrator (from engineering or IT): identity, permissions, connectors, audit.

• Evaluation lead (could be QA-minded): golden sets, rubrics, regression checks, incident review.

• Change lead: training, docs, rollout comms, feedback loops.

Not a big team. A clear interface. And one rule: the group does not build random demos. It only ships workflow upgrades that live in the tools people already open every day.

This is also where you borrow from transformation mechanisms that prevent silo theater. If you want a tighter set of steering tools, I wrote a separate piece on five mechanisms that prevent silo theater. The same logic applies here: clarity of ownership, cadence, and decisions beats enthusiasm.

A lived example: the moment you realize “pilot” is a governance choice

I once watched an R&D organization ship multiple “assistants” in parallel, each built by smart teams trying to help. They worked. Individually. Then a release changed a shared dependency, and nobody could agree whether quality improved or regressed because each tool used different prompts, different context sources, and different acceptance criteria.

We did not fix it by picking the “best” assistant. We fixed it by standardizing evals and documentation, then collapsing the tools into one sanctioned path with clear access rules. The visible impact was fewer arguments. The real impact was speed: improvements stopped resetting to zero every time a model or prompt changed.

The point is uncomfortable but useful: pilots become permanent when you avoid the hard work of standardization. “Temporary” is often just “unowned.”

The rollout pattern you can run this quarter

If you want a concrete sequence, use this:

1. Pick two workflows where the output is easy to judge and the handoff pain is real (support triage, sales call summaries to CRM, incident writeups, PRD drafting with a defined template).

2. Define the input contract: which systems are allowed sources, what fields matter, what is out of scope.

3. Install the control plane: SSO, permission boundaries, audit trail. No exceptions for “just this team.”

4. Create a golden set from real cases and write a rubric. Start small. Make it executable.

5. Ship a workflow card inside the primary tool (ticketing, CRM, docs, chat). Keep usage friction low.

6. Run a weekly review: adoption, failure modes, regressions, and one improvement shipped.

7. Kill alternatives that bypass the standards. Be polite, be firm, be fast.

If your organization is already thinking in “control plane” terms for AI, you may also like AI architecture isn’t a diagram. It’s an operator’s checklist. The through-line is the same: reliability is designed, not hoped for.

My opinion: “build on the stack you have” is a discipline, not a preference

Building on the stack you have is not about being conservative. It is about compounding. When AI lives inside your existing identity, permissions, docs, and evals, every improvement becomes reusable. It spreads through workflow cards, not hallway conversations. It survives staff changes. It gets safer as it gets more useful.

When AI lives outside the stack, you might move fast for a month. Then you spend the next six cleaning up the consequences and trying to rebuild trust.

If you want one sentence to guide decisions: standardize the control plane, and only then scale the creativity.

And if you are tempted to measure success by hours saved, I would challenge that instinct. The real goal is throughput with confidence. I unpacked that tension in Stop Measuring AI by Hours Saved.

The best rollout is the one that makes next quarter easier than this quarter. That is what compounding looks like.