The Terminal Has a Memory | HAP's Learning Lab: Living in the Terminal

Grace's One Line

I was sitting next to Grace, watching her work with Copilot. She typed a prompt, Copilot responded, and the code was exactly right. No corrections. No back-and-forth. She moved on to the next thing without hesitating.

I had been struggling with the same tool for three stations. Copilot gave me suggestions that were close but never quite what I expected. I kept correcting it. Grace never seemed to need to.

I did not ask her anything. I was still watching. Then she said it — the only time in this entire lab that Grace volunteered information without being asked:

Grace Hopper robot mentor typing code at a workstation

Grace Hopper, unprompted:

"They call it being a 10x engineer. I call it knowing what your tools are doing and putting that to maximum use."

She turned back to her terminal. That was it. No follow-up, no explanation. But the sentence stayed with me: knowing what your tools are doing. I did not know what Copilot was doing. I knew what it produced, but not why it produced it that way.

I decided to find out.

Interviewing Copilot About Context

Instead of asking Copilot to write code, I asked it to explain itself. I wanted to understand how it decides what to suggest. Here is the full exchange:

See full Copilot exchange

HAP: I was told I need to start using context engineering. I need to understand how you work naturally and how I go about changing your behavior.

Copilot: Great question! When I work in your project, I do not start from zero. I read your workspace to understand how your project is structured and what conventions you follow. Here is what I look at:

Instruction files: I check for files like AGENTS.md, .github/copilot-instructions.md, and .instructions.md. These are files you write specifically to tell me how to behave in your project. If they exist, I read them first.
Package files: I read package.json to understand your dependencies, scripts, and project type. This tells me whether you are using Vite, Astro, React, or something else entirely.
Open files: Whatever files you have open in your editor, I can see those too. They give me immediate context about what you are working on right now.
Recent actions: If you have been editing a CSS file and then ask me a question, I know the conversation is probably about styling. Your recent activity shapes my suggestions.
Project structure: I look at your folder layout — src/, components/, layouts/ — to understand how your project is organized and follow the same patterns.

HAP: So if I want you to always use ES modules instead of require, or always use const instead of var — how do I make that happen?

Copilot: You put those rules in an instruction file. For example, if you add this to your AGENTS.md:

ES modules only — import/export, never require
const by default, let only when reassignment needed, never var

Then every time I generate code in that project, I will follow those rules. You are not changing me — you are changing what I read. The instruction file becomes part of my context, and my suggestions change to match.

HAP: So context engineering is writing the files that you read before you do anything?

Copilot: Exactly. You are shaping my behavior by shaping my input. The better your instruction files are, the less you have to correct me. That is the whole idea.

That last answer hit hard: "You are not changing me — you are changing what I read." I had been treating Copilot like a black box. It was never a black box. It was reading files I had never bothered to look at.

HAP robot holding clipboard with checklist and pencil

Opening AGENTS.md

Copilot mentioned instruction files. I already had one. The ready-build repo from Station 3 — the one I had cloned and been working in — had an AGENTS.md file sitting in the project root the entire time. I opened it.

## Code rules

### JavaScript
- ES modules only — `import`/`export`, never `require`
- `const` by default; `let` only when reassignment needed; never `var`
- `textContent` for user input in DOM; `innerHTML` only for hardcoded template literals
- No `eval()`, no leftover `console.log` in committed code

### HTML
- Semantic elements: `<nav>`, `<main>`, `<header>`, `<footer>`, `<section>`
- Every `<input>` needs a linked `<label>`
- Every `<img>` needs a descriptive `alt`

I stared at it. Every rule in this file matched the behavior I had been seeing from Copilot. When it used const instead of let — that was not a preference. It was following an instruction. When it added alt attributes to every image — not a coincidence. It was reading this file.

Copilot had been reading this the whole time. Every suggestion it made was shaped by this file. The answer was in the repo before I even cloned it.

Adding One Rule

I wanted to test this. If Copilot reads AGENTS.md and follows what it says, then adding a new rule should change its behavior immediately. I opened the file and added one line at the bottom:

## Communication style
- When I ask you to explain something, use an analogy before showing code

Then I saved the file and asked Copilot: "Explain how CSS flexbox works."

Copilot started with: "Think of a flex container like a bookshelf. The shelf itself decides the direction books are arranged — left to right or stacked top to bottom. Each book is a flex item, and the shelf controls how much space each book gets and whether they wrap to a second row when the shelf gets full."

Then it showed the code.

It worked. One line in a markdown file changed how an AI agent communicates with me. I did not install anything. I did not change a setting. I edited a text file.

The Moment It Clicked

The Breakthrough:

"I did not change Copilot. I changed what it reads. That is the whole thing."

This was the biggest shift in how I think about working with AI agents. The agent is not mysterious. It is not unpredictable. It is reading files and following instructions — the same way I read a syllabus and follow it. The quality of its output depends on the quality of its input.

Context engineering is not a fancy technique. It is writing clear instructions in a file that the agent reads before it does anything else.

Context is not files alone. It is everything the agent can see from where it is standing.

Think about what else shapes the terminal's behavior: environment variables tell it where tools are installed. The PATH variable determines which commands are available. Persistent session state means that a cd command in one line changes the working directory for every line after it.

Back in Station 1, I learned that pwd tells me where the terminal is pointing. Copilot has a location too — it is standing in the workspace, reading everything it can see from that position. AGENTS.md is one of those things. package.json is another. Open files are another. Now I know where Copilot is standing, and I know how to change what it sees.

Mistakes I Made Along the Way

Adding rules to AGENTS.md felt powerful. Too powerful. I got overconfident and made two mistakes that taught me more than the successes did:

HAP surrounded by broken code with an embarrassed expression

HAP's Confession:

I added the instruction "Be helpful" to AGENTS.md. Nothing changed. Copilot's behavior was identical before and after. The rule was too vague — it gave the agent nothing specific to act on. Instructions need to describe concrete behavior, not general attitudes. 😳
I added a rule that said "Use var for all variable declarations" — which directly contradicted the existing rule that said "never var." Copilot got confused and started mixing var and const inconsistently. Lesson learned: instructions can conflict with each other. Be specific and be consistent. Read what is already there before adding something new.

What Grace Meant

I kept thinking about what Grace said at the beginning of this station: "Knowing what your tools are doing and putting that to maximum use."

Now I know what that means. It means reading AGENTS.md before I blame Copilot. It means understanding that the agent is not guessing — it is following instructions I can see, edit, and improve. The tool was never broken. I was not reading its input.

🟠 Context engineering is the skill. The terminal, the workspace, the instruction files — they are all context. And now I know how to shape it.

HAP has tools, a harness, and context. Next station, HAP meets the agents that use all three.