All articles

    Architecture note

    29 March 2026by Gustavo Teixeira Cuco3 min read

    Context Engineering

    Architecture context

    Reusable method

    Information and context

    Applied in

    Agents & SkillsTHE iCON
    Context Engineering
    View on LinkedIn

    What I used to call "documentation" is, in fact, the real product of my work with AI.

    For months I built context files, structured repositories with CLAUDE.md files, created persistent memory systems per project. I called it "keeping things organised." What I was actually doing was context engineering — I just didn't have a name for it.

    Tobi Lütke, CEO of Shopify, named it in June 2025: "I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM." Andrej Karpathy sharpened the definition: "context engineering is the delicate art and science of filling the context window with just the right information for the next step."

    It's not about the perfect prompt. It's about what's in the context window when the model needs to act.

    What changed — and why now

    Prompt engineering made sense in 2022–2023. It was the skill of phrasing the right question. It worked for isolated tasks. But when teams moved from demos to production systems — agents, multi-step workflows, persistent memory — the prompt stopped being the bottleneck.

    Most failures in production agents are not model failures. They are context failures. Too little context and the model hallucinates. Too much, or poorly structured, and it loses the thread. The sweet spot is non-trivial — and it cannot be solved with better phrasing.

    If prompt engineering was finding the magic sentence, context engineering is writing the full screenplay.

    What a real context architecture looks like

    The shift becomes concrete when you look at how well-governed AI systems are actually structured. A production-ready setup doesn't rely on a single instruction file. It distributes context across layers: a system-level prompt that defines behaviour and guardrails; modular docs covering business context, architecture, design rules, and execution state; a trigger matrix that maps every type of change to the exact document that must be updated; and a decisions log that preserves the reasoning behind non-obvious choices.

    Each layer answers a different question the model might have. Together, they eliminate the need to re-explain the system on every task.

    That's not documentation. That's infrastructure.

    The question that actually matters

    In enterprise environments, this is not only a design problem. It is also a governance problem: who owns the context, who updates it, and who is accountable when it drifts?

    If you're building with AI in production, the question is no longer "which model should we use?" It's "what enters the context, in what order, and who owns keeping it current?"

    Context engineering is the answer to that question. And like all good engineering, it starts with clarity about the problem — not magic words.

    How are you managing persistent context in your systems? Drop a comment.

    Sources