Hire a Capability to Get the Job Done

Ask an account manager what they need, and they won’t say “the CRM contract endpoint and the health score table.” They’ll say: “Tell me whether Acme is ready to renew, and what’s in the way.”

That sentence is a job. The endpoint and the table are parts of one possible solution. Enterprise integration has spent twenty years building and managing the parts. Agents are now asked to get the job done, so we need a clear way to connect the two.

Jobs to be Done (JTBD) provides it. A job is demand: why the work happens. A business capability is supply: what the business offers to get the job done. In The Capability Is the Product we argued the capability is what you manage. This post is about who it’s for, and how you know it works.

A job is demand; a capability is supply

Clayton Christensen defined a job as the progress a person is trying to make in a particular circumstance. People “hire” a product to make that progress, and “fire” it when something does better. The job says nothing about the solution, the systems behind it or the team that built them.

A business capability sits on the other side of that hiring contract. In an Ikanos spec, it is a declared, executable unit with three parts:

• consumes takes on the enterprise sprawl: HTTP APIs behind the gateway, MCP servers in front of data platforms, credentials and format conversion.
• aggregates defines the business function once: its steps, mappings and semantics.
• exposes offers it in the shape each consumer needs: MCP tools for agents, REST for apps and Skills for discovery.

The job defines why the call happens. The capability is what gets called. Keep them apart and both get clearer: the job stays in the customer’s words, and the capability takes care of the plumbing.

The agent is a contractor, not the customer

Agents complicate the hiring picture. The account manager owns the job, and the agent does the work for them. JTBD has a word for this split: the job executor isn’t always the job beneficiary.

So think of the agent as a contractor. The person who owns the job hires it, and it hires capabilities as subcontractors to get the job done. That has two consequences:

• The capability has to be legible to the contractor. An agent picks tools from a list by reading their descriptions. A business name, typed inputs, right-sized outputs and declared semantics (safe, idempotent, destructive) let it choose without guessing.
• The capability has to answer to the owner. The spec names its owner in info.stakeholders, and every upstream call is visible in consumes. Whoever owns the job can see exactly what was hired on their behalf.

Jobs persist, so capabilities should too

A core tenet of JTBD is that jobs last while solutions change. People needed to “know whether a customer will renew” long before CRMs existed. That makes the job a good anchor for a capability.

A process is a path: how one team wired the flow this quarter. A capability is a place you can stand: a business function that holds up however the workflows around it change. Agents don’t want to replay a hard-wired path. They compose capabilities at runtime to get whatever job they’ve been given done.

If you anchor capabilities to jobs, they stay stable as processes, platforms and agents change around them. If you anchor them to systems, they change every time a system does.

The capability absorbs the coordination tax

Renewal readiness touches three places:

• The contract date lives in the CRM, behind the API gateway.
• Account health lives in a customer 360 data product on the data platform.
• Usage against entitlements lives in an internal service.

Without a capability, the consumer pays a coordination tax. It has to call three platforms, reconcile three formats, handle three authentication schemes, and know which field means what. For an agent, that tax shows up as context-window tokens, wrong-tool guesses and retries.

A capability shaped around the job pays that tax once, at design time. consumes reaches the three sources, aggregates joins them into one answer, and exposes offers one tool: Renewal Readiness. The consumer makes one call for the whole job.

On the left, the agent coordinates three platforms itself, on every run. On the right, the capability does that work once, and the agent makes one call.

Measure the capability by the job’s outcomes

Platform product management measures the asset each platform hosts. API products track calls, latency and keys. Data products track freshness, queries and schema versions. None of those numbers tells you whether the account manager is better off.

JTBD has a sharper tool: desired outcome statements. Tony Ulwick’s format is a direction, a metric and the object being controlled, with no solution named:

• Minimize the time it takes to know whether an account is at risk before renewal.
• Minimize the likelihood of missing a blocker that delays the renewal.
• Minimize the number of systems I have to check to answer the question.

Those are the measures for a capability manager: the owner who manages a business capability as a product. The capability is doing its job when those outcomes improve, for the people who call it directly and for the agents working on their behalf. The gateway, the lakehouse and the service catalog remain what they are: the supply chain behind it.

Agents make this harder and more necessary. As we wrote in Designing Agent Experience Outside-In, a confused agent doesn’t complain. It retries, guesses and bills you. You can’t wait for feedback, so write the outcomes down first and measure against them.

So start your next capability from the job, not the swimlane or the API catalog. Write one job story (When…, I want to…, so I can…) and two or three outcome statements. consumes, aggregates and exposes then follow from what the job needs.

The takeaway

• A job is demand: why the work happens. A capability is supply: what gets hired to do it.
• Agents are contractors. They work for the person who owns the job, and they hire capabilities to get it done.
• Jobs persist, so anchor capabilities to jobs, not to processes or systems.
• A capability shaped around the job absorbs the coordination tax once, for every consumer.
• Measure capabilities by the job’s outcome statements, not by calls or freshness.

Further reading

• 📄 Know Your Customers’ “Jobs to Be Done” (Christensen, Hall, Dillon, Duncan, HBR)
• 📄 The Capability Is the Product
• 📄 From Business Processes to Business Capabilities
• 📄 Designing Agent Experience Outside-In, When the Consumer Can’t Complain
• ⚙️ Ikanos · 🧪 Playground · 📖 Documentation · 🎨 Polychro