From Roles to Morphisms

A "product manager" is not a person. It is a bundle of typed transformations: customer feedback goes in, prioritised tickets come out. An "engineer" is another bundle: tickets go in, deployed code comes out. We gave these bundles names, built career ladders around them, and assumed the structure was about people. It was never about people. It was about the transformations, and AI just made most of them free.

Category theory, the branch of mathematics that studies structure-preserving transformations, gives us the precise language to say what changed and why. The answer is not "AI replaced some jobs". The answer is that AI applied a specific mathematical operation, a functor (a structure-preserving map between categories), to the entire category of professional work, and the operation has predictable, structural consequences that run all the way from role collapse to the emergence of agent-entrepreneurs.

1. Roles as morphisms, not titles

In category theory, a category consists of objects, morphisms (arrows between objects), and a composition law (the rule that lets you chain two arrows end-to-end into a single arrow). The key insight, due to Eilenberg and Mac Lane, is that what matters is not the objects but the morphisms. The objects are just anchoring points; the arrows are the structure.

Apply this to an organisation. The objects are typed work artefacts: a customer feedback report, a product spec, a code module, a test suite, a deployed binary. The morphisms are the transformations between them:

gatherRequirements : CustomerFeedback → Spec
implement          : Spec → Code
review             : Code → VerifiedCode
deploy             : VerifiedCode → DeployedBinary

A "role" is not a title on a business card. A role is a collection of morphisms that a particular person is authorised and equipped to perform. The junior engineer's hom-set (the set of all morphisms between two objects) was {Ticket → Code, Code → TestSuite}. The senior's was {Spec → Code, Code → VerifiedCode, VerifiedCode → DeployedBinary}. The PM's was {CustomerFeedback → Spec, Spec → Ticket, Roadmap → Ticket}.

This framing is more than metaphorical. The Curry-Howard-Lambek correspondence establishes a formal connection between morphisms in certain categories (specifically, cartesian closed categories), programs in typed lambda calculi, and proofs in constructive logic. The correspondence does not apply to arbitrary categories, so I am not claiming that an organisational chart is a cartesian closed category. But the structural parallel is genuine: a task with typed inputs and outputs behaves like a morphism, and the way tasks compose behaves like morphism composition. The analogy is grounded in real mathematics, even where the formal conditions are not fully met.

2. The pre-AI assembly line

The pre-AI organisation was a category with strict sub-category (a category sitting inside a larger one, using only a subset of the objects and arrows) boundaries. Engineers had morphisms into Code and DeployedBinary. PMs had morphisms into Spec and Ticket. Designers had morphisms into Wireframe and Prototype. These sub-categories had disjoint hom-sets: an engineer could not reach Wireframe, a PM could not reach Code.

This separation was not a choice. It was a constraint imposed by the cost of acquiring the skills behind each morphism. Learning to write production code took years. Learning to synthesise customer feedback into a coherent spec took years. Learning to design usable interfaces took years. The assembly-line structure existed because each junction required a different expensive human investment, and handoffs were cheaper than cross-training.

The cost of this structure was latency. Every handoff between sub-categories required translation. The PM wrote a spec; the engineer interpreted the spec; the designer interpreted the engineer's interpretation. Information decayed at every junction. The composition deploy ∘ review ∘ implement ∘ gatherRequirements was formally sound but operationally lossy, because the humans at each step had imperfect access to the intent behind the previous step's output.

3. The AI functor

A functor is a structure-preserving map between categories. It sends objects to objects and morphisms to morphisms, and it respects composition: F(g ∘ f) = F(g) ∘ F(f).

AI applies a functor F_AI : PreAI → PostAI that does three things simultaneously:

Morphism collapse. The codified-knowledge morphisms, tasks whose logic can be fully expressed as a procedure over structured inputs, are absorbed by AI. Ticket → Code, Code → TestSuite, Spec → Ticket, Feedback → CompetitiveReport: these are now near-zero-cost, near-instant operations. They have not been improved; they have been collapsed. The morphism still exists in the post-AI category, but it is no longer human-performed.

Object fusion. Artefacts that used to be distinct objects get merged. A CustomerFeedback and a Spec and a Ticket were three separate objects in the old category because three separate people needed to touch them in sequence. In the post-AI category, a single Intent object can encode all three, because the translation between them is now automatic. The object count shrinks.

Hom-set universalisation. In the old category, sub-categories were separated by skill boundaries. Post-AI, the AI layer provides morphisms across all pairs of artefacts, acting as a universal adapter. Every person now has theoretical access to every hom-set. An engineer can produce a marketing brief. A designer can generate working code. The differentiator is no longer which objects you can reach but which invariants (properties that must always hold) you can set and validate.

4. What survives the functor

The morphisms that AI cannot perform are precisely those whose input or output types are not yet fully specified. AI excels at filling in arrows where both domain and codomain are well-typed. It struggles when the task is to determine what the types themselves should be.

Two morphism classes are structurally irreducible:

Type-formation morphisms. These produce Types, not terms. "What should the product be?" is not a question with a typed input; it is a question about what the types should be. In Lean 4 terms, this is a morphism in a higher universe. AI can instantiate a type once it exists, but it cannot determine the type without human judgement about value, strategy, and ethics.

Invariant-validation morphisms. These check whether a produced artefact satisfies a property that requires understanding intent. "Does this code do what we actually want?" is not a type-checking question. It is a question about coherence between an artefact and an intent that may never have been fully formalised. The sorry in Lean 4, the explicit marker of an undischarged proof obligation, is the formal analogue of this gap.

These two classes define the post-AI human role. The engineer becomes an invariant architect: defining what the system must never violate, reviewing AI output against those constraints, composing agentic pipelines rather than writing implementation code. The PM becomes a coherence architect: defining the decision rights and product invariants that all AI-generated artefacts must satisfy.

The ratio of thinking time to typing time inverts, from roughly 20:80 to 80:20. The human is no longer the generator; the human is the composition point, the place where one morphism feeds into the next and someone must decide whether the output is fit to continue.

5. Where the model breaks

This category-theoretic framing is a lens, not a law. It has blind spots worth naming.

First, it applies cleanly to knowledge work where inputs and outputs can be typed. It says less about roles grounded in physical presence, emotional labour, or regulatory authority. A nurse, a judge, and a construction foreman occupy roles whose morphisms are not easily expressible as artefact transformations, and AI's functor operates differently (or not at all) on those sub-categories.

Second, some role separations persist not because of skill cost but because of accountability structures. Even when an engineer can write a legal contract using AI, the organisation may still require a lawyer to sign it. The morphism exists, but the composition law includes an institutional constraint that the model does not capture: who is liable for the output, not just who can produce it.

Third, the counterargument that roles are becoming more specialised in some domains has merit. "AI prompt engineer", "AI safety researcher", "context engineer" are new morphism bundles, not collapsed old ones. The functor does not only collapse; it also creates new objects and new hom-sets. A complete model would need to account for this, and the functor analogy, being structure-preserving by definition, is not the right tool for describing genuinely new structure.

These limitations do not invalidate the lens. They bound it. The analysis that follows applies most precisely to knowledge-work organisations where artefact transformations are the primary unit of value.

6. The solo founder

In category theory, a terminal object is one with exactly one morphism from every other object to it, and an initial object (one with exactly one morphism to every other object) is the dual. I will use these as informal analogies rather than formal claims, because an organisation is not literally a cartesian closed category.

In the pre-AI category of contributors, the solo founder was closer to an initial object: intent flowed from them, but they lacked the morphisms to reach Code or DeployedBinary without hiring specialists. Post-AI, the solo founder gains coverage across the full hom-set. They can reach every artefact type, either directly or via AI delegation. The full composition from Intent to DeployedSystem becomes:

intent → [AI: draft] → [Human: validate] → [AI: deploy]

The human morphism is sandwiched between AI morphisms. The founder controls the composition points but does not perform the implementation steps.

This is not theoretical. Carta's data on US startups using their platform shows solo-founded ventures rising from 23.7% to 36.3% between 2019 and mid-2025. The sample is biased toward VC-adjacent startups, so the absolute numbers should be read cautiously. But the direction is consistent with the structural explanation: AI is removing the sub-category boundaries that used to make the solo path infeasible for knowledge-work ventures.

But terminalness has necessary conditions:

1. Closure: the founder's personal category must have complete morphism coverage from Intent to DeployedSystem, via human plus AI delegation.
2. Type-formation ownership: the founder must personally hold the intent and invariant specification morphisms. These cannot be delegated.
3. Verified composition: every AI morphism must pass through a validation step before its output enters the next morphism.
4. Invariant defensibility: at least one system invariant must be non-replicable via AI alone (domain knowledge, distribution, regulatory access).
5. Bandwidth monotonicity: the number of active composition points must never exceed the founder's cognitive capacity.

Conditions 1 and 5 are in direct tension: more coverage requires more composition points. This is why the optimal solo venture is narrow and deep, not broad: maximise the defensibility of a small invariant set while keeping the pipeline short enough for one person's bandwidth.

7. The agent as entrepreneur

Now push the functor one step further. If the solo founder's role is reduced to type-formation and invariant-validation morphisms, and if AI keeps improving at those too, what happens when the agent itself becomes the founder?

This is not a hypothetical. We are already seeing AI agents that:

• Discover market signals (customer feedback → intent)
• Generate product artefacts (intent → deployed system)
• Monitor coherence (deployed system → invariant validation)
• Adapt based on outcomes (validation → updated intent)

The full loop from Intent through DeployedSystem and back to UpdatedIntent is an endofunctor (a functor from a category to itself). When an agent closes this loop autonomously, it is no longer a tool. It is an actor in the same category as the solo founder.

But the agent-as-entrepreneur faces the same necessary conditions, with different failure modes:

Type-formation: who sets the initial types? The agent can iterate within a type space, but the choice of type space, what the venture should be about, still requires a value judgement that grounds out in human preferences. This is the alignment problem restated as a category-theoretic constraint: the initial object of the venture category must be human-specified, or the entire morphism chain optimises for an objective that may not correspond to anything a human values.

Invariant defensibility: an agent can replicate any invariant that is fully expressible as data. The moats that survive are relational (trust from specific humans), regulatory (licences, certifications), and physical (hardware, inventory). An agent-entrepreneur's venture must anchor in at least one such non-replicable invariant, or it has no defence against another agent doing the same thing slightly faster.

Verification: who validates the agent's output? The solo founder validated AI output against their own intent. If the agent is the founder, the verification loop has no external anchor. This is the open-loop failure mode: the system produces plausible outputs that drift from any meaningful objective because there is no independent invariant-checker.

The solution, the one that makes agent-entrepreneurship structurally sound rather than structurally fragile, is to build verification and governance into the category itself. Not as external oversight, but as morphism constraints that are intrinsic to the composition law.

8. Building infrastructure for the agent category

If agents are going to operate as entrepreneurs, they need the same infrastructure that human entrepreneurs rely on, but machine-readable and formally specified. The category-theoretic framing tells us what that infrastructure must look like: it is the set of morphism constraints that make the composition law well-behaved.

Human entrepreneurs operate within a rich infrastructure of composition constraints that we mostly take for granted:

• Discovery mechanisms (job boards, marketplaces, professional networks) let actors find counterparties and understand requirements. Without discovery, the category has objects but no way to find the morphisms between them.
• Legal and regulatory frameworks specify the types and invariants of the operating environment. Without a type system, morphism composition is undefined: you cannot compose "deliver software" with "receive payment" if the types of "software" and "payment" are not agreed.
• Escrow, insurance, and reputation systems determine how much evidence is required before settlement. These are verification tiers: the morphism deliverWork → receivePayment only composes if the verification constraint is satisfied.
• Corporate governance, fiduciary duties, and audit requirements constrain what actors can and cannot do without review. These are authority envelopes: the composition law itself has guards.
• Statements of work and service-level agreements define what "done" looks like before work begins. These are output contracts: pre-declared codomain types that the morphism must actually hit.

For agent-entrepreneurs, each of these needs a machine-readable equivalent. The discovery root must be a file an agent can parse, not a website a human browses. The regulatory framework must be a formal specification, not a statute book. The verification tier must produce machine-checkable evidence (replayable audit logs, output contracts with testable acceptance criteria, proof certificates for invariant compliance), not a handshake.

This is the infrastructure problem that projects like ClawCombinator (clawcombinator.ai) are beginning to address: publishing formal world models, verification policies, output contract schemas, and governance controls as machine-readable artefacts that agents can load, reason about, and compose with. Whether this particular approach succeeds matters less than the structural observation: the agent economy needs its category to have a well-defined composition law, and that law must be specified, not assumed.

9. The ladder

The progression is not a metaphor. It is a single functor applied iteratively:

1. Roles (pre-AI). Morphisms are distributed across specialised sub-categories with disjoint hom-sets. Coordination cost is high. Composition is lossy.
2. AI-augmented roles (current). The AI functor collapses codified-knowledge morphisms, fuses artefact types, and universalises hom-sets. Human roles contract to type-formation and invariant-validation. The assembly line becomes a composition graph with fewer human nodes.
3. Solo founder (emerging). A single human becomes the terminal object, covering the full morphism chain via AI delegation. The constraint shifts from execution bandwidth to composition-point bandwidth.
4. Agent as entrepreneur (next). The agent closes the intent-to-deployment endofunctor loop. The constraint shifts from human bandwidth to verification architecture: who checks the agent's invariants, and how?
5. Governed agent economy (target). Agents operate within a formally specified category where the composition law itself enforces verification, governance, and accountability. The infrastructure is the category.

At each step, the same question recurs: what morphisms can be delegated, and what constraints must hold at the composition points? The answer is never "delegate everything" or "constrain nothing". It is always a precise boundary between what can be automated and what must be validated, between the terms that AI can fill in and the types that humans must set.

The sorry in Lean 4 is the honest answer. It marks the exact point where the proof cannot be discharged without human judgement. The future of work, whether human or agentic, is about knowing where the sorrys are, and building systems that make them explicit rather than hiding them behind fluent text.

About the author: Eduardo Aguilar Pelaez is CTO and co-founder at Legal Engine Ltd and builds infrastructure for verified AI systems. ClawCombinator is an executable reference stack for agents as entrepreneurs. Read the previous essay: Legal Reasoning Needs a Wind Tunnel