Harness Engineering

I start from the behavior I actually need from an agent working in the workspace. Once I know that, I configure the harness to produce it. This strategy is known as "Working Backwards."

Working Backwards

"Working backwards" is a planning direction, not a step backward. It means naming the outcome I need from the agent first, then configuring the harness to produce it. This strategy forces me to build the harness around a real need, instead of starting from a list of available tools and hoping one fits.

I use it because there is no off-the-shelf harness for our internal framework and workspace. Starting from the tools already on hand means reaching for whatever is closest instead of what the task actually needs.

In practice, that means each of the following needs is stated on its own first, then followed by the specific harness piece, custom tool, guide, or sensor, that answers it.

Custom Tools for a Framework

I need an agent that writes framework-conformant code on the first try, not code I have to rewrite. Our internal Lambda framework has conventions no public model has trained on:

• How controllers, services, and modules wire together.
• How auth guards get applied.
• How DynamoDB access is structured.

The harness answers with a custom MCP server, one I built specifically for this framework.

• Three tools, one each for the controller, service, and module layers, generate framework-conformant boilerplate on request instead of leaving conventions to be inferred from scattered examples.
• The framework's own docs are served as MCP resources instead of static files, so the agent pulls documentation on demand rather than carrying it in every prompt.
• A design-system MCP, for the same reason.

Steering the Agent Before It Acts

I need an agent that never touches a secret, and never re-litigates permission for a command already proven safe. Asking for the same approval on every call trains me to click approve without reading, which defeats the point of asking.

The harness answers with allowlists, denials, and on-demand context, set once at the workspace level.

• Execution commands already proven safe (test, build, and lint commands) are pre-allowlisted, removing repeated permission friction for exactly the commands that need none.
• Anything npx-prefixed stays gated, since it can resolve and execute arbitrary packages. Harness engineering isn't only about reducing friction. It's choosing where friction should stay.
• A workspace-wide security baseline denies read and write access to env files, secrets, and configs, so no individual project can loosen it by accident.
• Skills load workspace conventions on demand, design tokens, API framework rules, backlog workflow, house copy style, so the agent has the right context before it writes anything.

Catching What Slips Through

I need mistakes caught before they reach a reviewer, not after. Guides prevent most of the obvious ones, but scope creep and small copy leaks are easier to catch by inspecting the result than by steering the process.

The harness answers with dispatched review agents, run as a focused, isolated pass over the actual output.

• One review agent flags scope creep against the product roadmap's staged boundaries.
• Another enforces that every feature spec ships with a diagram.
• A third catches competitor names or comparison framing leaking into public-facing copy.

Observation Without Another Inference Pass

I need to read state and results back quickly, without paying for another model call just to check on something. Not every check needs to be smart. Most just need to be fast and correct.

The harness answers with deterministic, script-backed tooling, kept separate from the review agents above.

• Backlog status scripts, pre-allowed by absolute path, for reading task and plan state.
• Dev-preview and screenshot capture, wired per project, for seeing an actual rendered result.
• Monitor and TaskOutput for reading results back from dispatched agents in the background.