What Happens When You Press Enter

It’s Thursday morning. I have a 1:1 with Ana after lunch and I haven’t prepped. I have no idea what she’s been working on, I forgot what we discussed last time, and the meeting is at 2pm. I open Claude Code and type: prep for my 1:1 with Ana

You: prep for my 1:1 with Ana

  ◈ google_calendar > list_events("next 2 days")
    Today: Sprint Planning (10am), 1:1 with Ana (2pm), Platform Sync (4pm)
    Tomorrow: Design Review (10am), Team Retro (3pm)

  ■ Read notes/
  ⚡︎ use obsidian-cli for vault searches

  ■ $ obsidian-cli search "Ana" --vault ~/notes --since 14d
    3 entries: project handoff, blocked card, team retro feedback

  ■ Read people/ana.md
    role: tech lead · last interactions: discussed tech radar presentation
    style: direct, values prep

  ◈ slack > search_messages("Ana", last 7 days)
    5 messages: deployment blocker, design review feedback, team retro follow-up

  ▶ prep-1-on-1
    - The handoff is still in progress — ask where it stands
    - She flagged a blocked card 4 days ago — check if it's resolved
    - Retro feedback mentioned team morale — worth following up

  ■ Write 1-1-prep-ana.md

  Prep written to 1-1-prep-ana.md. Want me to adjust anything?

■ tool — ◈ mcp — ⚡︎ hook — ▶ skill

I typed nine words. The agent read my calendar, searched my notes, checked Slack, pulled a profile, and wrote a prep doc. How?

You sent a prompt

Your prompt is the nine words you typed: prep for my 1:1 with Ana. But what arrived wasn’t nine words. It was about 10 tokens — chunks of text, sometimes a whole word, sometimes part of one.¹ prep is a token. for is a token. my is a token. 1:1 gets split into three: 1, :, 1.

Those 10 tokens are your prompt. But they didn’t arrive alone.

Before you pressed enter

An agent like Claude Code has two parts: a model and a harness.² The model produces text. The harness is the program around it that executes actions and feeds results back. Codex and Cursor work the same way: different harnesses, same idea.

flowchart LR
    subgraph Agent
        direction LR
        M["Model"] -- "produces tokens" --> H["Harness"]
        H -- "executes tools, 
        feeds results" --> M
    end

flowchart LR
    subgraph Agent
        direction LR
        M["Model"] -- "produces tokens" --> H["Harness"]
        H -- "executes tools, 
        feeds results" --> M
    end

Before your prompt arrived, the harness had already packed over 8,000 tokens into the context window — everything the model can see at once.³

• Behavior instructions you never see — the system prompt⁴
• Notes from previous sessions — memory⁵
• Your project directory and git state⁶
• Descriptions of every tool the model can ask the harness to run — file operations, shell access, search⁷
• Third-party integrations like your calendar and Slack, connected via MCP⁸
• Reusable workflows called skills, loaded as one-line descriptions⁹
• Your project conventions, loaded from instruction files¹⁰
• Hooks — scripts that fire before or after certain actions, running outside the model entirely¹¹

All of it is text. All of it is tokens. Your 10 tokens landed among 8,000 others, and together they became the model’s entire world.

Text in, text out

Here is what the model does with all of it.

The model has a vocabulary — tens of thousands of possible tokens. Given the full sequence in the context window, it produces a probability distribution over that vocabulary: every possible next token gets a score. The model samples one. That token gets appended to the sequence. The model runs again, conditioned on the longer sequence. Samples the next. And the next. And the next.¹²

That is how LLMs work, nothing more. The model does not think. There is no internal “Ana had a deployment blocker this week, I should check if it’s resolved before the 1:1.” It produces the next token. Then the next. Then the next. Until the response is complete and the harness takes over.

Each token is shaped by every token that came before it. When those 8,000 tokens include a tool description for google_calendar and your message asks about a 1:1 with Ana, the next tokens will probably describe a call to that tool. Not certainly — probably. That distinction matters. The tool description is what made the right call probable. Just another set of tokens shifting the distribution.¹³

This process is non-deterministic. Same input, different result every time. The model does not always select the highest-scoring token. If it did, every response would be identical: safe, repetitive, predictable, and the text would start repeating itself. Sampling is what lets the model produce novel combinations: code it was never trained on, connections between ideas that weren’t adjacent in its training data, different approaches to the same problem on different runs. The non-determinism is not a side effect. It is the source of everything useful the model does.

But non-determinism means the result is never guaranteed. The model might follow your instructions. It might not. You cannot control it the way you control a program. You can only make certain results more probable by shaping what the model receives. That is the fundamental constraint this entire series is built on: the model is non-deterministic, and every component you’ve seen in this trace is a different strategy for channeling that — making the right results probable, and protecting the parts that need to be exact.

The trace, explained

The model received the context — 8,000+ tokens assembled by the harness, plus your 10 — and produced its first response. Not a prep doc. A tool call: text that says “run google_calendar > list_events.” The model didn’t access the calendar. It produced text describing the action. The harness read that text, executed the call, and added the result to the context. Then the model produced its next response, now conditioned on the calendar data.

That is the pattern for every step. Let’s walk through them.

[mcp] google_calendar > list_events

My Google Calendar is connected via MCP — a protocol that lets agents call third-party tools over a standardized interface.⁸ The harness sent the request, got five events back, added them to the context. The model now knew about the 1:1 at 2pm.

[tool] Read notes/ → [hook] use obsidian-cli

The model tried to read my notes directory using Read, a built-in tool.⁷ But a hook intercepted it — a script I configured to fire before any Read, Grep, or Glob call.¹¹ The script checks whether the path targets my personal vault. If so, it blocks the read and suggests the Obsidian CLI instead:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Read|Grep|Glob",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/vault-guard.sh"
      }]
    }]
  }
}

#!/bin/bash
if echo "$TOOL_INPUT" | grep -q "Documents/Vault\|notes/"; then
  echo '{"hookSpecificOutput":{"permissionDecision":"deny","permissionDecisionReason":"Use obsidian-cli for vault searches"}}'
fi

The model didn’t ask for this redirection. The hook blocked the call and injected the suggestion back into the context. This is what makes hooks different from instructions: instructions are suggestions the model might follow. Hooks are code that runs regardless of what the model produces.

[tool] $ obsidian-cli search "Ana"

The model’s next response, now conditioned on the hook’s suggestion, produced a shell command via the Bash tool instead of a file read. The harness executed it and added the search results — three entries about Ana from the last two weeks.

[tool] Read people/ana.md

A built-in tool. The harness read the file from disk and added Ana’s profile to the context: her role, last interactions, working style.

[mcp] slack > search_messages

Another MCP call. The harness sent the request to my Slack server. The server searched for recent messages involving Ana. Five messages entered the context.

[skill] prep-1-on-1

A skill — a reusable workflow written in a markdown file that I can invoke by name.⁹ At startup, only its one-line description was loaded. Now the harness loaded the full content: what information to gather, how to structure the prep, where to pause for input. The model produced the prep doc following this structure.

[tool] Write 1-1-prep-ana.md

A built-in tool. The harness wrote the file to disk.

The agent loop

Seven tool calls. Four different types. One hook interception. The model produced text at every step — tool calls, not actions. The harness executed all of it. Nine words in, prep doc out. Ready before lunch.

That cycle — model produces a response, harness executes the actions in it, results feed back as context, repeat — is the agent loop.^{14 15 16}

flowchart LR
    G["Gather"] -- "read context" --> A["Act"]
    A -- "call tools" --> O["Observe"]
    O -. "repeat" .-> G

flowchart LR
    G["Gather"] -- "read context" --> A["Act"]
    A -- "call tools" --> O["Observe"]
    O -. "repeat" .-> G

Most of it was computational: the calendar fetch, the CLI search, the file reads, the file write, the hook checking a path pattern — deterministic operations, same input same output every time.¹⁷ The inferential parts were the model’s decisions: which tool to call, what arguments to pass, how to synthesize Ana’s profile and Slack messages into a prep doc. The computational parts are reliable. The inferential parts are where the non-determinism lives, and where context engineering has the most leverage.

The loop does not care what kind of task it is running. Whether it is prepping a 1:1, running tests, or reviewing code, the mechanism is identical. What changes is the context.

The context window grew

flowchart LR
    subgraph before ["Before you type"]
        direction LR
        SP["System Prompt"] ~~~ I["Instructions"]
        I ~~~ T["Tool Descriptions"]
        T ~~~ M["Memory"]
    end
    before --> C["Context Window"]
    subgraph during ["During the session"]
        direction LR
        P["Your Prompt"] ~~~ TR["Tool Results"]
        TR ~~~ SK["Skill Content"]
    end
    during --> C

flowchart LR
    subgraph before ["Before you type"]
        direction LR
        SP["System Prompt"] ~~~ I["Instructions"]
        I ~~~ T["Tool Descriptions"]
        T ~~~ M["Memory"]
    end
    before --> C["Context Window"]
    subgraph during ["During the session"]
        direction LR
        P["Your Prompt"] ~~~ TR["Tool Results"]
        TR ~~~ SK["Skill Content"]
    end
    during --> C

Each tool result entered the same shared space: the context window. The calendar response, the search results, Ana’s profile, the skill content, the prep output. All of it added tokens.

Context windows range from around 200,000 tokens to over 1 million.¹⁸ The exact number matters less than the principle: the window is finite, and everything in it competes for space. A verbose response wastes tokens that could hold your code. A long instruction file crowds out tool results.

When the window fills up, the harness compacts: summarizing older content to make room. Your instructions survive compaction. Conversation details from an hour ago may not.¹⁹

Context engineering

Nine words. No mention of which calendar, which Obsidian vault, what format. The model produced the right tool calls because the context made them probable. Tool descriptions told it what was available. Instructions shaped how to use them. The skill defined the workflow. The hook enforced the right path. The harness executed those calls and fed results back.

The nine words worked because the context was already engineered to make the right results likely.

Prompt engineering is getting a good response by writing a better message. Context engineering is designing the system that assembles the context — before the session starts and at every turn. Harness engineering is one form of it: building the components — tools, instructions, skills, hooks — that assemble the context for coding agents.¹⁷

Every decision behind that trace is something you can customize: which tools to connect, what to put in your instructions, which skills to build, which hooks to wire. Those decisions shaped the probability distribution. The nine words just triggered the sampling.

What you’re looking at

You can now name every part: the MCP call to my calendar, the hook intercepting a Read, the CLI search, the built-in file read, the Slack lookup, the skill orchestrating the prep, the Write saving the output. The harness executed all of it. The model produced text. And I showed up to my 2pm prepared.

That is the agent loop. The model is non-deterministic. You cannot control its output directly. But you can shape what goes into the context, and that shapes what comes out. The question this series answers: what should be in the context, and when?

Next: Building Your AI Toolkit — the model is non-deterministic. The toolkit exists to shape what it produces. Each capability is a different strategy for channeling that.