Your AI Strategy Needs Jobs To Be Done, Not a Thousand Agents

TL;DR

• Most agent roadmaps start with capability: "What can the model do?" Stronger roadmaps start with work: "What job needs to get done?"
• Jobs To Be Done gives product teams a practical map for deciding where agents belong, where workflows are enough, and where humans should stay in control
• The best agent strategy is not a collection of bots. It is a ranked system of customer and business jobs with clear inputs, outputs, tolerances, and escalation paths

---

Your AI strategy does not need more agents. It needs a sharper map of the work.

Too many teams start with the model and work backwards. They see tool use, memory, voice, browsing, code execution, and orchestration, then ask where they can attach an agent. That is how companies end up with demo gardens: impressive, scattered, and commercially weak.

Start with Jobs To Be Done instead.

The Christensen Institute defines Jobs To Be Done as a lens for understanding the progress people are trying to make in a specific circumstance. People do not simply buy products. They hire them to make progress.

The same is true for agents.

Users do not want an "AI assistant". They want the booking fixed, the invoice reconciled, the customer replied to, the claim triaged, the campaign launched, the defect explained, the lead qualified, or the report sent without spending Friday afternoon in a spreadsheet.

This is not theory for me. In OpenChair, the useful AI work was never "build a salon agent". It was recover missed bookings, answer calls after hours, draft the customer message, route the deposit exception, and keep the operator out of repetitive admin.

If you cannot name the job, you have no business building the agent.

Capability-first agent strategy creates clutter

Capability-first thinking sounds practical at first.

"The model can search the knowledge base. Let's build a support agent."

"The model can call tools. Let's build an operations agent."

"The model can write copy. Let's build a marketing agent."

This creates broad agents with vague accountability. They sit beside the real workflow, waiting for someone to summon them. Users try them once, get a mixed result, and quietly return to the toolchain that already works.

That is not adoption. It is novelty decay.

I have written before that enterprise AI adoption fails at the harness, not the model. The same pattern shows up in agent work. Capability is abundant. Context is scarce. Workflow fit is the hard part.

A Jobs To Be Done map forces the useful questions early:

• Who is hiring this workflow?
• What progress are they trying to make?
• What triggers the job?
• What input does the workflow need?
• What output proves the job is done?
• What failure would destroy trust?
• Where does a human need to approve, correct, or override?

Those questions are dull. They are also where agent strategy becomes product strategy.

Workflows before agents

Anthropic's guidance on building effective agents makes a useful distinction: workflows follow predefined code paths, while agents dynamically direct their own process and tool use. Anthropic also recommends starting with the simplest solution possible and increasing complexity only when needed.

That should be printed on the wall of every AI roadmap meeting.

Most business jobs do not need autonomous agents. They need structured workflows with one or two model calls inside them.

Invoice matching does not need an agent personality. It needs extraction, comparison, exception detection, and a queue for ambiguous cases.

Lead qualification does not need a chatbot. It needs enrichment, scoring, routing, and a clean reason attached to the decision.

Customer recovery does not need a "relationship agent". It needs a trigger, account context, offer rules, tone constraints, approval thresholds, and measurement against retention.

Autonomy is a cost. It adds latency, variability, observability burden, and new failure modes. Pay that cost only when the job genuinely requires dynamic planning.

OpenAI's Agents SDK documentation shows the serious end of the stack: orchestration, tools, guardrails, human review, integrations, observability, and workflow evaluation. That is not a toy surface. It is application infrastructure.

If your use case cannot justify that infrastructure, you may not need an agent. You may need one well-placed model call inside a boring workflow.

A practical AI jobs map

A good AI jobs map has four layers.

Customer jobs. These are the jobs users hire your product to do. "Help me recover missed bookings." "Help me understand which property risk matters." "Help me keep my team compliant without reading every policy update."

Operator jobs. These are the internal jobs your team performs to deliver the product. Support triage, onboarding review, data cleanup, billing exceptions, campaign QA, fraud checks, renewal prep.

Decision jobs. These are moments where judgment matters. Prioritising a roadmap, approving a refund, changing a price, marking a lead as high-intent, escalating a complaint. AI can prepare the decision. It should not always make it.

Control jobs. These keep the system honest. Evals, audit trails, permission checks, cost monitoring, model routing, incident review. Weak AI strategies forget this layer until something breaks.

Once the jobs are visible, rank them by four criteria:

• Volume: how often does this job occur?
• Pain: how much time, money, or frustration does it create?
• Tolerance: how much error can the workflow absorb?
• Data readiness: do we have the inputs needed to do this well?

High-volume, high-pain, high-tolerance, high-data jobs go first. Low-tolerance decision jobs wait until the control system is stronger.

That is how you avoid building a thousand agents nobody trusts.

The unit of strategy is the job, not the bot

Bot-centric roadmaps age badly.

You launch a support bot, sales bot, finance bot, onboarding bot, and manager bot. Six months later, nobody knows which bot owns which step. The bots overlap. They answer differently. Users learn to route around them because the mental model is worse than the original workflow.

Job-centric roadmaps scale better because the ownership is tied to work, not interface.

"Resolve a missed appointment" might involve SMS, calendar access, pricing rules, staff availability, customer history, and a payment link. Whether the user experiences that as a button, voice call, chat thread, automation rule, or background agent is secondary.

The job is stable. The interface can change.

This matters because AI interfaces are still shifting. Chat is overused. Voice is improving. Background agents are becoming plausible. Generative UI will change how users inspect and correct outputs. If your strategy is "we need a chat agent", you are anchoring on a temporary interface.

Anchor on the job.

Product leaders need an agent portfolio

An agent portfolio should look more like a risk-adjusted investment book than a feature list.

Each candidate job needs a short operating brief:

• Job statement: the progress the user or business needs
• Current workflow: tools, handoffs, delays, failure points
• Proposed AI role: draft, classify, retrieve, decide, execute, monitor, or escalate
• Autonomy level: copilot, reviewed autopilot, bounded autopilot, or full autopilot
• Quality bar: acceptable accuracy, latency, cost, and refusal behaviour
• Control design: evals, traces, approvals, permissions, and rollback
• Business metric: time saved, conversion lift, retention, cost reduction, risk reduction

This is not bureaucracy. It is how you stop AI work from becoming a pile of disconnected experiments.

It also gives executives a better conversation. Instead of asking "How many agents have we launched?", they can ask "Which jobs have we materially improved, and what risk did we take on to do it?"

That is a healthier metric.

Stop naming agents before naming work

Names are seductive. They make half-built ideas feel real.

The moment a team names the agent, the product thinking often gets worse. The conversation shifts to personality, interface, and launch theatre. The harder questions get deferred.

Can it complete the job?

Can we measure completion?

What happens when it is unsure?

Which system of record does it trust?

Who owns the exception queue?

What does it cost per successful outcome?

Where does the user inspect the reasoning?

If those questions do not have answers, the agent does not need a name. It needs a job map.

AI product management in 2026 is not about sprinkling agents across the org chart. It is about decomposing the business into jobs, deciding which jobs deserve automation, and designing the control system around them.

Do that well and agents become useful infrastructure.

Skip it and you get bots with names, demos with applause, and workflows nobody changes.

---

Frequently Asked Questions

What is an AI jobs map?

An AI jobs map is a ranked list of customer, operator, decision, and control jobs that AI could improve. It connects each workflow to a business outcome, quality bar, autonomy level, and control design.

When should a team build an agent instead of a workflow?

Build an agent when the job requires dynamic planning, tool selection, and adaptation across changing conditions. Use a workflow when the path is known, the steps are predictable, and reliability matters more than flexibility.

Why use Jobs To Be Done for AI strategy?

Jobs To Be Done keeps teams focused on progress, not novelty. It helps product leaders choose where AI belongs, what success looks like, and which parts of the workflow should remain human-controlled.