We Can all be Work Designers in the Composable Enterprise

Composable workflows are important for AI readiness, but they start with a mindset shift and simple practices that anyone can try.

In recent editions, we explored how codifying work can make it visible and legible, and how codifying rulesets can help socialise and guide enterprise AI agents. This week, we will consider how to build on this by composing individual components and services into workflows and processes that both people and machines can understand and use.

Employees are taught to follow processes, but rarely to think about how to compose and design them. Most teams are excellent at doing the work, but have not been empowered to shape their process steps into reusable building blocks that others (colleagues or AI agents) can easily adopt or plug into.

Ethan Mollick captures the current reality for most firms in his latest piece, using the metaphor of organisations as “Garbage Cans,” where unwritten rules, bespoke knowledge, and undocumented processes are the norm. In such environments, scaling automation or AI agents is harder than it should be, because there are no clear rules or structures for them to follow.

The Garbage Can represents a world where unwritten rules, bespoke knowledge, and complex and undocumented processes are critical. It is this situation that makes AI adoption in organizations difficult, because even though 43% of American workers have used AI at work, they are mostly doing it in informal ways, solving their own work problems. Scaling AI across the enterprise is hard because traditional automation requires clear rules and defined processes; the very things Garbage Can organizations lack. To address the more general issues of AI and work requires careful building of AI-powered systems for specific use cases, mapping out the real processes and making tools to solve the issues that are discovered.

Where documented processes exist, they are often built for control, not clarity; and when AI meets this environment, it inherits the chaos rather than simplifying it.

Composability is less a technical exercise and more of a mindset shift. It’s about breaking work down into pieces that are understandable, moveable, and adaptable. You don’t need to be an engineer to do this. You just need to start thinking about tasks as ingredients you can name, package, and reuse.

And most importantly, you can begin quietly, right where you are. No new platform, no leadership approval, just a willingness to structure what you already do in a way that makes sense to others.

This edition explores how to make that shift, why it matters, and how you can take the first step this week.

Why Work Needs to Be Designed, Not Just Done

Most teams don’t experience their work as a neat, end-to-end process. Instead, they live inside messy middle layers: juggling inputs, nudging tasks forward, recovering from ambiguity, and compensating for missing information or context.

Even where formal processes exist, they’re often designed for control, not clarity:

• Documented as static SOPs no one reads.

• Dependent on tribal knowledge and interpersonal handoffs.

• Optimised around departments or systems, not actual flows of value.

So when people try to automate, delegate, or hand over tasks, the invisible glue falls apart and we are left with partial flows, brittle bots, or “let me just do it manually” shortcuts.

This isn’t a tooling problem. It’s a framing problem.

The Foundations of Composability

If codifying work is about making it visible and legible, composing work is about making it usable - in different contexts, by different people, and increasingly by different intelligences.

Composability begins with how teams frame their work.

We’re used to thinking either too big (at the level of projects and roles) or too small, in isolated steps. Composability asks us to work in the middle layer: identifying the units of work that carry intent. These are not just checklists of actions, but self-contained “blocks” that have a purpose, inputs, outputs, and clear handoffs. At this level, workflows stop being rigid procedures and become modular recipes that can be reused, recombined, and adapted.

Three principles can help make that shift:

1. Name the Building Blocks

When work feels fuzzy or “we just know how to do it,” the first step is to break it down into its smallest useful units. These don’t need to be atomic in a technical sense - just coherent enough to hand over.

A good block has:

• A clear intent (what’s the purpose?)

• Defined inputs and outputs (what does it need, and what does it produce?)

• A specific trigger (when does this happen?)

These blocks form the raw material of composability.

2. Make Relationships Visible

Work rarely happens in isolation. Tasks depend on one another, and those dependencies are often implicit or assumed.

Composable thinking means getting comfortable mapping relationships:

• What must come before this?

• What can happen in parallel?

• What happens if it fails?

It’s less like writing code and more like mapping a recipe or choreographing a dance: clarity in the handover, flexibility in the sequence, and plenty of scope for human judgment.

3. Design for Reuse, Not Just Completion

We’re often trained to finish the work, not to package it for others.

Composable teams think in patterns:

• How could this task be reused in another project or context?

• What would someone else need to run this without me?

• Could this be handed to an AI agent with enough context to complete it safely?

Even if you never automate a task, making it modular and self-contained reduces rework, simplifies onboarding, and makes collaboration smoother.

This is not a process mapping exercise for specialists. It’s a mindset shift for every team:

• From implicit to explicit.

• From personal memory to shared logic.

• From linear execution to adaptive recombination.

The most composable teams aren’t the most technical, but those that can make their work explainable, modular, and moveable.

Simple Team Tools That Can Make Work Structures Visible

It’s tempting to jump straight into orchestration platforms or AI agents; but without clear structure, these tools end up automating confusion.

True composability starts with how teams structure and narrate their work. Tools become powerful when they help us surface that structure, test it, and refine it over time.

Here are a few categories of tools that support composable thinking, each with a human-first entry point:

🟩 Visual Workflow Mappers

Tools like Mural, Whimsical, or even sticky notes on a wall can help teams break down processes into modular chunks. The goal isn’t detail, it’s visibility:

• What are we actually doing?

• Where are the natural breakpoints or handoffs?

• What repeats? What varies?

This is how most good design work starts: not with code, but with shared understanding.

🟨 Lightweight Orchestration Tools

Once blocks are clear, simple orchestration tools can help sequence them. Think of these like flow builders:

• Zapier or Make (no-code)

• LangGraph or ReAct-style frameworks (for agentic workflows)

• CrewAI, Autogen, or Function Calling (if going deeper into agents)

🟦 Prompt Libraries and Execution Playbooks

In many cases, the most accessible form of composition is a library of prompts or reusable workflow snippets tied to specific tasks. These can be:

• “How we summarise a report”

• “Steps for reviewing a data set”

• “Checklist for onboarding a new vendor”

Over time, these small units can be strung together, first by humans, then by orchestration tools or AI agents.

🟧 Supervision and Oversight Layers

As workflows become more complex, teams need transparent oversight rather than top-down control:

• Who is responsible for each block?

• What happens when something fails?

• Is the process evolving as intended?

This is where composability meets governance, and why codified ownership, logging, and escalation logic matter.

None of these tools require a technical background to get started. But they do require teams - and especially team leads - to step into a new role, not just as doers of work, but as architects of the flows and systems that support it.

Think of this as the modern version of "working out loud." When teams make their logic visible and modular, they’re laying the foundation for safe and scalable AI integration.

Read on for some examples of how teams are making work more modular and some starting exercises you can try in your work context.