What a harness is

A solution engineer’s output is not code. It is a pipeline of artifacts: account research, discovery questions, findings, a data model, sample data, demo environments, click-paths, scripts, and leave-behinds. That pipeline is the job. Everything a demo becomes was one of those artifacts first, and every one of them can be produced, checked, or rehearsed by an agent.

That is the whole thesis of this field manual. Not “use AI to write your app” — you are not writing an app. Use agents to run the pipeline of artifacts that a customer engagement actually consists of, and run all of it in one place.

Why VS Code, not a chat tab

A chat tab is a good place to ask a question and a poor place to run a pipeline. The artifacts are files; they have versions; they are produced by agents that need tools; and the whole thing has to be governed on a managed laptop. VS Code is the one surface where all of that meets: instructions that shape every response, custom agents with scoped tools, MCP servers that reach real systems, a terminal, and version control — in one window. Agent mode is generally available for every Copilot user now^⊙ , so the harness is not a preview you are gambling on; it is the default way of working.

The moment your work lives in files instead of a scrollback, three things become possible: you can diff it, you can review it, and you can hand it to another agent. A finding that traces to a quote, a data model that traces to a finding, a demo beat that traces to a success criterion — traceability is only free when the artifacts are files.

The engagement is a repo

The organizing pattern of this manual is one private git repo per customer engagement. The engagement is the spine; the harness is the payload wrapped around it. For our worked example that repo is contoso-financial/, and it is fully specified later in the pack — numbered folders for each stage of the pipeline, an instruction stack that encodes the rules, an agent roster, and the MCP config that plugs the whole thing into real systems.^⊙

Instructions in that repo are always on: they are how you tell every agent the non-negotiables — cite your claims, never put customer data of record in the repo, seed anything you generate. You write them once and they shape everything after.

What “state of the art” means here

This manual is dated on purpose. Everything it asserts about a real product was verified against a primary source on July 6, 2026, and every page carries that as-of date. The AI ecosystem changes monthly; a claim that was true at the top of a release wave can be renamed by the bottom of it. Treating the date as part of the fact — not a footnote to it — is the single most important habit this manual tries to teach. When a claim here has a fact mark, it resolves to a source you can re-check.

In the field

Open a new folder in VS Code and write two files: a README.md with one sentence naming the pipeline of artifacts your next real engagement will need, and an empty .github/copilot-instructions.md. You will fill the second one in a couple of lessons. For now, just make the repo exist — the harness begins as a place, not a prompt.