They Don't Get It: The One-Case-Type Anti-Pattern Is Succeeded by the One-Agent Anti-Pattern
The Dynamic Work Design Approach from 2018 by Repenning and Kieffer from MIT is becoming even more important in the Age of Agentic AI.
The Anti Pattern
A long-standing anti-pattern in workflow design is the one-case-type solution: one component built to deal with every variant of a request, wrapping heterogeneous work into a single structure so that its differences never have to be separated. The case type holds routine approvals, exceptions, and edge cases side by side, with branches so deep that nobody can say which path is correct.
In the age of agentic AI, the same error returns in a new form. The one-agent solution is one agent given every tool, a broad brief, and responsibility for the whole case. It looks efficient for the same reason the one-case-type design does: there is one thing to build and one thing to govern. In practice, it overloads a single agent with tasks that need to be handled separately, and it removes the accuracy that specialization would provide.
The people who build either design don't get it. They optimize for the number of components, when the design question is how the work should be divided.
The continuum between generalism and specialism
Every component sits somewhere on a continuum between generalism and specialism. A generalist handles many kinds of work with one configuration. A specialist handles one kind of work with a configuration tuned to it. Neither end is wrong in itself. The error is choosing a position on the continuum by default, usually toward generalism, because a generalist is one thing to build.
Poor design happens when the split is not made in either place. In work design, the variants of a request that need different handling are not separated into distinct paths. In solution design, the component that performs the work is not separated into distinct units, each suited to one kind of task. The result is a component that is too general to be accurate and too coupled to be changed.
Judgment is not only agentic
The continuum applies to judgment itself, and judgment does not have to be performed by a language model. A deterministic rule is judgment made explicit: a decision table that says what happens when a claim exceeds a threshold and the policy is in force. It is the most predictable form of judgment, because its logic can be read, tested exhaustively, and audited. A machine learning model is judgment learned from data: a score that estimates risk or classifies a pattern from many labeled examples. It is probabilistic, but its behavior can be measured against held-out data and monitored for drift. A language model agent is judgment over unstructured input: reading a free-text complaint, weighing evidence in a document, or drafting a response. It is the most flexible form, and the hardest to predict.
Each form fits a different kind of judgment, and the right choice follows from the nature of the decision. Where the criteria are known and stable, a rule is the specialist. Where the criteria must be learned from patterns in historical data, a model is the specialist. Where the input is open-ended language and the output needs reasoning, an agent is the specialist. Using an agent for a decision a rule could make is the one-agent anti-pattern in its purest form: a generalist tool applied to work that has a more precise specialist. It adds cost and unpredictability to a decision that did not need either.
There are places where you don't need AI. If you know your business rules, you should not have an agent derive them again. A rule costs no tokens and behaves the same way every time, which a language model cannot guarantee. AI belongs where rules run out: interpreting unstructured requests, extracting data from documents, summarizing a case, and researching similar cases.
This changes the split. In a well-designed workflow, the judgment units are not only agent steps. Some are decision tables, some are model scores consulted by a rule, and only some are agents. The Pega architecture supports this mix: the same case can call a deterministic decision, a scored prediction, and an agent step, each in the stage where its judgment is needed. The design question is therefore not whether to use an agent, but which kind of judgment each unit requires, and whether the rule, the model, or the agent is the most specialized tool for it.
Why the one-agent design fails
An agent's accuracy depends on several things that can be tuned: the instructions it follows, the model it uses, the context data it receives, and the tools it can call. A generalist agent must compromise on all four. Its instructions must cover every task, so none is precise. Its model must serve every task, so none is optimal. Its context must hold data for every task, so none is focused. Its tools must cover every task, so each invites the wrong use.
A specialist agent can be tuned on each of the four. Its instructions name one judgment. Its model is chosen for that judgment. Its context carries only the data that judgment needs, and its tools are only the ones it uses. Its behavior can then be tested against a golden reference set for that specific outcome. A generalist agent offers no such outcome to test against, and its failures are hard to attribute, because a fix to its prompt affects every path at once.
Agents cannot repair a design that was never split. Placing an agent into a mixed workflow asks it to handle both predictable and unpredictable work, and no improvement in the model changes that. The split has to come first.
Why splitting is the design
The Repenning argument supplies the principle. In an MIT Sloan Management Review article, Nelson Repenning, Don Kieffer, and James Repenning argue that work should be designed so that its well-defined and ambiguous parts are separated and handled in the way each requires. Stable work suits a serial, factory-style design, and ambiguous work suits a collaborative, studio-style design. Forcing both into one process means it must be efficient and adaptive at once, and it ends up being neither.
Their practical advice maps directly onto component design. Separate well-defined work from ambiguous work. Keep units small enough to check often. Know who helps when something fails. Build explicit triggers and checks between the modes. Each is an argument for splitting rather than merging, in the workflow and in the agent that serves it.
Splitting also makes change cheaper and failure visible. A new exception can be added to one unit without retesting the rest. A failure in a specialist belongs to a named unit with its own owner and escalation path, instead of appearing as a vague problem in the whole process.
How this looks in Pega
Pega's case management model supports the split at the castype level. A parent case owns the outcome and coordinates. Child cases each cover one unit of work with their own stages and rules, and the parent can close only when they are resolved. Exceptions are handled by alternate stages, reached through a defined condition or user action rather than by additions to the normal path.
The parent-to-child handoff uses the Create Case shape, which can create one child, or one child per entry in a page list. The parent can then hold with a Wait shape until the child resolves, using the case dependency option. A child counts as resolved when its status starts with "Resolved." Data passing deserves care: the Create Case shape supports a data transform for initial values, but community reports suggest the source page parameter field may not appear in every release, so pass only what the child needs and confirm the mechanism for your version.
Agents attach to these units at specific steps. Pega's Agent Step runs inside a case type and performs one defined action asynchronously, so the case keeps moving. A GenAI Connect rule suits a single fixed action, while an Agent Step suits a judgment task. Either way, the agent is a specialist inside a workflow that already has a trigger in front of it and a check after it.
What to avoid
Three patterns recur.
- The first is one case type that holds every variant of a request.
- The second is one generalist agent given all the tools and a broad brief.
- The third is an exception handled by a workaround in the normal path, which hides it from both the design and the people who must review it.
Each has a split as its remedy: a separate case type or child for each distinct kind of work, a specialist agent for each distinct judgment, and an alternate stage for each distinct exception.
Where to start
Take one existing case type and list its variants. Separate the variants that rules can decide from those that need judgment. Give each group its own case type or child case. For each judgment group, define the one task the agent performs, the data it may see, the tools it may call, and the field where its output lands. Then define the exception routes as alternate stages with named triggers.
Only after that split should you ask whether an agent is needed, and where. In most workflows, the answer is yes for a smaller share of the work than the original design implied, and the parts that remain are easier to build, test, and govern.
The people who don't get it treat the workflow, and the agent that serves it, as one thing to build. Both are several things with different properties, and the architecture should reflect that.
References
Nelson P. Repenning, Don Kieffer, and James Repenning, "A New Approach to Designing Work," MIT Sloan Management Review, sloanreview.mit.edu/article/a-new-approach-to-designing-work/. 2018 A New Approach to Designing Work
AI Use / Disclosure: This work represents my own ideas, objectives, expertise, and professional judgment. The underlying ideas, analysis, and final conclusions were developed and validated by me. Generative AI tools were solely used as an editorial aid to to assist with language refinement, formatting, style, structural improvements and image generation.