Context Engineering: How I Give AI Agents the Right Context

The quality of code produced by an agent depends less on prompt length than on what it knows about the project.

An agent equipped with the right rules, reliable sources, and a clear plan can work with precision. Without that context, even a capable model has to guess, and every assumption becomes a potential source of error.

Context engineering is precisely the practice of selecting, structuring, and maintaining that information. The goal is not to fill the model's context window, but to provide the smallest set of high-signal information, at the right time.

In my article of the shift from vibe coding to agentic engineering, I explained why context is becoming part of software infrastructure. Here is how I build that infrastructure in practice, using AGENTS.md, CLAUDE.md, Markdown specs, skills, tools, and MCP.

Context engineering and prompt engineering solve different problems

Prompt engineering improves how an instruction is phrased. Context engineering organizes everything the model can use to interpret and carry out that instruction.

Take a concrete request: “add a local visibility audit for Bing to Begonia.pro, my local SEO SaaS, to measure this channel alongside Google.”

The business need is clear, but that sentence says nothing about the existing architecture, product rules, available data, components to reuse, or definition of done. That context is what enables the agent to turn a good idea into a coherent feature.

Anthropic defines context engineering as curating and maintaining the optimal set of tokens available during inference. The important word is optimal, not maximal.

My real use case: evolving a SaaS without re-explaining the project

On projects such as Begonia.pro or Fude.md, a feature crosses several layers: user need, interface, business logic, storage, external services, and tests. To produce a coherent implementation rather than merely plausible code, the agent needs to understand:

• the expected user outcome and what remains out of scope;
• the existing components, types, and user journeys to reuse;
• business rules and product decisions that are not visible in the code;
• current external service contracts and required permissions;
• project conventions, guardrails, and areas that must be preserved;
• interface states, supported languages, and validation criteria before shipping.

I do not put all of that into one giant prompt. I split context between a static layer, available from the start, and a dynamic layer, retrieved when the task requires it.

My architecture: a static foundation, then dynamic context

Static context defines the rules of the game. Dynamic context brings in information specific to the task and to the current state of the project.

Markdown specs occupy a particular place: they remain in the project, but the agent loads only the one for the current feature. I build them through ongoing discussions with Codex or Claude Code and review them in Fude. They bring together the problem, scope, decisions, and acceptance criteria, then serve as both reference context and an implementation plan. I describe this workflow in detail below.

AGENTS.md and CLAUDE.md hold the map, not the whole library

The entry point depends on the agent. Codex and other agents use AGENTS.md, while Claude Code loads CLAUDE.md into its context at the beginning of every session. These files should be precise, short, and maintainable.

They usually include:

• the product's purpose and target users;
• the stack and package manager;
• important directories and their responsibilities;
• conventions that cannot be inferred easily from the code;
• areas that should not change without an explicit reason;
• lint, test, typecheck, and build commands;
• the definition of done for a change.

A deliberately simplified extract of the project context would look more like this:

# Project

Begonia.pro is a Local SEO SaaS built with Nuxt for businesses and consultants.

## Product rules

- An audit must explain its findings, not only display a score.
- Every result from an external source retains its source and date.
- French and English user journeys evolve together.

## Technical rules

- Reuse existing audit types, components, and patterns.
- Call external providers only from the server.
- Never expose a key or another customer's data.

## Validation

- Run lint, typecheck, and the relevant tests.
- Check empty, loading, result, and error states.
- Summarize changed files, verification performed, and remaining limitations.

I do not duplicate the same rules in two files that will eventually drift apart. My CLAUDE.md can import the shared foundation, then add only the instructions specific to Claude Code:

@AGENTS.md

## Claude Code

- Use the active Markdown spec as the implementation plan.

OpenAI recommends maintaining an AGENTS.md file to help Codex operate effectively in a repository. Claude's documentation explains that Claude Code reads CLAUDE.md and can import AGENTS.md from it.

Documentation explains durable decisions

Code shows what the product does today. It does not always explain why a solution was chosen, which alternative was rejected, or which customer constraint must not be broken.

I therefore keep information that should survive several tasks in the documentation:

• product specs and acceptance criteria;
• architecture decisions;
• contracts with external services;
• deployment or migration procedures;
• a few examples considered canonical.

Good documentation reduces guesswork. Bad documentation does the opposite: an agent gives too much trust to a decision that is no longer true. I add a date or status to sensitive documents and remove obsolete instructions instead of accumulating exceptions.

Skills bring in a method on demand

A skill is a specialized instruction package: how to write Nuxt content, audit a database migration, review a PR, or build an MCP integration. The agent loads it only when the task matches.

When an official skill is available, I install it first. I use the official Nuxt skill, which gives the agent the framework's conventions, the files to inspect, and the points that require attention for the version in use.

I reserve my own skills for methods specific to my projects. This is more precise than a global rule such as “follow Nuxt best practices”: I encode a method once, then reuse it across agents and models.

Tools and MCP bring in the current state of the world

Repository files are not enough when an answer depends on live information: search volume, ticket status, updated documentation, customer content, or an API response.

Tools let the agent explore its environment and bring back targeted information. MCP (Model Context Protocol) standardizes access to some of those sources and actions. I have already shared what I learned from building two MCP servers for my SaaS products.

When I work on a pull request, GitHub's official MCP server lets the agent access its description, proposed changes, review comments, and CI status. I do not need to copy all of that into a prompt: the agent retrieves the current state of the PR when it starts working on it.

MCP therefore complements the project's static context with information that evolves outside the local repository: discussions, review decisions, and validation results. The agent accesses this context when it becomes useful instead of loading it systematically into every conversation.

My seven-step workflow

1. I build the spec with AI while reviewing it in Fude

For an important feature, I start by working with AI in Codex or Claude Code. Together, we frame the user problem, expected outcome, scope, out-of-scope items, known decisions, and acceptance criteria. The AI helps me produce and challenge a Markdown spec file.

During the discussion, I keep the file open in Fude, my Markdown file reader. As the spec evolves through iterations in Codex or Claude Code, I review it in that clean, carefully designed environment, spot unclear areas, then continue the conversation with the AI to refine it.

The approved version has two roles: reference context for understanding the feature and an implementation plan for building it. The feature no longer depends on a prompt buried in a conversation.

2. The agent reads the project rules

With Codex, AGENTS.md provides the stack, conventions, and validation commands. With Claude Code, that information comes through CLAUDE.md, which can import the same shared foundation. The agent then reads the Markdown spec reviewed in Fude and the linked documents without loading everything “just in case.”

3. It explores before proposing

I ask it to find related components, schemas, tests, and similar features. Existing code often provides better context than a long explanation: it shows naming, abstractions, and the expected quality level.

4. It loads the specialized method

Depending on the task, the agent uses a Nuxt, database, security, content, or code review skill. The skill adds a process without polluting every other conversation.

5. It retrieves fresh data

If information is missing or may have changed, the agent uses a tool or MCP. It brings back only the required result and its source, not a complete export.

6. It works in verifiable increments

I prefer a small change followed by a test over a long generation that is difficult to review. Typecheck errors, tests, and the diff then become context for the next step.

7. It verifies the result and leaves a trace

The work ends with the planned commands, a diff review, and a summary: outcome, changed files, decisions, verification performed, and remaining limitations. That trace helps the next session without preserving the entire raw history.

The mistakes that taught me the most

Providing too much context

Attaching ten documents feels reassuring, but often hides the important rule. A large context window is not an obligation to fill it. I start with the minimum foundation, then let the agent retrieve what is missing.

Keeping contradictory instructions

An old spec, a comment, and a rule file can describe three versions of the product. I define a clear hierarchy: explicit repository rules, the active spec, current code and tests, then reference documentation. When sources conflict, the agent must report it instead of choosing silently.

Turning memory into the source of truth

Memory is useful for retaining a preference or the state of a long task. It does not replace the repository, database, or current documentation. Critical information must remain verifiable.

Measuring quality by token count

A short context can be incomplete; a long one can be excellent. I look instead at first-pass success, required clarifications, regressions, unnecessary tool calls, and human review time.

My context engineering checklist

Before handing a task to an agent, I check:

• Outcome: are the expected result and out-of-scope items explicit?
• Authority: which source wins when information conflicts?
• Project: does the agent know the stack, directories, and non-obvious constraints?
• Examples: is there a canonical implementation to follow?
• Freshness: must any data be retrieved now?
• Tools: does each tool have a distinct role and appropriate permissions?
• Guardrails: are secrets, personal data, and risky actions protected?
• Validation: which commands and scenarios prove the result works?
• Trace: what should remain available for the next session?

My final question is simple: if I remove this information, is the agent's behavior likely to change? If the answer is no, it probably does not need to enter the context.

Frequently asked questions about context engineering

::faq-accordion{class="mt-6"}

items:

• question: "What is context engineering in AI?" answer: >- Context engineering is the practice of selecting, structuring, providing, and maintaining the information a model needs for a given task. It includes instructions, documentation, examples, history, memory, tools, retrieved data, and guardrails.
• question: "What is the difference between prompt engineering and context engineering?" answer: >- Prompt engineering focuses mainly on phrasing the request. Context engineering manages the whole information environment in which that request is executed. A good prompt is therefore part of good context, but it is not enough to guide an agent through a real product project.
• question: "How do you select the right context for an AI agent?" answer: >- I prioritize information that is relevant to the task, comes from an authoritative source, is current, compact, and directly actionable. I load durable rules upfront, then retrieve specialized documents and data on demand. Finally, I use observed failures to improve the context instead of adding preventive rules without evidence.

::

Context is part of the product

Context engineering is not a trick for getting a better answer in a chat. It is architecture work: organizing what must remain stable, what must be retrieved, what must be verified, and what must never be exposed.

It is also what separates an impressive demo from a repeatable workflow. A better model helps. Better context makes the result more consistent from one task to the next and makes failures easier to understand when they happen.

This is the discipline I apply in my Product Engineering work: frame the need, structure the context, build, then verify.

What information do your agents most often lack: project rules, domain knowledge, or validation criteria?

📌 Do you have a web project to launch or an existing product to evolve? I design and build it end to end, using AI to ship faster. Explore my Product Engineering services.

Sources

• Google, “The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering”.
• Anthropic, “Effective context engineering for AI agents”.
• OpenAI, “How OpenAI uses Codex”.
• OpenAI, “ChatGPT Search”.
• Claude Code, “How Claude remembers your project”.
• Model Context Protocol, MCP architecture documentation.
• GitHub, official GitHub MCP server.