Context Engineering

Abstract

The shift from prompt engineering to context engineering reflects a deeper truth about working with AI. Models don’t need cleverly worded instructions as much as they need the same context that a skilled human would need to do good work. The question isn’t “how do I trick the AI into writing good code?” It is “what would a new team member need to know to contribute effectively, and how do I encode that knowledge in a form the AI can use?

A Real Skill

As agentic engieering has matured, a key insight has emerged: the quality of AI-generated code depends less on the cleverness of your prompts and more on the quality of the context provided. This means providing AI agents with rich, structured information about your codebase, architecture, conventions, and intent. It less about prompt engineering and more about context engineering.

Developers must consider six primary types of context:

  • Instructions: the agent’s core role, goals, and operational boundaries.
  • Knowledge: retrieved documents, architectural diagrams, and domain-specific data.
  • Memory: short-term session logs (what just happened) and long-term persistent state (what the project is).
  • Examples: few-shot behavioral demonstrations and codebase reference patterns.
  • Tools: precise definitions of the APIs, scripts, and external services the agent can invoke.
  • Guardrails: hard constraints, formatting rules, and safety validations.

What is Context

…WIP…

Context Rot

….WIP…

Static vs. Dynamic Context

Static context is always loaded: system instructions, rule (AGENTS.md, CLAUDE.md), global memory, persona definitions. It defines who the agent is and how it behaves. It is expensive because every token is present in every interaction.

Dynamic context is loaded on demand: skill instructions triggered by task matching, tool results, documents fetched from RAG pipelines, windowed session history. It is efficient because the agent pays the token cost only when the information is needed.

…WIP… REVOIR LE DIAGRAM mermaid

flowchart TB
A(<h2>Instructions \n Roles, Goals, Boundaries</h2>) -->
B(<h2>Knowledge \n Documents, Diagrams, Domain Data</h2>)
C(<h2>Memotry \n Sesssion Logs, Persistent state</h2>)
D(<h2>Examples \n Few-shot demos, reference patterns</h2>)
E(<h2>Tools \n APIs, scripts, external services</h2>)
F(<h2>Guardrails \n Hard Constraints, safety rules</h2>)

    subgraph Static["📌 Static Context (Always Loaded)"]
        direction LR
        SI["System instructions"]
        RF["Rule files\n(AGENTS.md, CLAUDE.md)"]
        GM["Global memory"]
        PD["Persona definitions"]
    end
    subgraph Dynamic["⚡ Dynamic Context (On Demand)"]
        direction LR
        SK["Skill instructions\n(task matching)"]
        TR["Tool results\n(execution)"]
        RAG["RAG documents\n(fetched)"]
        WH["Windowed session\nhistory"]
    end
    Agent["🤖 Agent"] --> Static
    Agent --> Dynamic

    style Static fill:#1a2a3d,stroke:#4a6a8a,color:#fff
    style Dynamic fill:#1a3d1a,stroke:#4a8a4a,color:#fff
    style Agent fill:#533483,stroke:#7a5ab5,color:#fff
Figure 1: Context Engineering — Static vs. Dynamic
The Design Trade-off

Too much static context wastes tokens and dilutes signals. Too little means the agent forgets critical rules. The best systems treat this boundary as a first-class architectural decision, reviewed and versioned like any other configuration.

The most powerful pattern for managing dynamic context is Agent skills: structured, portable, packages of procedural knowledge that the agent loads only when the task calls for it.