WTF is context engineering? (with real examples)

At PostHog, technical writers who took over an onboarding AI agent became context engineers, owning what it reads, what it must not do and how its output is checked.

Jina Yoon writes on the blog of PostHog, which makes product analytics and developer tools. PostHog's Wizard is an AI agent that installs PostHog into a customer's code, and early versions gave out-of-date or wrong answers. The docs team took over its development, and its technical writers renamed their team and job titles to context engineers.

• The first version built PostHog's documentation into the agent itself, so customers received outdated instructions; the team now publishes the documentation separately as versioned packages.
• The agent reports the problems it met after each run, which gives the team a live list of stale documents and redundant instructions.
• The team benchmarks each new AI model release before upgrading, and writes down limits such as never renaming a customer's existing feature flags.
• PostHog reports that installation fell from at least two hours to eight minutes. Agents now open about 70% of pull requests in its main code repository, up from about 20% four months earlier.

A team that runs an AI agent can hand the upkeep of its instructions to people already skilled in documentation. That this works outside PostHog is an inference and is not the author's claim. This is a vendor's account of its own product, and the numbers are PostHog's own.

Derived by Working Surface from the article; more in the Playbook. Source line: At PostHog, our context engineers started out as technical writers.

10 October 2026: as AI agents start work without being asked, the rules that limit them need to be written down and owned: by a person, a team and the machine itself.