The Skills Convergence: Three Problems, One Solution

The Skills Convergence: Three Problems, One Solution

November 15

Sometimes you discover you’ve been working the hard way. Not because you made bad decisions, but because you didn’t have all the information yet. That’s what happened on Saturday morning when I brought a new idea to my Chief of Staff. We had the Chief Architect analyze token usage patterns and we found something remarkable: we could reduce our most expensive operations by 98.7%.

But this isn’t a story about optimization. It’s about what happens when efficiency reveals itself as strategy, when three separate problems converge into one solution, and when an economic model emerges that funds its own transformation.

The expensive way to process documents

Saturday November 15 started at 5:39 AM with my Chief Architect investigating a question: how efficiently was Piper using Model Context Protocol (MCP)?

A few days earlier, Anthropic had published research showing something counterintuitive. When LLMs call tools through MCP, they consume tokens for every step: input, output, reasoning. But when they write code that uses those tools and then execute that code? Token savings of 98.7%. The difference is fundamental: orchestration happens in the model’s context (expensive) versus orchestration happens in code execution (cheap).

My Chief Architect looked at Piper’s actual usage patterns. We had five MCP servers active: GitHub (heavy usage), Slack (medium), Calendar (light), Notion (heavy), Serena (medium). The token-heavy pattern was immediately visible: document processing consumed ~150,000 tokens per operation.

Here’s why. When a user asks “summarize my documents from last week,” the model orchestrates a chain:

1. Call Notion MCP to list documents (3K tokens)
2. Parse results, identify relevant docs (2K tokens)
3. Call Notion MCP to fetch each document (10K tokens × 5 docs)
4. Call GitHub MCP to check related issues (5K tokens)
5. Synthesize everything into summary (8K tokens)

Total: ~65K tokens just for the tool calls. Add reasoning overhead and context management, and you’re at 150K tokens for a single document query.

[PLACEHOLDER: When you first saw these numbers, what was your reaction? Did this surprise you, or does this connect to past experiences with inefficient architectures that only revealed themselves through measurement?]

The expensive part isn’t any individual step — it’s that every step flows through the model’s context window. Each tool’s output becomes the next tool’s input, all mediated by the LLM. The model is doing secretarial work instead of thinking work.

Three tiers of tool usage

At 5:50 AM, the Chief Architect proposed a three-tier strategy:

Tier 1: Direct MCP — Keep for simple, one-shot operations under 1,000 tokens. Checking a calendar, posting a Slack message, creating a GitHub issue. These are fine. The orchestration overhead is minimal.

Tier 2: Skills MCP — NEW approach for common multi-step patterns. Instead of the model orchestrating tool calls, we encapsulate entire workflows as executable skills. The model writes code once, we execute it repeatedly.

Tier 3: Code Execution — For complex, custom workflows that don’t fit predefined patterns. The model writes fresh code, we execute it.

The key insight: LLMs are better at writing code than calling tools. Their training data is full of code. They’ve seen millions of examples of “fetch data, process it, return results.” They’re excellent at generating Python or JavaScript that accomplishes multi-step workflows.

By 6:00 AM, the Skills MCP architecture was designed:

• SkillsMCP meta-server provides executable skills to agents
• Skills encapsulate workflows: StandupToIssuesSkill, DocumentAnalysisSkill, BatchProcessingSkill
• Data stays in execution environment: No massive outputs flowing back to model
• Only summaries return: Model sees ~50 tokens of result, not 50K tokens of intermediate data

The projected savings were dramatic: 90–98% token reduction on common patterns.

When everything connects

At 7:30 AM, something interesting happened. The Chief Architect was reviewing yesterday’s UX audit findings — 350 pages documenting 68 gaps across six user journeys.

Journey 6 (Document Management) had scored 2 out of 10. The crisis was clear: users couldn’t effectively retrieve or manage documents they’d uploaded. The system stored documents but provided no good way to find them again.

The Chief Architect looked at Journey 6 and saw: DocumentAnalysisSkill.

The document management problem? Solvable with a skill that encapsulates document retrieval, filtering, and summarization.

The token efficiency problem? Solvable with Skills MCP architecture.

The UX improvement funding problem? Solvable with the resources saved from token efficiency.

Three initiatives that had seemed separate — UX transformation (my researcher estimated it as requiring $130K worth of UX work in the traditional market), Skills MCP implementation, Learning System completion — were actually one integrated transformation.

By 7:40 AM, the Chief Architect had modeled the economics:

Current state: Estimated future document processing costs ~$4,440 per month in tokens (150K tokens per query × 200 queries/day × $0.015/1K tokens)

With Skills MCP: Same operations cost ~$60 per month (token usage drops to 2K per query — just the model writing the skill execution code)

Potential monthly savings: $4,380

Potential three-month savings: $13,140

Thirteen-week transformation budget: $130K total

The math was elegant: by week 4, Skills MCP would generate enough savings to fully fund UX improvements over three months. By week 13, the transformation would have paid for itself and established a sustainable economic model. (Even without the “funny money” that drove this logic, the tradeoffs are similar!)

The virtuous cycle

The Chief Architect mapped the convergence:

Efficiency Stream (Skills MCP):

• Measure, prototype, validate
• Build core skills library
• Migrate agents to Skills
• Dynamic skill generation from learning patterns

Experience Stream (UX Transformation):

• Design system + quick fixes (Journey scores 4.0 → 5.5)
• Core improvements (5.5 → 6.5)
• Document management overhaul (6.5 → 7.5, Journey 6 jumps 2→8)
• Advanced features + accessibility (7.5 → 7.8)

Intelligence Stream (Learning System):

• User interactions generate patterns
• Patterns inform skill creation
• Skills make operations more efficient
• Efficiency enables more sophisticated features

Each stream strengthens the others:

• Better UX → More users → More interaction patterns
• More patterns → Better skills → Lower costs
• Lower costs → Fund more UX improvements → Better experience

This wasn’t just “make things faster.” It was “build an economic engine that funds its own evolution while improving user experience and creating competitive moats.”

From discovery to execution

The roadmap laid out clear milestones:

Week 1: Measure everything. Add token counting to all MCP operations. Establish baseline costs. Identify the most expensive patterns.

Weeks 2–3: Build ONE prototype skill (probably DocumentAnalysisSkill, since it solves the worst UX problem). Validate the savings. Confirm the architecture works.

Weeks 4–6: Build the core skills library. Four priority skills: DocumentAnalysis, StandupToIssues, BatchProcessing, MultiSystemWorkflow. These cover 80% of our token-heavy operations.

Weeks 7–9: Migrate agents to use SkillsMCP. Update prompts, add skill selection logic, train agents to prefer skills over raw MCP calls.

Weeks 10–13: Advanced patterns. Dynamic skill generation from learning system. Skills that write themselves based on observed usage patterns.

By February 2026 (MVP target), the transformation would be complete:

• Journey scores averaging 7.8/10 (up from 4.0/10)
• Token costs reduced by 95%+ on common operations
• Economic model established and validated
• Learning system generating new skills automatically

Again, even if the dates change (most of these time estimates tend to be based on human teams) the larger patterns hold.

The parallel work that Saturday reinforced the plan’s viability. While the Chief Architect designed strategy, the Code Agent implemented UX Quick Wins — five features that moved critical journeys from 3/10 to 6/10 in a single session. The UX transformation was already proving its value.

What working the hard way teaches you

We’d been using MCP correctly according to its design. The problem wasn’t that we’d made mistakes — it was that we hadn’t yet discovered the more efficient pattern.

This is what systematic building enables. You build something that works. You measure how it works. You discover patterns in the measurements. The patterns reveal better approaches. The better approaches weren’t available to you initially because you needed the working system to generate the data that revealed them.

The 98.7% token reduction wasn’t magic — it was the result of:

1. Building MCP integration properly first
2. Actually measuring token usage across operations
3. Analyzing the measurements systematically
4. Recognizing the pattern (orchestration overhead)
5. Designing an architecture that eliminates the overhead
6. Connecting that architecture to other problems (UX gaps, economic sustainability)

Saturday’s discovery wasn’t that we’d been doing it wrong. It was that we’d been doing it right enough to learn how to do it better. The working system generated the evidence that pointed toward the optimal system.

That’s the cathedral-building payoff: patience in process creates possibilities that rushing misses. We could have panicked about token costs and made reactive optimizations. Instead, we measured systematically, analyzed comprehensively, and designed strategically. The result wasn’t just efficiency — it was transformation.

The Skills MCP architecture, the UX transformation funding model, the virtuous cycle between efficiency and experience — none of this was visible until we’d built enough to see the whole picture. Systematic building reveals not just what’s wrong, but what’s possible.

Three problems became one solution. Token efficiency became economic strategy. Optimization became transformation. That’s what happens when you build cathedrals instead of chasing features.