Stage 2 · Design a Digital Workforce
Think Like a Manager, Not a Technologist
After this you can reframe an AI question from what the technology can do into what the work actually needs done.
Recommended first: So What Is an Agent?
You know what an AI worker is. A team of them is a different problem. This module opens the Design stage by naming the pattern organizations hit when digital workers get added one at a time, describing the managed state you want instead, and making the one change in framing that gets you there.
What you will be able to do
- Explain why running several AI workers is a different problem from using one
- Describe the unmanaged pattern and the managed state you want in its place
- Turn a technology request into a management question before any tool is chosen
One Worker Is Useful. A Team Is Different.
The Understand stage gave you the anatomy of a single digital worker: brain, skills, tools, context and memory. That is enough to put one worker to work. It is not enough to run several.
Now it is time to think about how multiple agents work together, and how you, as a manager, stay in control of all of them. Those are two separate questions and both are yours. This stage is written for the people who already carry that kind of responsibility:
- Business leaders managing teams or programs
- Operations and workforce professionals
- Project and program managers
- Anyone building or overseeing AI-enabled workflows
By the end of the Design stage you can scope a business function, define agent roles, draw a working org chart, and set up tracking and orchestration, without writing code. None of that is engineering. All of it is management.
The Problem Most Organizations Hit
AI programs can struggle when organizations skip the management layer.
The pattern is recognizable once you have seen it. Put the two states side by side.
| What usually happens | What you want |
|---|---|
| Random tools added one at a time | Clear ownership per agent |
| Nobody knows what each agent is responsible for | Defined handoffs between agents |
| No visibility into what is actually running | A register you can audit |
| Overlap, gaps, and finger-pointing | One orchestrator that routes the work |
| Leaders afraid to trust it | A human in the right place in the loop |
Read the left column again and notice what is missing from it. Not one of those five items describes a model that reasons badly or a tool that fails to run. They describe unclear ownership, undefined handoffs, no visibility, and a leader who cannot see enough to sign off.
Sound familiar? That is also how poorly managed human teams break down. The same list would describe a department where nobody wrote the roles down, and you would not fix that department by buying it better software.
The right column is the Design stage stated as an outcome. Every module that follows builds one of those five rows.
Tech Framing Versus Management Framing
Here is the change that produces the right column.
The question is not "what can AI do?" The question is "what does this function actually need done?"
| The tech framing | The management framing |
|---|---|
| "Let's set up an AI for emails" | What does this function produce? |
| "Let's automate the reporting" | What are the repeatable tasks inside it? |
| "Let's build a chatbot for HR" | Who is accountable for each outcome? |
| Starts with the tool. Ends with confusion. | Starts with the work. Ends with a team. |
The left column is not wrong because those are bad ideas. It is wrong because it starts at the tool and then goes looking for work to justify it. Nothing in those three sentences says what the function produces, which of its tasks repeat, or who owns the result. So the tool arrives, and ownership never does. The right column starts from the work and arrives at a team. Same technology either way, different order of questions.
One test keeps you honest. You would not hire a new employee without a job description. Do not deploy an agent without one either. If you cannot write down what this agent is responsible for, what it produces, and who reviews its output, you are not ready to deploy it. You are still scoping.
Key takeaways
- Running multiple agents is a management problem, not a technology problem: it needs ownership, handoffs, visibility and a human in the right place in the loop
- The unmanaged pattern is random tools, unclear responsibilities and no audit trail, and it is the same way poorly managed human teams break down
- Stop asking what AI can do and start asking what the function actually needs done
- You would not hire an employee without a job description, so do not deploy an agent without one
Next step
The management framing starts with one function, not the whole company. The next module gives you the three questions that turn a function into an agent design brief. Continue with Scope the Function First.