The next frontier is context - not models

Over the last 18 months, AI has experienced massive gains. We have released new models almost monthly. Every model is "better" than the last, and often cheaper! Do more with less! Do the same things better and faster! Do things we couldn't do before! Do all the things!

During this time, we've also introduced skills, plugins, marketplaces, agents and so many different ways of organizing knowledge. This is great. every one of these innovations has helped us build towards the next step in our AI journey.

But increasingly, I'm seeing a different conversation happening inside companies. It's no longer "what's the next big thing we're missing?" but rather, "what do we do with all this stuff?"

I recently ran an internal audit at my workplace. Nearly 6,000 skills spread across thousands of marketplaces and repositories. I categorized every single skill. And what did I discover?

The ten largest capability categories accounted for 2,444 unique skill locations. That's 45.57%.

The top 20 accounted for 3,508 unique skill locations. That's 65.41%.

Think about that. Just 20 broad categories of capabilities account for nearly two-thirds of our entire skills landscape.

That doesn't mean they're all doing exactly the same thing. But it raises an interesting question:

Are our needs really that different, or are we solving the same problems over and over again?

From Proliferation to Saturation

The consolidation discussion predates AI. It predates computing. Humans have always used tools, and making a new tool for every job has always been inefficient.

So why are we joyously baking hundreds of variations of skills like "open a Jira ticket" or "edit a wiki page"? Are our needs really so unique?

My skills analysis identified 3,508 skill locations across just 20 common capability categories. An average of 175 per category. That doesn't mean 175 identical implementations of every capability. But it does raise an interesting question: how much of this variation represents genuinely different needs, and how much is simply reinvention?

Context. That's often the answer.

I've previously published a paper on the power of composed context assembly, exploring how shared capabilities can be adapted to different organizational needs through dynamically assembled context.

But there's a problem that composition alone doesn't solve: repetition.

My skills analysis revealed a landscape of strikingly similar capabilities, implemented over and over again across the enterprise. My analysis of agents revealed a related, but subtly different problem: repeated context across many subagents. Bloated context. Including context assembled by my own engine.

A swarm of subagents, performing similar tasks from different perspectives, would often carry many of the same instructions. Each agent received its own blocks of composed context, sometimes repeating substantial portions of what its peers had already been given.

We had achieved customization. We had achieved reuse. We had even solved much of the problem of distributing organizational knowledge.

But at what cost?

More tokens. More repeated instructions. More opportunities for conflicting guidance. And potentially, more interference with the very reasoning we were trying to improve.

We had solved the problem of getting the right context to the right agents.

Now we had to ask whether we were giving them too much.

The cost was context saturation.

Distillation

Let's take a relatively simple system: code review.

We start with a system prompt, a reviewer persona, Jira ticket information, and a code coverage report. We tell the agent to fetch the PR, extract the diff, read the patch, analyze each line, apply a long list of rules, and definitely, definitely don't do an equally long list of prohibited things.

We've built a highly bespoke skill, packed with situation-specific instructions.

But is this the best way?

So we do what good software engineers do. We abstract.

We extract the common review process into a reusable system prompt. We introduce personas to provide different expert perspectives. We compose organizational rules and domain knowledge through context assembly, injecting the appropriate context for each review.

Now we have a reusable skill, dynamically customized for different teams, repositories, and review scenarios.

Success! Right?

Well, we've taken a huge, specific prompt and turned it into an even bigger, abstract one. The original instructions are still there, and now we've layered dynamically assembled context on top.

Was this better? DRY says so.

We had optimized for reuse, maintainability, and customization. But we hadn't necessarily optimized for the model consuming all this context.

And these are fundamentally different problems.

A system can be beautifully abstracted, perfectly DRY, and still be terribly inefficient at execution.

We had confused software engineering efficiency with context efficiency.

Have We Forgotten the Bitter Lesson?

In 2019, Richard Sutton published The Bitter Lesson. His observation was uncomfortable: throughout the history of AI, researchers repeatedly invested in carefully engineered, human-designed approaches, only to see more general methods eventually surpass them as computation scaled.

And yet, here we are.

We have models capable of reasoning across enormous bodies of knowledge, adapting to unfamiliar problems, and navigating complex workflows.

And what do we do?

We write thousands of lines of instructions telling them how to think.

We prescribe their steps. We anticipate their decisions. We build elaborate orchestration around them. Then we add more instructions to compensate when the results aren't what we expected.

Does any of this sound familiar?

Sutton's lesson wasn't about prompts or agents. But I wonder whether our enthusiasm for engineering every detail of agent behavior is creating a modern version of the same trap.

We may be spending more effort teaching our agents how to solve problems than allowing them to demonstrate what they already know.

That's not an argument for removing constraints or abandoning engineering discipline. It's an argument for questioning which constraints actually improve outcomes, and which simply encode our own assumptions.

Separation

A long-established principle in software engineering is separation of concerns: each component should have a clear responsibility.

Yet the way we write skills today often violates this principle. A single skill might contain a persona's expertise, task instructions, outcome definitions, domain knowledge, and exhaustive rules describing what to do and what not to do.

We've bundled everything together because we want the agent to have everything it might need. But does it really need all of that, all at once?

Research such as Lost in the Middle highlights an important limitation: just because information is present in a model's context doesn't mean the model will effectively use it.

And there's another side to this problem. Simply giving an agent a reference to a file doesn't guarantee that it will read it, either.

These are different failure modes, but they point toward the same architectural opportunity: separating context discovery from context acquisition and application.

Instead of loading every piece of potentially relevant information up front, we can make it discoverable and allow the agent to retrieve what it needs, when it needs it. Essential instructions can remain explicit, while supporting knowledge and evidence can be loaded on demand.

This is why we encourage keeping CLAUDE.md and AGENTS.md files lean, focused on guidance that applies to most operations within a repository rather than every possible scenario.

The same principle applies to skills.

Let's return to our pull request review example. What if, instead of embedding the review process, expertise, evidence, and classification rules into one enormous prompt, we separated them into distinct artifacts?

Skill body:
You are reviewing a pull request.

The patch is here: <path to patch>
The PR description and conversation: <path to PR JSON>
Your expertise: <path to expert lens>
The Jira story and discussion: <path to Jira JSON>
Code coverage: <path to lcov report>
Finding severity guidelines: <path to severity guide>

Apply your expert perspective to the PR.
Use the available evidence and guidelines to identify
and classify meaningful findings.

Notice what we've removed.

We're no longer telling the model how to read a patch, how to walk through every line, or prescribing a long sequence of reasoning steps. We're giving it a task, a perspective, access to evidence, and the criteria for evaluating its findings.

The skill describes what the agent needs to accomplish, not every step it must take to accomplish it.

Of course, there's a tradeoff.

We can't guarantee that the model will read every referenced file. But loading everything into its context doesn't guarantee that it will reason over everything, either.

The challenge isn't simply to provide less context. It's to ensure that essential context is acquired and applied, while avoiding the cost of loading everything indiscriminately.

And perhaps most importantly, to recognize that making knowledge available to an agent is not the same as making that knowledge useful.

Personas, Prompts, Pink Elephants, Oh My!

You may have noticed that in my example, I didn't talk much about guardrails. I didn't spend exhaustive effort telling the model what it may not do.

This brings me to the "pink elephant problem."

Tell someone not to think about a pink elephant. What's the first thing that comes to mind?

A pink elephant, of course.

Models aren't people, and they don't necessarily respond to negative instructions the way humans do. But there's an interesting parallel: every instruction we add introduces more concepts, conditions, and potential distractions into the model's context. Even the things we're telling it not to do.

There's an interesting lesson here for how we write agent instructions.

Rather than exhaustively describing everything an agent must not do, perhaps we should spend more effort describing the behavior we actually want.

"Don't do X" tells the model what to avoid. "When encountering X, do Y instead" gives it a constructive path forward.

This doesn't mean negative instructions are inherently bad, or that security boundaries should be left to clever prompt engineering. Permissions, sandboxing, and authorization belong in enforceable systems wherever possible.

But when we're describing how an agent should perform its work, I suspect we could eliminate a surprising amount of unnecessary instruction simply by focusing on desired outcomes rather than anticipated mistakes.

And that brings us back to the question: how much of our carefully engineered context is actually helping?

So much has changed. Yet so much stays the same

Models have improved by leaps and bounds over the years, but these insightful papers expose concepts that have outlasted the AI models of their time. We've spent the last two years learning how to give agents more capabilities, more instructions, and more context.

Perhaps the next challenge isn't figuring out what else we can give them, but understanding what they actually need.

That means separating capabilities from expertise, evidence from instructions, and constraints from execution. It means making context discoverable without making all of it mandatory. And it means being willing to question whether our carefully engineered prompts are helping the model, or getting in its way.

The next frontier may not be how much context we can assemble.

It may be how much we can leave out.