Why Skills Are the New Context Layer for Agentic Analytics

In my previous article, “Rise of the Agentic Analyst,” I talked about the technology and expertise that an agentic analyst would need to acquire in order to navigate the headwinds facing the BI industry.

It is important to note from that article how the agent stack has gotten simpler in many ways, despite how intimidating it may feel for many users to run commands in a terminal.

Previously, it was common for organizations to build much more infrastructure to support their agents. The complexity of Retrieval-Augmented Generation (RAG) using vector databases was replaced with the user’s local file system.

You no longer need fancy vector retrieval techniques to manage the agent context. You only need to write clear and concise docs that link to each other so your agents can access the information they need, much like a human reader would.

We’re seeing similar trends in the agent tooling space. In the past, agents needed human developers to write each and every tool they’d use to take action on the environment. This required a good amount of forethought and planning from the human developer in order to get it right. And once written, the tools were static.

Coding agents with access to a terminal can arguably now solve problems better if they can write the code themselves. This means the agent can be leaner, with fewer tools, and still be more capable.

Ultimately, the driver of all these changes is coding agents. Agents that require fewer tools and less setup in order to do valuable work, but that also require a change in the AI strategy mindset we’ve been talking about for the past couple of years.

This raises an important question: if coding agents don’t need a massive collection of tools to be effective, what can you do as an agentic analyst to improve their reliability and performance?

The answer is context.

What Happened to Prompt Engineering?

You know another term that has quickly gone by the wayside? Prompt engineering.

For a while at the beginning of this LLM wave, everyone predicted this would be the hot new job. It felt exciting but also counterintuitive that prestigious technical roles such as software engineer would be replaced by people who were simply good at “clear communication,” “describing what they want,” “defining measurable objectives,” etc.

You know, the kind of platitudes you hear at business conventions over burnt coffee and stale donuts, sugar rush on top of a cortisol spike. Middle managers were rejoicing. Messaging like this is where you find the art behind a solid go-to-market strategy: a sort of “noble lie” to get decision-makers onboard with the program.

The early AI age has offered us many such examples.

This was the early era of prompts, starting with “you are a database expert with decades of experience writing SQL…” Those approaches were shared among practitioners as tips, hacks, and shortcuts to get agents to do things. The art of prompting hasn’t gone away, but there wasn’t enough value in the space to justify employing a dedicated prompt engineer on the team.

Models these days don’t need to roleplay either.

Just give Claude instructions for the job. It doesn’t need to believe it is a “SQL expert with 20 years of experience” in order to write that query for you.

Are you also going to give the agent an imaginary mortgage and bills to pay to give it that extra incentive to write performant SQL queries?

Over time, the term “prompt engineering” went out of favor with industry practitioners as a new term, “context engineering,” came into vogue. It sounds more serious and comes with a more rigorous expectation for people doing the job, so you can’t blame developers when they pushed back on the former job title.

The challenge is no longer convincing the model that it’s an expert. The challenge is giving it enough context to do the job right, but not so much data that the agent can no longer keep track of what it’s doing.

Context Engineering

To understand what context engineering can accomplish as an agentic analyst working with agents, let’s start with this thought:

A coding agent should be able to write the code to perform a task directly from its training data.

And it wouldn’t need paragraph upon paragraph of instructions, either. Ideally, your workplace selected a loadout of open-source developer tools that are also well represented in the model’s training data so the agent uses them effectively without the need for babysitting.

Now, of course, anyone who has worked with agents knows this isn’t actually the case.

Sure, you can make better decisions about your tech stack. But you will also always need proper instructions in some form or another to get the AI to do what you want.

So are we back to prompts? Yes, but don’t tell anyone. We call them skills now.

You see, skills use proper Markdown syntax with front matter. You can’t have a skill without organizing it in a specific way. It needs a SKILL.md file. Anthropic wrote a proper standard for skills. This is serious engineering. It’s not “vibe coding” or writing silly roleplay into a chat app.

However simple a folder full of Markdown might seem, skills possess real power. Anthropic published a blog post describing its approach to self-service analytics as a frontier AI lab. The approach is mostly skills.

In fact, Anthropic improved its MCP performance dramatically by combining it with skills.

Don’t feel like you’re above doing things in Markdown, or that you need some complex system to make your agents effective. High-quality skills are really all you need.

Think of it. Anthropic manages its semantic model in Markdown. It documents its internal analytics landscape, maintains it over time, and maps user requests to specific data sources and queries.

You might be thinking that semantic models are too difficult for you to implement yourself. There is certainly depth to the domain. But you now have a coding genius sitting beside you. Why not use it?

Isn’t it cool that we keep things simple for agents and use GitHub as a single source of truth for our organizational semantic model?

This is a powerful pattern. What else can we do with this setup?

By the way, skills aren’t composed only of Markdown files. It is quite common to ship working code packaged inside of a skill. You give the agent a small, deterministic library to complement the instructions it gets from the skill. You give the agent a couple of useful abstractions that make the code easier to work with so it can focus on the task at hand.

This is real engineering. You are writing deterministic helper code that would essentially bootstrap a junior engineer and make them successful within a larger project.

AI agents are like that new engineer who needs some extra context to get the bigger picture. They’re great at writing code, but they don’t know where things are or how they relate to each other yet.

The act of developing a good understanding of a given problem, and modeling the mind of a new developer working through it, are the signs of a truly good engineer. This is what lets you break down technical complexity into simple steps.

Writing high-quality skills is probably the single highest-leverage thing you can do as an analyst in your organization.

It is the most accessible and arguably most impactful form of context engineering at your disposal. Your domain knowledge is so valuable, waiting to be recognized and leveraged by others. You finally have a way to express this know-how without having to contend with a complex implementation.

You can just write the Markdown and push it to GitHub. You can just do things.

Analysts Are Becoming AI Tech Leads

All this talk about skills brings us to a new mindset, a different way of understanding how agents work and what they need to be more effective.

We talked about how writing skills is very similar to writing the technical documentation that a new engineer would need to get started in the role. This is the kind of work that a tech lead would do for an engineering team: a more senior person with experience who knows how the internal systems of the company function together, someone you would trust with this critical onboarding function.

An analyst is very much in a similar position. They understand the company’s data ecosystem, the nuances of certain tables and relationships. Analysts are the tech leads who can build the foundation to make agents successful, even if they’re being steered by business users not familiar with analytics.

This work has a proper term: Developer Experience, or DevEx. It is the act of improving the workflows that engineers use to produce something valuable, like an app or dashboard.

As a strategy, you want to continuously make this easier for people to do in your organization. It improves velocity, productivity, and morale. And just like many things that have to do with engineering morale, it’s been largely ignored by many organizations.

Why bother? Engineers work in a backroom and nobody talks to them. They’re technical, they can solve their own problems. They can toil through architectural decisions that never take into consideration their happiness or productivity. They weren’t invited to the sushi dinners when these decisions were being made in the first place. They probably weren’t even forwarded the sales decks.

Today you no longer have that luxury.

The developer experience at your company is now basically the same as the agent experience.

How hard it is to build and deploy a useful app will define how effective your agents will be. There is no amount of MCPs and licenses you can throw at the problem to solve it.

Leadership would let you get by with ignoring DevEx in the past, but surely in some form or another you are accountable for the AI strategy at your company if you’re reading this article. You have to recognize the synergy described here so you can employ the right strategies to maximize agent impact early rather than late.

You have to get better at DevEx. You have to look at your tech stack and clean up the mess. You have to take software engineering more seriously, even if it’s not your primary function as a company.

There are many ways of doing DevEx besides skills.

Skills are just a gateway to a more complete form of Developer Experience.

These include docs, SDKs, libraries, APIs, specs, and CLIs. Don’t worry if you’re not familiar with all of these concepts. We’ll break them down in future articles.

First, we’ll explore one of Action’s own skills in detail to show how this technology works in practice. Then, we’ll take a closer look at Developer Experience and why it has become such an important discipline in the age of AI.

Agents Succeed When Context Succeeds

Organizations often focus their AI strategy on models, tooling, and vendor selection. Those things matter. But they’re only part of the equation.

The organizations that extract the most value from coding agents will be the ones that make their knowledge easy to find, their systems easy to understand, and their workflows easy to navigate.

The future of agentic analytics is not simply about smarter models. It’s about creating environments where those models can succeed.

Agents succeed when context succeeds. It’s as simple as that.