You Don’t Need 59 AI Tools. You Need 6 Capabilities.

AILeave a comment

Why Claude’s examples show how AI really works in organisations

Most organizations waste resources building the same AI capabilities multiple times because they organize adoption by department instead of by underlying capability.

Fifty-nine use cases. Six organizational capabilities. One structural misunderstanding.

Right now, 95% of enterprise AI pilots are failing. Not because the technology doesn’t work, but because organizations keep rebuilding the same intelligence six different ways. Each department starts from scratch, with each pilot costing $500K to $2M.​

Anthropic’s Claude use-case library contains fifty-nine examples, spanning HR, Legal, Sales, Marketing, Finance, Research, Operations, Education, Personal productivity, and specialized scientific workflows.

At first glance, it reinforces a familiar belief:

Each department needs its own AI use cases.

Legal reviews contracts.
Sales prepares deals.
HR builds onboarding guides.
Marketing analyses campaigns.

Different departments.
Different labels.
Different tools.

But when you step back and read the entire library as a whole, a different picture emerges.

The use cases are not different kinds of work.
They are different departmental expressions of the same underlying capabilities.

Reframing the question

Most AI conversations start with:
“Where can we use AI?”

A more useful question is:
“What shared capabilities are being exercised across the organisation?”

Claude’s use-case library is useful precisely because it makes this visible, if you stop reading it department-by-department and start reading it capability-by-capability.

This analysis focuses on the six organizational capabilities where departments repeatedly rebuild the same infrastructure. Personal productivity tools (Capability 8), interactive artifact builders (Capability 7), and domain-specific scientific workflows (Capability 9) follow similar patterns but operate in different contexts.

Capability 1: Interpretation & normalisation

(Making fragmented information usable for decisions)

This capability appears wherever people must pull information from multiple sources, reconcile it, and explain what it means.

Appears in multiple departments

Finance: pulling metrics from dashboards
Marketing: analysing campaign performance
Sales: generating sales reports
Research: verifying statistics from raw data
Nonprofits: analysing fundraising performance

These are not different problems. They represent the same interpretive task applied to different data sources.

Shared infrastructure required

Data layer: Secure connectors to systems of record, common metadata standards, consistent transformation rules
Governance layer: Audit trails for data lineage, role-based access to source systems, data quality thresholds
Output layer: Standardised reporting templates, citation to source records, explanation of reconciliation logic

Without shared infrastructure here, Finance and Marketing both pay vendors to build the same extraction and normalisation capabilities twice.

Capability 2: Document intelligence

(Reading, comparing, and structuring long-form material at scale)

This capability shows up anywhere documents must be reviewed, compared, or transformed.

Appears in multiple departments

Legal: contract redlining and negotiation
Compliance: discovery timeline analysis
Research: literature reviews
Procurement: comparing competing proposals
Operations: process flowcharts and SOPs

The documents differ. The cognitive work (extract, compare, flag discrepancies) remains constant.

Shared infrastructure required

Ingestion layer: Document parsing (PDF, DOCX, scanned images), chunking and vectorization strategies, OCR and table extraction
Classification layer: Metadata tagging standards, document taxonomy, version and lineage tracking
Retrieval layer: Semantic search infrastructure, source citation mechanisms, access controls and retention policies

This is not “AI for Legal.” It is document intelligence infrastructure that Legal, Procurement, and Compliance all use, with domain-specific customization layered on top.

Capability 3: Structured drafting with institutional standards

(Producing aligned drafts without constant rework)

This capability generates content that must conform to brand, legal, or operational rules.

Appears in multiple departments

HR: new hire onboarding guides
Sales: proposal presentations
Compliance: AI policies
Marketing: brand assets and adapted content
Education: custom course materials

Each department believes its drafting needs are unique. The underlying task (generate text that complies with institutional standards) is identical.

Shared infrastructure required

Standards repository: Brand guidelines, legal language, approved tone banks, regulatory templates
Prompt infrastructure: Reusable prompt templates with variable slots, few-shot examples for consistency, output validation rules
Review workflows: Version control and approval gates, deviation flagging, feedback loops for continuous improvement

When Marketing and HR both procure separate “AI writing tools,” they’re paying twice for the same generation capability with different style guides bolted on.

Capability 4: Knowledge reuse & synthesis

(Reconnecting institutional memory)

This capability prevents reinvention by surfacing and reusing what already exists.

Appears in multiple departments

Communications: company newsletters
Nonprofits: impact reports and program toolkits
Sales: battle-card libraries
Research: synthesised notes and literature
Personal productivity: research captured on the move

Organizations don’t have a content creation problem. They have a memory reconstruction problem.

Shared infrastructure required

Knowledge architecture: Central repositories with consistent schemas, tagging and taxonomy standards, federated search across siloed systems
Permissions framework: Role-based access to sensitive material, time-based content lifecycle rules, source attribution requirements
Retrieval logic: Context-aware search (not just keywords), recency weighting and relevance scoring, cross-functional knowledge graphs

Without this, Sales rebuilds competitor research that Marketing already completed. Research re-summarizes literature HR already synthesized. Expensive redundancy masquerading as productivity.

Capability 5: Dialogue & interaction

(Customer-facing and internal assistance through conversation)

This capability is notably absent from Claude’s use-case library, but it represents one of the most common enterprise AI applications.​

Structured conversations (customer support, internal help desks, guided workflows) where AI responds dynamically to user questions appear across organizations:

Appears in multiple departments

Customer service: 24/7 support chatbots and ticket routing
HR: onboarding assistance and policy Q&A
IT: internal help desk and troubleshooting
Sales: lead qualification and product recommendations

Different audiences. Same conversational infrastructure.

Shared infrastructure required

Dialogue management: Intent recognition and entity extraction, context maintenance across turns, escalation logic to human agents
Integration layer: Real-time connections to CRM, ticketing, and knowledge systems, streaming response handling, session state management
Governance layer: Conversation logs and compliance monitoring, response quality assurance, human-in-the-loop handoff protocols

A healthcare provider and a bank both need appointment scheduling bots. The underlying capability (conversational workflow automation) is identical. Only the domain vocabulary and backend integrations differ.​

Why the omission matters: Claude’s library focuses on asynchronous knowledge work (documents, reports, drafts). Conversational AI requires different technical patterns (real-time response, session state, multi-turn context), but the organizational principle remains the same. Build the capability once. Reuse it across departments.

Capability 6: Workflow orchestration & coordination

(Making work flow across systems and time)

This capability connects systems, creates trackers, generates status updates, and orchestrates routine preparation tasks.

Appears in multiple departments

Executive: preparing from calendar and weekly planning
Operations: project status reports
Events: turning emails into event trackers
Sales: deal preparation and CRM logging
IT: file organization and email cleanup

Shared infrastructure required

Integration layer: Authenticated connections to calendar, email, drive, CRM systems
Scheduling logic: Recurring workflow triggers, time-based automation
State management: Tracking what changed since last run, incremental updates
Output formatting: Consistent templates for status rollups and coordination artifacts

This differs from other capabilities because it’s time-based and stateful. The AI doesn’t just respond to requests, it monitors systems and proactively surfaces what needs attention.

Cross-cutting requirement: Evaluation, review & control

(Human-in-the-loop by design)

This is not a standalone capability. It is a governance principle that must apply to all five capabilities above.

Claude’s use cases repeatedly assume review, not autonomy:

Sales: CRM logs drafted for approval
IT / Ops: files flagged before deletion
Legal: contract changes proposed, not executed
Marketing: email cleanup with human confirmation

Infrastructure for accountability

Approval gates: Role-based review workflows
Audit infrastructure: Action logs with timestamps and user attribution
Exception handling: Clear escalation paths when AI confidence is low
Feedback loops: Human corrections that improve future outputs

AI that bypasses accountability does not scale. Organizations building reusable capabilities must bake review mechanisms into the architecture, not retrofit them later.​

What this changes in practice

Once you see capabilities instead of use cases, four things shift:

1. Departments become contexts, not silos

Before: Legal buys a “Legal AI tool.” Marketing buys a “Marketing AI tool.” Both tools contain document analysis, both integrate with cloud storage, both require data governance.

After: Legal and Marketing both use the organization’s Document Intelligence capability. Legal applies it to contracts with legal review workflows. Marketing applies it to campaign briefs with brand compliance checks. One infrastructure. Two contexts.

2. Governance becomes shared, not bolted on

Before: Each department pilot addresses data privacy, access controls, and audit logging independently. Compliance reviews each pilot separately. Six pilots = six compliance reviews.

After: Governance requirements are defined once at the capability level. When a new department wants to use Interpretation & Normalisation, they inherit access controls, audit infrastructure, and data lineage standards. One governance framework. Six implementations.

3. Data standards become central, not local

Before: Finance defines “revenue” one way. Sales defines it another. Marketing uses a third. AI tools produce conflicting answers depending on which system they query.

After: The organization defines canonical data entities at the capability level. When Finance and Sales both use Interpretation & Normalisation, they query the same standardised sources, even if they generate different reports.

4. Tools become replaceable, not strategic

Before: “We’re an [Vendor X] shop.” Tool selection becomes an identity. Switching costs escalate. Negotiating leverage disappears.

After: “We build Document Intelligence as a capability. Currently, we use [Vendor X], but our architecture isn’t coupled to their API.” Tools become implementation details, not strategic dependencies.

Acknowledging the objection

“But Legal contracts are fundamentally different from HR onboarding guides.”

Yes. And that’s precisely the point.

This framework does not claim all AI work is identical. It distinguishes between:

  • Shared capabilities (document intelligence, knowledge synthesis) that should be standardized across the organization

  • Domain-specific customization (legal review criteria, HR policy compliance) that happens on top of shared infrastructure

The mistake is building six separate “document intelligence” systems because Legal, Compliance, and Procurement each believe their documents are too unique to share infrastructure.

They are unique in content. Not in the cognitive operations required to process them.

The question that matters

Stop asking:
“Where can we use AI?”

Start asking:
“What shared capabilities should we build once and reuse everywhere?”

Claude’s use-case library doesn’t answer that question directly. But it makes the answer visible, if you read it the right way.

Audit your current AI pilots. Which ones are attempting to solve the same underlying problem with different tools? That’s where consolidation creates value.

This post uses Claude’s public use-case library as primary evidence. The capability framework includes conversational AI (a notable omission from Claude’s library) to present a complete view of organizational AI patterns. The analysis applies broadly, regardless of vendor or platform.

Appendix: All Claude Use Cases Grouped by Capability (59 URLs)

Capability 1: Interpretation & Normalisation

(Turn scattered information into decision-ready summaries)

Capability 2: Document Intelligence

(Read, extract, compare, structure long-form documents)

Capability 3: Structured Drafting With Standards

(Draft outputs aligned to institutional voice and policies)

Capability 4: Knowledge Reuse & Synthesis

(Reconnect institutional memory)

Capability 5: Dialogue & Interaction

Note: This capability does not appear in Claude’s use case library, despite being one of the most common enterprise AI applications. Examples would include customer service chatbots, internal help desk automation, HR policy Q&A systems, and sales qualification assistants.​

Capability 6: Workflow Orchestration & Coordination

(Connect systems, create trackers, prep routines)

Capability 7: Build Interactive Tools & Artefacts

(Generate working interactive tools/apps/sites)

Capability 8: Personal Utility & Lifestyle Planning

(Personal planning, learning, travel, health)

Capability 9 — Science & Bioinformatics Analysis

(Specialised analytical workflows; domain-heavy, but still capability-driven)

(Note: “Create health and exercise notes” appears here as well conceptually; in the appendix it’s listed under Personal Utility to keep one primary bucket.)

Daniel Kerson
Daniel T Kerson
AI consultant. Writer. Builder. Based in Singapore for 20 years. He runs three projects at the intersection of technology, language, and creativity.
AngMohDan
Language, culture, and ideas
Musical Brick
LEGO music legends
Kerson AI
AI literacy and tools

KersonAI

View posts by KersonAI

Related Posts

  1. The Chip I Didn’t Need, and the Road to AI

    August 31, 2026

  2. The Top 10 Skynet Stories of August 2026

    August 29, 2026

  3. A PDF Is Not a Document

    August 19, 2026

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top