Coworker Is An Implementation, Not A Feature
08 Nov 2026 » AI
This is my first attempt at a guest post. My coworker Tom Solarek has sent me not one, but three posts, which compose a series that I will share over the coming weeks. I hope you enjoy the first one as much as I did. All credit goes to him. Thanks Tom!
When I first started designing use cases for Adobe CX Enterprise Coworker, I was probably a little too sold on the magic. The dream and vision we are all sold is something like “Describe the task, connect the right tools, and let the agent do the work.” I knew there would be implementation effort, but I underestimated how much of it would involve understanding the work itself.
Once I got into the design, my confidence swung in the other direction. I started prescribing behavior and building components before I had properly tested what Coworker could already handle. I ended up with more machinery than the use case needed. Working back from that taught me quite a bit about where to spend the effort.
The Work Behind the Request
Consider a request like this: create a performance report for a product using the approved template.
Someone who does this every week might not even think of it as a process. They know which template is approved, which product names are interchangeable, which metric the business uses, and which parts of the report should stay untouched.
Now imagine explaining the task to someone who has access to the tools but none of that background. Which template? What does performance mean? Is this a new report or an update? Can they change the original?
Much of the implementation involves getting that background out of people’s heads and into a form the agent can use. We need to agree on the business definitions and the expected result before we can judge whether the agent did the job correctly.
Start Smaller Than the Ambition
A goal like “improve our marketing performance” may be where we ultimately want to go, but it does not give us much to design against. “Prepare this recurring report using these definitions without changing the original template” gives us a much better place to start.
When starting with CX Coworker use cases, I would start with work people already repeat. Ask someone to walk through a real example, including the preparation and checking they might otherwise skip over. When they say “normally” or “we always use this one,” ask why. That explanation may contain a requirement nobody has documented and importantly, something that needs to become a building block (Skill files, Business Context, etc.) for the agentic harness.
Another piece of advice is to encode different distinct areas of the process separately, if possible, rather than having one, giant, end-to-end solution design. For example, if the task is to prepare a report, producing it should not depend on the agent subsequently running additional analyses. We can add those once the core process works and the user (and Coworker) can chain them together in intelligent fashion during their conversation if they would like.
Creating a process map helps, although I would expect to change it as we learn. We may discover that Coworker already handles a step we planned to build, that a business definition needs clarification, or that one use case should really be two.
I would approach the design itself the same way. Start with a small scope and appropriate guardrails, try it, and adjust based on what happens (especially using Coworker itself to help with this). I would not expect the first version to be right, especially while we are still learning how best to design these agentic processes. Keeping changes small and reversible gives us room to experiment without putting the original report or other important assets at risk. We can use that flexibility to test an idea before investing too much in it, then keep, revise, or remove it based on the results.
Use What is Already There
My over-engineering came partly from doubting that Coworker could handle the mechanics. In the use cases I worked on, available tools could already perform actions I had started designing around. I should have tested those first.
I have started to think about the design as a Swiss cheese model. Coworker may handle most of a process well without much help, but there will be holes. The job is to find the holes that matter and decide what, if anything, needs to cover them.
The holes will be different for each use case. Does Coworker understand what the user means in the context of this business? Is it using the right source? What happens when two objects look like a match? After it takes an action, can we verify that the intended change really happened?
Testing those questions tells us where the solution design needs to do more. Maybe Coworker needs additional business context to resolve the right product or template. That might belong in a knowledge file. Maybe we want a stricter check before it changes something. That could belong in a skill or another control. Sometimes testing shows that Coworker already handles something well enough and we do not need to add anything.
It is better to start with the native behavior and patch the important gaps than design every step from scratch. “Use what is available” does not mean “trust whatever happens.” It means spending the implementation effort where Coworker actually needs help.
For the report example, I would want the user to see the selected template and proposed scope before a consequential change. Afterward, the implementation should verify the saved result. Those are relatively small additions around something Coworker may already handle well, but they cover gaps where a wrong choice would matter.
This also gives us a useful check against over-engineering. Every skill, knowledge file, rule, or control we add becomes something that someone will eventually have to understand and maintain. If we cannot point to the hole it is covering, we should probably question whether we need it.
Someone has to Maintain it
One of the easiest ways to over-engineer an agentic solution is to design only for the first version. AI makes it relatively easy to create more skills, instructions, reference files, and rules. Each addition may make sense on its own, but eventually the design becomes difficult to understand and even harder to safely change.
Designing for maintenance forces some useful discipline. Sometimes the best step is no step at all. If Coworker already handles something well enough, adding another layer may create more work without making the outcome meaningfully better.
Complexity also makes the solution fragile. Business definitions change. Product names change. Skills and knowledge files get updated. If nobody can easily understand how those pieces fit together, they will eventually drift apart, and something will break.
I would settle those questions during design. The business should be able to maintain its definitions without tracing references through a dozen files, and the technical owner should know which tests to run after a change.
There will still be maintenance. I would rather make that work manageable than hand over a design that depends on its original author being available.
Reset the Expectation
Coworker is not set-and-forget automation. It is also not merely prompt engineering. It is a solution made from reasoning, context, tools, controls, and operating practices.
The architect still has to define the outcome and decide how much freedom the agent should have. We need to make assumptions visible and provide checks where a wrong choice would matter. When designing, think about “I want enough structure that someone can use the result with confidence, without recreating every manual step in instructions.”
In my next post, I will look at that trade-off more closely: what to hard-code, what to leave flexible, and how I think about the reliability budget between them.