Idea #1
Context has a practical ceiling far below the advertised limit, and ignoring this is the root cause of most agent degradation. The claim: infinite (or very large) context windows are a marketing lie that shapes engineering decisions incorrectly — the operational ceiling is much lower and crossing it hurts badly. The mechanism: a paper on 'context rot' shows that performance starts degrading after 25% of the context window is used. The speaker adds a practical rule of thumb from DataRobot's experience: the 'smart zone' is roughly the first 40% of context; past that, you enter the 'dumb zone' where you get dumb responses. This means context is a budget, not a free resource. The implication is severe: if you load 15 MCP servers' tool definitions before a conversation even starts, you may consume over 100,000 tokens in tool descriptions alone — potentially starting your first user message already in the dumb zone. This also explains the common Claude Code experience of the agent repeating mistakes it made 5 minutes earlier as the session grows: the context is, in the speaker's words, 'almost eating itself.' The correct mental model is not 'how much can I fit?' but 'what is the minimum right information to load at the right moment?'
[from: Skills are the New SDKs – Elvin Aghammadzada, DataRobot — YouTube · AI Engineer · https://youtu.be/LC3-P7v3yoI]
Idea #2
In the AI era, enterprise moats shift from switching-cost friction to fluency — and skills are the primary mechanism for building fluency. The historical pattern: SaaS companies built moats through friction (hard integrations, locked-in data, high switching costs). AI is breaking that model because tools like Claude Code can rewrite millions of lines of code in days, collapsing switching costs that took years to build. The new moat is fluency: making the experience so reliable — the gap between user intent and correct outcome so small and fast — that users don't want to leave, not because they can't, but because the platform genuinely works well. Skills compound this: each skill added improves the intent-to-outcome translation, and that improvement accumulates across every subsequent use. The speaker argues this introduces a new item on the enterprise AI evaluation checklist — 'teachability' — alongside existing criteria like security, compliance, data governance, SLA guarantees, and tracing. Teachability means: when my agent harness is new to your platform, how fast can it pick up your operational knowledge (encoded as skills) and get to correct results? Friction moats are defensive; fluency moats are offensive. The strategic implication for platform builders: invest in making your skill library rich and your intent-to-outcome reliability high, because that compounds in a way that documentation and APIs do not.
[from: Skills are the New SDKs – Elvin Aghammadzada, DataRobot — YouTube · AI Engineer · https://youtu.be/LC3-P7v3yoI]
Idea #3
Skills solve the MCP context bloat problem via three-tier progressive disclosure, not by replacing MCP's role. The core claim: connecting an LLM to MCP servers is expensive in tokens (each server adds tool definitions upfront), while skills expose only lightweight metadata until a capability is actually needed — acting like database indexes rather than full table scans. A skill has three layers: (1) front matter/metadata, always loaded, typically under 100 tokens — this is the index that lets the agent know a skill exists; (2) the markdown body, loaded on demand when the agent decides it needs that skill, typically under 5K tokens; (3) optional scripts, either executable (Claude Code can run them and return only the output) or example code (for agent reference). The practical payoff: 15 MCP servers might cost 100,000 tokens in definitions before the conversation starts; the equivalent skill index costs a fraction of that, with full content loaded only when activated. The distinction from MCP is important: MCP is best for remote resources, authentication, process isolation, and heavy compute (the speaker gives the example of semantic search over 400TB of documents or 75 GPUs — things your laptop cannot do). Skills are best when the hard part is reasoning — changing how the agent thinks about a problem. They're complementary: skills can even instantiate and expose an MCP server as part of their execution, so you can use skills to do progressive disclosure for a large MCP server.
[from: Skills are the New SDKs – Elvin Aghammadzada, DataRobot — YouTube · AI Engineer · https://youtu.be/LC3-P7v3yoI]
Idea #4
Build one general-purpose agent engine, then extend it with domain-specific skills rather than building separate agents per domain. The claim is that the skill layer makes agent specialization a configuration problem, not a software-architecture problem. A supply-chain agent and a manufacturing agent can share the same reasoning engine — what differs is the skills loaded on top. This is a significant shift in how you think about delivering AI solutions to customers: instead of maintaining multiple agent codebases across industries, you maintain one well-engineered base agent and a library of skills. Open Agent demonstrated this at the extreme: it has roughly 10 tools and can theoretically handle any task via skills — including writing new skills to extend its own capabilities. However, the speaker flags a critical finding from recent research: LLM-generated skills actually hurt performance. They consume more tokens and cause the model to spend more time reasoning about the problem rather than getting faster. This means humans still need to write high-quality skills, and skills should be treated as production software — versioned, evaluated, and tested — not as prompt snippets. The corollary: a skill is only as good as the human who wrote it, and weak skills are a silent quality ceiling on the agent.
[from: Skills are the New SDKs – Elvin Aghammadzada, DataRobot — YouTube · AI Engineer · https://youtu.be/LC3-P7v3yoI]
Source: Skills are the New SDKs – Elvin Aghammadzada, DataRobot (AI Engineer)
Text summarized and optimized using Anthropic’s models and reviewed by a human.