The agent harness: designing the environment your AI works in

Hi, Hoya here.

We've finally reached the last part of this series. There's something about making a series and actually finishing it that makes me keep fussing over the final post, haha.

Anyway, while deploying in the last part, you probably repeated the same steps several times. Today we'll turn those steps into a single command, then go a little further: designing the environment the AI works in.

1. What is a harness?

You may have seen people calling this harness engineering. A harness is the layer around a model that runs the work loop, provides tools, manages approvals and context, and checks the results.

Here's the funny thing: you've already been building one. Look back at the previous five lessons through that lens:

So today isn't about starting something completely new. It's about deliberately designing what you've been doing all along.

Even with the same model, that environment changes the work. Do you explain the rules in every conversation, or does the agent load your project instructions? Do you describe the same procedure from scratch, or invoke it in one line? Does a dangerous command run immediately, or stop for approval? Those differences add up.

A little aside: I've been revising this post for two or three weeks now. I've been busy lately... Have you seen REA, Reverse Engineer Anything? It connects agents to tools for investigating how programs work, including established binary-analysis tools. What interests me is the combination: existing analysis tools become part of a workflow an agent can carry out. That's a concrete example of why the surrounding system matters. Use such tools only on software you own or have permission to analyze, within the applicable terms.

2. MCP: a place to plug in tools

How does something like REA actually connect those tools to an agent? That brings us to MCP, the Model Context Protocol.

Think of it as a USB-C port for AI applications. Instead of building an entirely different connection for each application, a server can expose capabilities through a shared protocol. Compatible clients can use that connection, though setup and supported features still vary. REA, for example, offers an MCP interface to its analysis tools.

The things you connect might be:

• Tools: hands that operate a browser, query a database, or run an analysis program.
• Data sources: reference material from somewhere like Notion, Google Drive, or a calendar.

MCP is an open protocol, rather than a feature belonging to one coding assistant. Like the project instructions from part 4, it gives you something you can carry between compatible tools. You'll still need to check each client's configuration, permissions, and support.

But remember one thing: every connected tool gives the agent another hand. More hands mean more things it can do, and more ways it can make a mess. Before installing an MCP server, ask the question from part 5: "What can this do with my keys and my data?" Knowing the name and the idea is enough for today.

3. Skills: put a repeated procedure in a file

If MCP gives an agent hands, a skill gives it know-how.

Start by writing down the steps you kept repeating while deploying. Your list might look something like this:

1. Check that secret-bearing .env files aren't going into the commit.
2. Update requirements.txt.
3. Commit and push.
4. Check the deployment platform's logs.
5. Open the app while logged out and verify that private data isn't visible.

Are you going to remember that every time? I couldn't, haha. Write it down once, then call it when you need it. That's the idea of a skill: a procedure the AI can read when the task calls for it.

There's good news here too. Agent Skills is an open format. A skill lives in a folder with a SKILL.md file, optionally accompanied by scripts, references, and assets.

The installation folder depends on your client and whether the skill belongs to one project or your whole account. You'll encounter paths such as .claude/skills/ and .agents/skills/; check your own tool's documentation for the location it actually reads. The portable part is the skill's content and format, though a procedure may still depend on specific tools being available.

It's the same basic idea as AGENTS.md in part 4. Keep the knowledge in a file you can take with you. I've also found that giving an assistant a skill I'd already written and asking it to install it for another service can save the manual copying. Check where it puts the files, then make sure the new client discovers them.

And yes, those folders starting with a dot are hidden folders. This is one of the reasons I asked you to turn on hidden-file visibility back in part 1.

Here's a small SKILL.md example:

---
name: deploy-check
description: Check for exposed secrets and deployment prerequisites. Use before deployment, deploy, or push.
---
# Before deployment

## Procedure
1. Run git status to see the current changes.
2. Run git ls-files -- .env '.env.*' to list matching files in the index.
   Inspect the list: a template with placeholder values is different from real secrets.
3. Run git diff --cached and review the staged changes for secrets.
   Also inspect relevant tracked code and configuration for embedded credentials.
4. Check that requirements.txt matches this project's dependencies.
5. If there is a problem, stop and report it to the user before deployment.

git status alone doesn't tell you whether an unchanged .env is already tracked. And a search for one prefix such as sk- can't prove there are no secrets: keys have different shapes and can appear in other files. Reviewing the tracked files and the staged diff is a better starting point. If a real credential has already been committed or exposed, leaving it out of the next commit isn't enough; revoke or rotate it.

The two required frontmatter fields are the key, especially description. It helps the agent decide when the skill is relevant. A vague description can leave it unused; one that's too broad can make it turn up in the wrong place. Write what it does and when to use it together.

When I first tried this, I wrote only "deployment-related work" and then spent ages wondering why it never got called. Adding words that might actually appear in the request, such as "deployment," "deploy," and "push," made it much easier to trigger. The next section explains why that little description matters so much.

4. Progressive disclosure: a library, not every book open at once

Hang on. If you create ten or twenty skills, won't the AI slow down because it has to read them all? I wondered about that too. The format is designed around progressive disclosure:

1. Discovery: make the skill's name and description available.
2. Activation: read the full SKILL.md when the task calls for it.
3. Additional resources: load referenced files when they become necessary.

Think of a library. You look through the catalog, then take out the book you need. You don't open every book before you start.

That keeps unused instructions out of the working context, although a growing catalog still has some overhead. The practical advice from the skill authoring guide is to keep the main file under about 500 lines and put detailed reference material in separate files. The less often something is needed, the less reason there is to load it up front.

5. Workflows: the reference book and the button

There's another idea that's similar to a skill, but useful to distinguish by how you call it:

The boundary depends on the product. Some clients let you invoke the same skill directly with a command as well as letting the agent select it; others have different workflow features or invocation syntax. Claude Code's skills documentation is one example of how a client implements both automatic and explicit use. Don't assume every client supports /name in the same way.

For designing your own process, though, asking who starts it is a useful distinction.

For example, you could define a /ship workflow with these steps:

1. Summarize the changes and show them to me.
2. Run the deploy-check skill.
3. If it finds a problem, stop here and report it.
4. Propose a commit message and get my approval.
5. Once approved, commit and push.

For the learning workflow we're building here, step 4 matters. If automation quietly removes the approval point, we've lost the habit we practiced in part 3. Also remember that pushing may trigger a deployment, depending on how the project is connected.

6. Approval policies: you turn the autonomy dial

You decide how much freedom to give the agent. I think of it in three rough levels. These are a way to reason about permission, rather than setting names shared by every product:

In part 1, the rule was "don't approve a command you don't understand." Client permissions and sandbox settings can help enforce that boundary, depending on what your tool supports. An instruction file alone isn't an access-control system.

The question I come back to is: can I undo this?

A current Git commit makes it easier to recover tracked code. It doesn't undo a remote deployment, refund a payment, restore deleted database records, or recover an untracked file. Those actions need their own permissions and recovery arrangements. Be stricter when the agent can affect the outside world, and check the reach of connected MCP tools too. More hands should make you think harder about where the dial belongs.

There's also something called a hook: a rule that runs automatically at a particular point. Depending on the tool, it might check for secret files before a commit or block a dangerous command before execution. For now, knowing these exist is enough. Look them up when you actually need one. No over-engineering; we've been saying that throughout this course, haha.

7. Six lessons, six layers of control

Let's put the whole series on one page. There's been one thread running through it: each lesson gives you control over another part of the work.

In part 1, you typed pwd yourself. Today you're designing the environment the AI works in. That's how far we've come over these six lessons.

8. What stays when the tools change

This is what I've thought about most while writing the series. If all I teach is how to click through a particular tool, that lesson can be out of date in a year.

What changes: tool names, screens, shortcuts; model versions and usage limits; companies and prices.

What stays: a feel for paths and files; the habit of leaving yourself a way back; reading and approving a plan; keeping rules in files; knowing where to draw the line around secrets.

AGENTS.md, Agent Skills, and MCP give us open formats or protocols for parts of that work. When you change tools, take the instructions, procedures, and connections with you, and check what the new client supports. That's why I've tried to keep this series from depending on one particular product.

For a final assignment, take one small project from beginning to end yourself:

Create a folder → git init → write AGENTS.md → request, review, and approve a plan → implement → run it yourself and verify it → commit → check for secrets → deploy → share the link.

Keep it to about an hour's worth of scope. A personality quiz or a lunch-menu roulette is enough. Keep it small. No over-engineering.

And one last thing. Honestly, it's impossible to keep everything in this series in mind all the time. I can't do it either. When I'm in a rush, I sometimes skip a commit or approve a plan without reading it...

But paying even a little attention makes a real difference.

If you keep just one habit, commit your work. A safe checkpoint gives you somewhere to return to when the code goes wrong. Keep the separate checks for secrets and outside-world actions too; those consequences can outlive the code change.

Thank you for following along through all six parts. See you in your own projects! 🎉

Keep going!

Sources

• Agent Skills overview and format specification: the portable skill format, metadata, and progressive disclosure.
• Anthropic: Skill authoring best practices: descriptions, concise instructions, and reference files.
• Claude Code: Extend Claude with skills: one client's installation and invocation conventions.
• Model Context Protocol introduction: connecting AI applications to external capabilities.
• REA official repository: its MCP interface and program-analysis workflow.
• Git: git-ls-files and git-diff: inspecting indexed files and staged changes.