Unmarkdown
AI Tools

Context Engineering for Everyone: A Non-Developer's Guide

Updated Feb 24, 2026 · 12 min read

In June 2025, Shopify CEO Tobi Lutke posted a message that changed how people think about working with AI. The term he used was "context engineering." Three days later, Andrej Karpathy (co-founder of OpenAI, now leading AI education) amplified the idea, calling it the real skill that separates people who get mediocre AI output from people who get exceptional results.

The concept resonated because it named something millions of people were already experiencing: the AI is only as good as the information you give it.

But most of the discussion since then has been aimed at developers. RAG pipelines, vector databases, embedding models, retrieval strategies. Important work, but irrelevant to the vast majority of people who use AI tools every day for writing, research, project management, and communication.

This guide is for everyone else. No code required.

What is context engineering?

Context engineering is the practice of deliberately structuring the information your AI has access to, so it can give you better answers.

That's it. No fancy infrastructure. No APIs. Just being intentional about what the AI knows when it responds to you.

Every time you start a conversation with ChatGPT or Claude, the AI builds its response based on three things: its training data (what it learned from the internet), its instructions (system prompts, custom instructions, memory), and the conversation so far. Context engineering is about making that third category as rich and relevant as possible.

The distinction from prompt engineering is important. Prompt engineering is about how you ask. Context engineering is about what the AI sees before it answers.

A perfectly worded prompt to an AI that has no context about your work will produce a generic response. A simple question to an AI that has your product roadmap, your team structure, your technical constraints, and your style preferences will produce a response that sounds like it came from someone on your team.

Why context matters more than the model

There's a common assumption that better AI output requires a better model. Upgrade to GPT-5. Switch to Claude. Pay for the Pro tier. And yes, more capable models do produce better results. But the difference between a good model with no context and a good model with rich context is far larger than the difference between model generations.

Consider a concrete example. You ask an AI: "What should our Q2 priorities be?"

Without context, you get a generic framework. "Focus on customer retention, invest in product quality, consider market expansion." Correct, but useless. It could apply to any company in any industry.

With context (your product roadmap, your Q1 results, your competitive landscape, your team capacity, your compliance deadlines), you get: "Given that the V2 API shipped in February and the HIPAA audit deadline moved to March 30, Q2 should prioritize GA launch for the API in April, SSO integration to close the three enterprise deals in pipeline, and backfilling the two engineering positions before the Q3 roadmap planning in June."

Same model. Same prompt. Dramatically different usefulness. The difference is context.

The three layers of context

All context that an AI works with falls into one of three layers. Understanding these layers is the key to context engineering.

Layer 1: Ephemeral context

This is what you type in your current message. The question itself, any details you include, any instructions you add. It exists for one exchange and is gone when you move on to the next topic.

Most people operate exclusively in this layer. They type everything the AI needs to know into every single message. If the AI needs to understand their company to answer a question, they describe their company. If it needs to know their preferences, they list their preferences. Every conversation starts with the same re-explanation.

This works, but it doesn't scale. When your context requires more than a paragraph to explain, you start cutting corners. You leave out the detail about the compliance deadline. You skip the part about the team member who's on leave. The AI gets an incomplete picture and gives you an incomplete answer.

Layer 2: Session context

This is the conversation history. Everything you and the AI have discussed in the current chat session. The AI uses this entire history to inform its responses, which is why the AI seems to "understand" you better the longer you talk.

Session context is limited by the model's context window: the maximum amount of text it can process at once. GPT-4o handles 128,000 tokens (roughly 96,000 words). Claude supports 200,000 tokens by default, with a 1 million token extended option. These are large numbers, but they're bounded, and they reset to zero when you start a new conversation.

This is the layer where compacting happens. When a conversation grows beyond the context window, the AI summarizes earlier parts of the discussion to make room for new messages. In Claude, this process is called compacting, and it triggers at roughly 83.5% of context capacity. The summary preserves the broad strokes but loses specific details, numbers, exact wording, and nuanced constraints.

The result is a conversation that slowly forgets its own beginning. You explained the technical architecture in message 3, but by message 47, the AI's working from a compressed summary that says "discussed technical architecture" without the specifics.

Layer 3: Persistent context

This is information that survives across sessions. It's there when you start a new conversation on Monday, and it's still there on Friday. This is the hardest layer to get right, and it's where context engineering delivers the most value.

Today, persistent context comes in a few forms:

Custom instructions. ChatGPT gives you roughly 1,500 characters per field (about 4,500 characters total across three fields). Claude Projects have no documented hard limit but are practically constrained by how much the model can process. Either way, you're working with a few hundred words of persistent context. Enough for basic preferences, not enough for substantive knowledge.

Saved memories. ChatGPT's memory feature stores short factual snippets, with a total capacity of roughly 1,500 to 1,750 words. Claude launched its memory feature in late 2025, synthesizing a "Memory summary" from past interactions that updates approximately every 24 hours. Both are useful but shallow.

Project files. Both ChatGPT Projects and Claude Projects let you upload reference documents. This is more substantive. You can include your product spec, your style guide, your meeting notes. But files are siloed per project, the AI processes them (not reads them verbatim), and conversation history still resets.

External knowledge bases. This is the newest and most powerful option. Documents that live outside the AI platform, connected via protocols like MCP (Model Context Protocol). The AI reads from these documents on demand. They're always available, always current, and completely under your control.

The problem with layers 1 and 2

Layers 1 and 2 share a fundamental limitation: they reset.

Every new conversation starts from scratch (aside from whatever limited memory or custom instructions carry over). The detailed discussion you had on Monday about your product strategy? Gone on Tuesday. The constraints you explained about your budget? Not in the new conversation. The specific wording your CEO prefers in customer communications? You'll need to explain it again.

This reset is by design, not a bug. Context windows are RAM, not storage. They hold information for the duration of a single session. When the session ends, the memory is cleared.

People work around this by keeping "context documents" in their notes app: blocks of text they copy-paste into every new conversation. If you've ever started a ChatGPT message with "Here's background on my company..." followed by three paragraphs you keep in a Google Doc, you're doing manual context engineering. It works. It's just tedious, error-prone, and doesn't scale.

How to do context engineering without code

Here's the practical part. Three approaches, ordered from simplest to most powerful.

1. Write better custom instructions

This is the lowest-effort, lowest-ceiling approach. But most people underutilize the custom instructions they already have access to.

Instead of vague preferences ("I like concise answers"), include structural information. Your role, your industry, your team size, your current priorities, your key constraints. Write it in a way that gives the AI useful context for any question, not just formatting preferences.

The limitation is real: approximately 1,500 characters in ChatGPT (about 250 words). You'll run out of space quickly if you try to include substantive work context. But it's a start, and it costs nothing.

2. Use Projects with reference files

Both ChatGPT and Claude support Projects that let you upload reference documents. Create a project for your primary work context and upload your most important reference materials: company overview, product roadmap, style guide, current project status.

ChatGPT allows 5 files on the Free plan, 25 on Plus, and 40 on Pro (512MB per file). Claude Projects allow file uploads with custom instructions scoped to the project.

The main limitation is siloing. Your "Product Strategy" project can't reference files from your "Engineering" project. And you're still uploading static files that you need to manually update when things change.

3. Build an external knowledge base with MCP

This is the approach that eliminates the reset problem entirely. Instead of uploading files to an AI project, you maintain documents in an external platform that the AI connects to via MCP (Model Context Protocol).

MCP is an open standard, launched by Anthropic in November 2024, for connecting AI tools to external services. It's been adopted by OpenAI, Google, and Microsoft. The ecosystem now includes over 500 official registry servers and more than 16,000 community servers, with 97 million monthly SDK downloads.

The practical experience works like this: you write and maintain documents in a platform like Unmarkdown™. Your company overview, project specs, meeting notes, style preferences, and anything else your AI needs to know. You connect the platform to your AI assistant via MCP. Now, every new conversation has access to your full document library.

You can say "Read my product roadmap and suggest Q2 priorities" and the AI reads the actual document, not a compressed summary or a six-month-old uploaded file. When your roadmap changes, you update the document (or ask the AI to update it), and the next conversation automatically gets the current version.

No copy-pasting. No file uploads. No re-explaining.

This is context engineering without the engineering

The term "context engineering" can sound intimidating. It evokes images of technical infrastructure: databases, APIs, retrieval pipelines, embedding models. And at the enterprise level, that's often what it involves.

But for individuals and small teams, context engineering is much simpler. It's the practice of writing down what matters and putting it where the AI can find it. Instead of carrying context in your head and transferring it to the AI through conversation, you write it in documents that persist independently of any conversation.

Every time you re-explain your company to an AI, that's a signal that the information should be in a document. Every time the AI gives generic advice that ignores your specific constraints, that's a signal that the constraints should be written down somewhere the AI can read them. Every time you say "as I mentioned in our last conversation," that's a signal that the information needs to persist outside of conversations.

The workflow is straightforward:

  1. Identify what you re-explain most often. That's your highest-value starting content.
  2. Write it in markdown. It doesn't need to be perfect. It needs to be accurate.
  3. Store it in a platform with MCP support, like Unmarkdown™.
  4. Connect to your AI assistant using the integration guide.
  5. Start conversations by asking the AI to read your documents first.

The Claude integration guide walks through the specific setup. It takes about two minutes.

What good context engineering looks like

Once you've set this up, the change in AI usefulness is immediate.

Before context engineering: "Write a project update for my team." Result: generic template with placeholder content.

After context engineering: "Read my project status document and write an update for the engineering channel. Focus on what shipped this sprint and the two blockers." Result: specific update referencing your actual projects, your actual team members, your actual blockers, formatted for Slack.

Before: "Help me prepare for my meeting tomorrow." Result: generic meeting prep advice.

After: "Read my meeting notes from last week and the product roadmap. I'm meeting with the VP of Engineering tomorrow to discuss the API launch timeline. What should I bring up?" Result: specific talking points grounded in your actual decisions, timelines, and open questions.

The AI becomes a tool that understands your world, not one that needs your world explained from scratch every time you use it.

The compounding effect

The most important property of a well-maintained knowledge base is that it compounds. Every document you add makes every future conversation more useful. Every update you make is immediately available to every new session. The context accumulates instead of evaporating.

After a month of maintaining five or six core documents, you'll notice that you almost never need to explain background information. After three months, the AI will feel less like a generic assistant and more like a knowledgeable colleague who's been briefed on everything.

This is what Tobi Lutke was pointing at when he coined the term. Not a technical framework for developers. A fundamental shift in how humans and AI share information. The people who figure this out early, who build their context layer and keep it current, will have a structural advantage over those who keep starting every conversation from zero.

You don't need to write code to do context engineering. You need to write documents.

Your markdown deserves a beautiful home.

Start publishing for free. Upgrade when you need more.

View pricing