Polymorphic Cultures: One Year In

I’ve been saying “polymorphic cultures” for a year and I’ve never actually written down what I mean by it.

The term has shown up in podcast interviews, LinkedIn comments, panel answers at SXSW, and in passing inside half the posts on this blog. It’s become a shorthand I reach for whenever someone asks me how engineering teams are changing in the AI era and in the year since I started using it, I’ve watched the phrase escape into the wild and quietly become a synonym for “a team that uses ChatGPT.”

That’s not what it means and after a year of watching real teams try to actually become polymorphic the framework has earned a proper definition.

This is that post.

The biology metaphor, done right

Polymorphism in biology isn’t “many forms coexisting in the same place.” Polymorphism is the same organism expressing different forms in response to environmental conditions. The Daphnia that grows defensive spines when predators are in the water and the locust that changes color and behavior when its population density crosses a threshold. Same creature, different expression, in response to the specific context.

A polymorphic culture, the way I mean it, is a team where the unit of work e.g a decision, a deliverable, a coordination loop can be expressed by a human, an agent, or a hybrid of both, and the culture doesn’t break depending on which form shows up.

That second clause is the one most companies miss.

Most teams I’ve seen calling themselves polymorphic are actually running heterogeneous cultures. Humans in one lane, AI tools in another, with the two lanes never meeting except when a human copies an agent’s output into a doc somewhere. That’s not polymorphism but that is two cultures bolted together hoping nobody notices the seam.

The seam, as always, is where it all falls apart.

Three properties of an actually-polymorphic culture

A year of watching teams try this has clarified the framework down to three load-bearing properties. If you don’t have all three, you don’t have a polymorphic culture… you just have a team that uses AI tools.

Substitutability of form, stability of standard.

A code review is a code review whether a senior engineer or an agent does it. A status update is a status update. A draft of a vendor contract is a draft of a vendor contract. The quality bar is fixed by the team; the substrate that produces the artifact is flexible.

Most teams have the inverse: human-only standards (the review checklist a senior engineer enforces) and agent-only outputs (the half-formed PR description the agent generates), and the standard never crosses the seam. So the human reviews the agent’s output to a different bar than another human’s output, and the team unconsciously stratifies into “real work” and “agent work.” All of that stratification is the death of a polymorphic culture before it even starts.

The teams that get this right do the boring work first: write down what the artifact has to be, regardless of who or what produces it, then make every teammate accountable to that one standard.

Shared context as the load-bearing layer.

A polymorphic team’s competitive advantage isn’t its agents. It’s the memory layer all teammates read from and write to.

This is the part most enterprise AI rollouts skip, and it’s why most of them feel like a productivity rounding error. If your agents don’t know what your last sprint decided, what’s been promised to the customer, why the last vendor was fired, or how the architecture got the way it is, every interaction starts from scratch. You’re not building leverage but you are paying for inference on the same context over and over.

The companies I’ve seen actually compound from AI investment are the ones who treated the shared context layer as the product and the agents as the consumers. The companies that treated the agents as the product and the context as an afterthought are the ones still wondering why their pilot didn’t go anywhere.

Judgment-shaped roles, not task-shaped roles.

This is the org chart implication, and it’s the one nobody wants to talk about directly.

Humans organized around tasks get displaced by agents that do those tasks. Humans organized around judgment — what problem is worth solving, what quality bar is acceptable, what tradeoff is right for this customer — get amplifiedby them.

The transition is brutal in the middle. A role defined as “writes the first draft of the report” was a fine role in 2022 and is a vanishing role in 2026. A role defined as “decides what the report needs to say, and is accountable for the decision the report supports” was always the more valuable role; it just used to come bundled with the drafting. Now it doesn’t. The teams that survive the unbundling are the ones who explicitly redefine the role around the judgment, not the artifact.

The promotion conversation breaks here first.

What actually broke

The three properties are clean on paper but in practice, the failure modes are funnier and uglier than the framework suggests.

I watched a team try to make every agent report status the way a human IC would: a daily standup message, a Friday wrap, the whole ritual. The agents were fine at it, and the humans hated it. The format was wrong for the substrate and the team was forcing one form on every teammate, which is the opposite of polymorphism. Stand-ups died inside a month!

I watched another team build a beautiful agent layer with no shared context layer underneath. Three agents, three answers to the same question, none of them usable, and the team gradually stopped trusting any of them. The investment didn’t fail because the agents were bad but it failed because there was no substrate.

And I watched a promotion conversation derail because “what this person produced” was untangle-able from “what their agents produced.” The judgment-shaped role wasn’t yet in place, and the manager and the engineer were having two different conversations: one about the artifacts (which were great) and one about the person (which was harder to evaluate than it used to be). They both walked out frustrated as that’s the non-product surface area of running a polymorphic team. The work of evaluation, attribution, and growth that doesn’t go away just because the substrate underneath shifted.

None of these were tooling failures since they were cultural failures dressed up as tooling problems which is the whole point of why the framework matters.

Why this matters more now than it did a year ago

When I started using the term, polymorphic cultures were an interesting framework for big companies experimenting with agents. The audience I was talking to was VPs of engineering at hundred-person orgs, trying to figure out how to integrate AI without ripping their team apart.

A year later, the framework is doing something I didn’t predict as it scaled in both directions at once.

It scaled up: enterprises are now grappling with polymorphism at the org-design level, not just the team level. Whole functions are getting redesigned around the substitutability principle, which is uncomfortable for the same reason every honest reorg is uncomfortable.

And it scaled down: the framework turns out to be the operating model for one-person companies. A solo builder running three ventures in parallel is, internally, a polymorphic team of one. Same three properties. Substitutability of form (the builder doesn’t care whether the contract draft comes from an agent or themselves, as long as it meets the bar). Shared context (everything every venture has decided lives in one place all the agents read from). Judgment-shaped role (the builder’s actual job is the judgment, not the drafting).

I didn’t design the framework to apply at both ends of the scale. It just turns out that the constraints are the same, because the substrate is the same. That’s usually a sign a framework is pointing at something real.

It’s also the reason the term keeps showing up in conversations that have nothing to do with each other.

A year in

The people who treated polymorphic cultures as a buzzword have mostly stopped using the term. If the phrase isn’t doing real work for you you’ll stop reaching for it.

The people who treated it as an operating constraint are quietly building the next generation of companies. Some of them are running hundred-person orgs, some of them are running one-person ones, the team shape is different but the framework is the same.

A year from now I’ll probably look back at this post and find a fourth property I missed. That’s the deal with frameworks that point at moving targets — the target moves, and the framework either keeps up or gets retired. I’d rather write down what I mean now and let the next year tell me where it was wrong than keep using a phrase nobody, including me, has actually defined.

If you’ve been building inside one of these I’d love to hear what your version of the three properties looks like. LinkedIn is the fastest way to reach me.

Let’s build.