Designing Connected Workflows

What You Need to Know

Everything in Domain 3 converges here. You understand Skills (internal logic), Connectors (external data access), and Plugins (the bundles). Now you need to chain them together into workflows that solve real business problems — pulling data from one service, processing it through your custom logic, and pushing the result to another service, all from a single prompt.

Connected workflows are where Cowork stops being a clever chatbot and starts being a genuine productivity tool. But they are also where most people make their worst mistakes: over-engineering with too many components, ignoring token budget constraints, or building monolithic skills that try to do everything at once.

The Connector-Logic-Connector pattern

The most reliable workflow architecture follows a three-stage pattern:

1. Connector IN — fetch raw data from an external service (Salesforce pipeline data, Jira tickets, Google Drive documents)
2. Logic — Claude's reasoning engine processes the data, guided by a custom Skill that applies your specific rules (risk scoring, brand formatting, priority classification)
3. Connector OUT — push the finished result to an external destination (Slack channel, email, shared drive, project management tool)

This is the "CLC" pattern, and it maps directly to how effective delegation works in any organisation: someone gathers the raw information, someone else analyses it according to established criteria, and the result gets delivered to the right people.

Not every workflow needs all three stages. Some workflows only fetch and process (Connector IN → Logic), producing a result that stays in the Cowork conversation. Others only process and deliver (Logic → Connector OUT), working with data from your local working folder. But the full CLC pattern is what the exam tests most heavily because it exercises every component of the ecosystem.

Tool priority hierarchy

When Claude encounters a multi-step task, it follows a natural selection hierarchy:

1. Check for a relevant Connector — if the task involves external data, Claude looks for an installed, authenticated Connector first
2. Apply a relevant Skill — if processing logic is needed, Claude searches for a matching Skill via progressive disclosure
3. Fall back to native capabilities — if no Connector or Skill matches, Claude uses its built-in reasoning and file-processing capabilities

This hierarchy matters because it determines the order of operations. Claude doesn't randomly choose between tools. It prioritises real-time data from Connectors over static context, and specialised Skill logic over generic reasoning. Understanding this hierarchy helps you predict how Claude will handle ambiguous requests — and helps you write prompts that guide it to the right tools.

Token budget management

Every component in a connected workflow consumes tokens from your context budget:

• Connector tool definitions — each installed Connector adds its schema to the context, even when not actively in use
• Skill instructions — loaded via progressive disclosure only when triggered, but still consuming tokens when active
• Retrieved data — the raw data a Connector fetches occupies context space
• Claude's reasoning — the analysis and synthesis step needs room to work

A workflow with 10 Connectors, 5 loaded Skills, and a large dataset fetched from Salesforce may leave Claude with insufficient context for quality reasoning. The result: degraded output, truncated analysis, or dropped steps.

Tool-call batching for performance

The MCP specification supports sending multiple tool requests in a single protocol call. If your workflow needs data from Salesforce and Jira simultaneously, batching sends both requests together rather than waiting for one to complete before starting the other.

Think of it as ordering your starter and main course at the same time instead of waiting for the starter to arrive before ordering the main. The Streamable HTTP transport in the MCP 2025-03-26 specification makes this particularly efficient for workflows that pull from multiple sources.

You don't need to configure batching manually — Claude handles it when it identifies independent data requests. But understanding that it exists helps you design workflows where data retrieval steps are independent (and therefore batchable) rather than sequential (which forces one-at-a-time execution).

Designing for single responsibility

The most common architectural mistake in connected workflows is building one massive skill that tries to handle data retrieval, analysis, formatting, and distribution in a single file. This monolithic approach creates several problems:

• Hard to debug — when something fails, you can't isolate which step broke
• Hard to reuse — the skill is so specific to one workflow that no other task can use it
• Wasteful — the entire skill loads into context even when you only need one of its functions
• Fragile — a change to one step risks breaking unrelated steps

The better architecture: small, specialised components that chain together. A data-cleaning Skill. A risk-scoring Skill. A brand-formatting Skill. Each does one job well, and you assemble them into different workflows as needed. The Connectors handle data in and data out. Claude's reasoning engine orchestrates the flow.

A complete workflow example

Consider this real-world scenario: you need to fetch a customer's support history from a database, summarise their last three complaints using your company's tone guidelines, and post the summary to a private Slack channel.

Poor design: One massive skill that somehow handles database queries, text summarisation, and Slack posting.

Correct design:

1. SQL MCP Connector fetches the customer's support tickets from the database
2. Claude's reasoning identifies the three most recent complaints and analyses their themes
3. Company Tone Skill applies your organisation's specific communication guidelines to the summary
4. Slack MCP Connector posts the finished summary to the designated channel

Each component does one job. If the tone guidelines change, you update one Skill. If you switch from SQL to a different database, you swap one Connector. If you want the summary emailed instead of Slacked, you change the output Connector. The processing logic in the middle doesn't change.

Writing effective multi-step prompts

A connected workflow is only as good as the prompt that triggers it. Vague prompts force Claude to guess which tools to use, which data to fetch, and what format to produce. Specific prompts name the tools, define the data scope, and describe the expected output.

The structure that works consistently:

1. Name the data source — "Using the Jira Connector, fetch..."
2. Define the filter — "...all P1 tickets from the last 14 days"
3. Specify the processing — "Apply the Triage Skill to categorise by component and severity"
4. Describe the output — "Post a summary to #engineering-leads with the top 3 issues and recommended actions"

One prompt. Four clear instructions. Every component named. No ambiguity.

---

Common Mistakes

---

Hands-On Activity

---

Practice Question

---

Sources

• Cowork: Claude Code power for knowledge work — Anthropic
• Claude Cowork Guide 2026: Skills, Plugins, Connectors — FindSkill.ai
• Use plugins in Cowork — Anthropic
• Let Claude use your computer in Cowork — Anthropic