Harness Engineering for the People Who Own the Docs

A model can write a clear paragraph. The paragraph matches your product when the agent was allowed to read your page. It matches a general tutorial when that was all it could see.

Harness engineering is the practice of building the surroundings that turn a raw model into an agent you can check. The guide it reads first. The context it may see. The tools it can call. The limits on how far it may go. The long course on those ideas is Learn Harness Engineering. It organizes the work as instructions, state, checks, scope, and how a session starts and ends. This post is the short version for the people who own the words.

Four parts, and one of them is the pages

Guides. The rules the agent reads before it acts. Voice, the terms you use, and a file that says to change one page at a time. The file stays short. It points at the docs. It does not contain them.

Context engineering. What the agent is allowed to see for this task. The passages retrieved for the question. The notes that should still be true next session. The MCP server it calls, so a person does not have to paste the page into the chat.

Tools and sensors. The actions it may take, and the check that comes back. Search the sources. Ask a question. Confirm the citation is the page you just edited.

Guardrails. Who may call the server, which sources stay inside the company, and which pages a person still approves before they are public.

Guides tell the agent how to behave. Tools tell it what it may do. Guardrails tell it where to stop. Context is the material those three are about. That is the part a technical writer, a docs engineer, and a context engineer own.

What you place where the agent can ask

Three decisions, and then a server.

Which pages this task may read. The published guide, the repository, the spec, the PDF. A search of the public web returns whatever already ranks. Your server returns the page you chose, and the answer names that page.

What is loaded every session, and what is asked for. Voice and "one page per task" belong in the short guide. The docs themselves belong on the server. A guide that contains the whole site makes every later task carry pages it does not need.

When a source matters even if the question never names it. A style guide does not contain the words "release note." A release note still has to follow it. You say so in a sentence: when the task is a public page, a release note, or a sample, use the style guide.

MCP Studio by Appa Tools is where that server is built. You add the source. You write the retrieval rule in the same words you would use with a colleague. You describe a custom tool for the question the team keeps asking, such as the shortest example of a task and the page it came from. The agent calls one endpoint. Each answer cites the page.

A technical writer writes the page and the guide. A docs engineer checks that the question cites the page they just edited. A context engineer refreshes the source when the page changes, and reads the questions that came back with nothing useful in your sources. A developer advocate puts the current quickstart where a sample can ask for it, then follows those steps before publishing the sample. A vibe coder pastes the docs URL, connects the editor, and asks one question they already know the answer to. When the citation is their docs, they build.

What you can check

Ask a question you already know the answer to. The citation should be your page. Ask a second question that should use the style guide and does not say "style guide." The style guide should be in the answer.

A private design doc or a private repository goes on a private server, which answers only with an access token. The agent drafts. A person publishes.

The server returns what you placed on it. A decision that lives only in a meeting informs nothing until someone writes it down. Another MCP server you connect is read from. It is not a set of actions that change that other product. On any account, the dashboard shows how often a server is asked. The passage behind each answer is part of Action analytics, described in the analytics guide.

The recipes for each role, in this order, are in the harness engineering cookbook. Build the server from a docs URL, a repository, or a file in MCP Studio. The source guide covers what you can add. The same placement, seen from the writer's job, is what a context engineer puts in front of the model.