Context engineering: what it is and why it decides your results with AI

Context engineering is the practice of designing, structuring and managing the context AI agents receive to produce consistent, predictable results aligned with your team's standards. In one sentence: it's not tuning the prompt, it's building the system that makes any prompt produce a good result. And it's what separates teams that "use AI" from teams that master it.

Most development teams, by contrast, use AI the way they used Stack Overflow ten years ago: everyone searches on their own, finds what works, and doesn't share what they learned. Only now, instead of copying snippets, they write prompts. And the result is the same: fragmented knowledge, inconsistent results, and a learning curve that repeats with every new team member. Context engineering is the way out of that pattern.

The evolution most teams don't see

AI adoption in software development has followed a predictable pattern. Each phase solves one problem but creates another:

Most teams are in phase 1 or, at best, phase 2. Organizations in phase 3 or 4 don't necessarily use better models. They use better context.

The relevant data point: According to adoption data, 80% of teams use AI individually. Only 20% have systematized how they use it. And fewer than 5% treat AI context as a managed engineering asset.

What context engineering is (and what it isn't)

Context engineering isn't prompt engineering under a new name.

Prompt engineering focuses on formulating a good question. Context engineering focuses on building the system that makes any question produce a good result. The detail of why tuning the prompt has a ceiling and building the context doesn't: context engineering vs. prompt engineering.

It includes:

• Context design. What information the AI needs for your project: architecture, conventions, patterns, constraints.
• Structure and levels. Not all information is loaded all the time. Progressive disclosure: the minimum to decide, the full picture to execute, the detailed part on demand.
• Composability. Modular contexts that combine without conflict. One skill for testing, another for code review, another for documentation, coexisting.
• Versioning and testing. Context is treated as code: versioned in git, tested to make sure it activates correctly, iterated based on results.
• Organizational distribution. What one developer discovers, the whole team inherits. Automatically.

In short: context engineering is to AI what DevOps was to infrastructure. The systematization of what used to be done by hand.

Skills: the formalization of context engineering

Anthropic recently published an open standard called Agent Skills that formalizes these principles. A skill is a folder that contains:

• SKILL.md (required): Instructions in Markdown with YAML metadata.
• scripts/ (optional): Executable code for validations or transformations.
• references/ (optional): Additional documentation loaded on demand.
• assets/ (optional): Templates, resources, reference examples.

The interesting part isn't the folder structure. It's the mental model it implies.

Progressive disclosure: the AI doesn't load everything, it loads just enough

The system uses three levels of information:

1. Level 1 (YAML metadata): Always loaded. Tells the AI when to activate the skill. Minimal token consumption.
2. Level 2 (SKILL.md body): Loaded when the AI determines the skill is relevant. Full instructions.
3. Level 3 (linked files): The AI consults them only when it needs additional detail. Documentation, API guides, examples.

This pattern matters because it solves a real problem: the context window isn't infinite. More context isn't better context. Better context is the right context at the right moment.

The analogy that explains it all

Anthropic uses a kitchen analogy that is very clear:

MCP (Model Context Protocol) is the professional kitchen: access to tools, ingredients, equipment. It connects the AI to your services (Linear, Notion, GitHub, Slack...).

Skills are the recipes: step-by-step instructions on how to create something valuable with those tools.

Without recipes, you have a kitchen nobody knows how to use. Without a kitchen, recipes are theory. Together, they let anyone on the team execute complex flows without having to invent them each time.

Three categories of skills by the problem they solve

Anthropic has identified three recurring patterns in how teams use skills. Each solves a different problem:

From individual skill to organizational capability

What makes context engineering a discipline and not just a technique is the change of scale: from the individual to the organizational.

Skills can be distributed at the organization level. This means:

• An admin deploys a skill and the whole team has it automatically.
• Updates are centralized. When someone improves a skill, everyone benefits instantly.
• The AI behaves consistently for all team members on the same project.
• Onboarding accelerates because new members inherit months of collective knowledge.

This is the leap most teams haven't taken. It's not that the tools don't allow it. It's that they haven't recognized context management as an engineering responsibility.

The real problem: When each developer has their own prompts, the team has N different ways of using the same tool. Results are inconsistent. The generated code doesn't respect the conventions. And each new member takes weeks to be productive with AI. It's not a tooling problem, it's a context problem.

Testing context: treating instructions as code

One of the most interesting practices of the Skills standard is its proposal for testing. If your context is an engineering asset, it should be tested as one:

• Activation tests: Does the skill load when it should? Does it not load when it shouldn't?
• Functional tests: Is the output correct? Do the API calls work? Are the edge cases covered?
• Performance tests: Is it better with the skill than without it? How many round-trip messages are saved? How many tokens are consumed?

Comparison data Anthropic proposes to measure the impact:

The concept is simple: the instructions you give the AI are a system, and systems get measured.

The connection with Spec-Driven Development

If this sounds familiar, it's because it is.

At onext we've been implementing the principles of context engineering in development teams since before the term existed. We call it Spec-Driven Development (SDD): structured specifications that guide AI agents with control, predictability and traceability.

The convergence is direct:

• The project "constitution" in SDD is the equivalent of an organizational SKILL.md: immutable rules the AI must respect.
• The spec templates are category 1 skills: consistent documents and assets.
• The prompt playbooks are category 2 skills: automated workflows.
• The code review flow for AI is a category 3 skill: domain intelligence applied over tools.

What SDD has demonstrated: across the 12 transformed teams, the pattern signed with clients in 2026 is ×7 delivery velocity, 0 sprints lost during the transformation and −50% time-to-production, with +40% code consistency and every line traceable to a requirement. Context engineering is the formalization of these principles at an industry scale.

Where to start

You don't need to implement everything at once. The natural evolution is:

1. Weeks 1-2: Create an AGENTS.md or CLAUDE.md in your main repository. Document the conventions your team already follows. Our shared-instructions guide explains how to do it step by step.
2. Weeks 3-4: Identify 2-3 repetitive flows (code review, test generation, documentation) and create specific instructions for each.
3. Month 2: Package the most effective instructions as portable skills. Add validation scripts where it makes sense.
4. Month 3+: Establish a continuous improvement cycle: contribution, review, validation, distribution, feedback. Treat context as an internal product.

The key is to start small, with what already works, and scale from there.

Frequently asked questions

What is context engineering?

Context engineering is the practice of designing, structuring and managing the context AI agents receive —your project's architecture, conventions, rules and domain— so they produce consistent, predictable results. It's not tuning the prompt: it's building the system that makes any prompt produce a good result. It's to AI what DevOps was to infrastructure: the systematization of what used to be done by hand.

How is it different from prompt engineering?

Prompt engineering optimizes a specific question; context engineering builds the system that makes all questions work. Tuning prompts has a ceiling and doesn't scale across people or projects; well-designed context (versioned, tested, shared) is inherited by the whole team and improves with every iteration. One is an individual skill; the other, an organizational capability.

Why is context engineering a competitive advantage?

Because every team has access to the same models —they get commoditized and improve for everyone equally. What doesn't get commoditized is the context: how you configure the AI, what it knows about your business, which conventions it respects, which errors it avoids. That's proprietary to your team, it can't be copied, and it's what makes the same tool deliver ×3 in one organization and nothing in another.

Context is the competitive advantage

Every team has access to the same models. GPT-4, Claude, Gemini. The tools get commoditized. The models improve for everyone equally.

What doesn't get commoditized is the context. How you configure the AI, what it knows about your project, which conventions it respects, which patterns it follows, which errors it avoids. That's proprietary to your team. That can't be copied. That gets built.

Teams that master context engineering:

• Get consistent results without depending on whichever developer writes the prompt.
• Scale collective knowledge with every improvement any member contributes.
• Cut onboarding from weeks to days.
• Generate code that respects the architecture on the first attempt.
• Treat the AI as another team member, not as a sophisticated autocomplete.

The question isn't whether your team will use AI. The question is whether the context you provide it will be handcrafted or engineered. That decision defines the results.