Context Engineering：PostHog Wizard

Say you're deploying an AI assistant that processes online order returns. For it to work, it would need access to your store's purchase policy, item prices, and order history.

The problem is that LLMs can only hold a finite amount of information, so you can't give it the whole database of purchases made by every user since you launched. Instead, you might provide details on one specific order, which you can only get after the customer provides their order number.

Building the systems to deliver that information is what context engineering is about. You're designing what an agent should read – instructions, tools, data, examples, memory – and when. Andrej Karpathy, one of the co-founders of OpenAI, described it well:

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

You might think that as models and agents improve, context engineering's relevance would decrease over time, but it's actually the opposite.

Better models just give agents the potential to tackle a challenge, but context engineering is what gets them to actually succeed at scale.

What does context engineering actually look like?

To understand what context engineering is more concretely, take a look at the system behind the PostHog Wizard, our custom onboarding agent.

The PostHog Wizard is an AI assistant that automatically installs PostHog in an existing codebase. This used to take developers at least 2 hours of manually reading docs, pasting code snippets, and testing integrations. Now, users can accomplish this in 8 minutes – all with a simple npx @posthog/wizard@latest command. And it's been wildly successful since launch, 5x'ing our paid conversion rates and 2x'ing activation speeds.

Building it, however, was not simple.

When we started on it back in 2025, language models were already good enough at generalized coding tasks. The challenge was in making them good at PostHog-specific code. It's like how the world's greatest rocket scientist won't know how to install a toilet or cook a mean lasagna if they've never tried or been taught how. No matter how super-intelligent models are, general knowledge can only take you so far in highly specific scenarios.

Then, when you consider that PostHog has 20+ products, 17+ SDKs, and 25+ frameworks that are constantly getting updated, you'll start to see the moving combinatorial explosion we were dealing with. On top of that, LLMs are diabolically good at sounding correct, so there were many wrong solutions that slipped and passed our review in the early stages.

(We won't go into the details of how we solved those problems in this blog. If you're interested in that story and want to see the lessons we learned while building the PostHog Wizard, check out our newsletter.)

It took several months of hacking and experimenting until we finally landed on the design that's still in use today: the context-mill.

It's an automated pipeline that independently gathers PostHog installation context and serves it to downstream wizard client agents. It works by first grabbing the latest info about PostHog from three main sources:

• Docs. For example, the Next.js integration skill pulls the Next.js library docs, plus the shared .md guide about how to identify users for analytics.
• Example apps. These are 40+ few-shot example apps with PostHog installed across frameworks like Django, Swift, Rust and more. The wizard is instructed to match these as closely as possible.
• Hand-written instructions. This contains technical "gotchas" to avoid, step-by-step installation guides, and other prompts for runtime.

Once it's gathered all of the source information, the context-mill assembles the material into a collection of zip files and cuts a versioned GitHub release. It then packages the context as downloadable skills and registers them with MCP servers as a publicly accessible resource. That way, downstream agents can install PostHog with the latest version from anywhere, anytime.

This is just one example of context engineering in practice. Anyone in the field will tell you that no two context engines will ever look the same since each one is typically built to solve a specific, unique, contextual problem.

Why is everyone talking about context engineering now?

Context engineering first started trending around 2024, but it exploded in popularity in 2025 for a few reasons.

1. Prompt engineering turned into context engineering

In 2025, most of us were still using ChatGPT in the browser as a chatbot and marveling at Cursor's auto-complete.

At the time, the only real surface in which engineers could improve their AI systems was just in their prompts. This was the era when prompt engineering was hot; people would work on mastering the craft of writing the best combination of text for one-shot classification or generation tasks. Companies were hiring "prompt engineers", communities like r/PromptEngineering thrived, and Google published a 68-page whitepaper on advanced prompting techniques.

And then agents happened. Agents changed the meta from chatbots that primarily work in single-turn interactions to systems that can operate over multiple turns of inference:

This opened up way more possibilities for AI engineering.1 Developers could now start designing strategies for the entire context state including system instructions, tools, message history, and more.

2. The models just kept getting better

With every major model release, there's a matching rise in interest in context engineering since no two generations are the same. Boris Cherny, the creator of Claude Code, described:

"Every model generation behaves differently. It has a slightly different personality, and you have to take the time to get to know it and then adjust."

One of the most dramatic advancements in model capabilities of 2026 was Anthropic's Fable 5. As part of the release, Anthropic reported that they removed 80% of Claude Code's system prompt because the new models needed fewer rules and repetition. Instead, they said that allowing more space for LLM judgment was the better approach. The new rules for context engineering now favor leaner prompts and thinner context.

For example, in older versions of the PostHog Wizard, the installation would often land on the wrong project in monorepos because our scripts pointed to root by default. Once models got smart enough to reliably infer repo structure on their own, we updated it so headless runs take advantage of those capabilities.

This is an ongoing cycle in context engineering. As models improve, your context needs to be reshaped and often cut down in response. Otherwise, you risk "hobbling" the model – A.K.A., overconstraining it by giving too much information, rather than letting it use built-in reasoning.

3. Agentic systems keep getting more complex

Alongside model improvements, harnesses, infrastructure, and tasks keep getting more complex. In turn, agents have more complicated needs for context, which is why interest in context engineering has grown.

Consider that in early 2025, most people were working with just a handful of agents at a time, usually on a single task. Now, we have things like:

• Multi-agent orchestration: Agents leading other agents to break up, dispatch, and execute work in parallel
• Long-horizon tasks: Agents working autonomously for hours on multi-step projects with complete verification
• Scheduled agents: Agents that run on a schedule or trigger on events, without a human starting the session
• Multiplayer AI: Systems where people and agents work in the same shared workspace and context, like in Slack
• Sandboxing: Isolated environments that limit what agents can touch, which lets them run often with even higher autonomy