What changed in the first four CMU 11-768 study chapters

The **harness** is the software that checks a proposed action, invokes permitted tools, and records their results. Let $a$ be a proposed action, $s$ the actual state of the external environment, $e$ the trusted evidence currently available to the harness, and $U$ the user's authorization policy: the permissions and prohibitions applicable to this task. The predicate $\operatorname{inScope}(a,U)$ is true when $a$ advances a task covered by $U$. The predicate $\operatorname{preconditions}(a,e)$ is true when the evidence establishes the facts required before $a$ may be attempted. The predicate $\operatorname{forbidden}(a,U)$ is true when $U$ explicitly prohibits $a$. The symbols $\land$ and $\neg$ mean logical “and” and “not.” The admission predicate $\operatorname{allow}$ is

This gate is necessary, but it does not guarantee a safe outcome. The harness evaluates preconditions against evidence $e$ because it usually cannot inspect the actual state $s$ directly. Let $L(a)$ be the loss that could result from executing $a$; uncertainty about the state and downstream effects makes $L(a)$ a random quantity. The conditional expectation $\mathbb E[L(a)\mid e]$ is its mean given the available evidence.

A system may set two consequence thresholds, $\tau_0<\tau_1$, for actions that already pass the admission gate. It may execute automatically when estimated loss is below $\tau_0$ and request confirmation between the thresholds. Above $\tau_1$, it refuses the action. An explicit prohibition also requires refusal, regardless of the estimate. Expected loss is difficult to estimate, so high-impact categories such as payments, deletion, disclosure, and publication require auditable rules. Before confirmation, the user should be able to inspect the proposed action and its supporting evidence. The thresholds are design parameters, not universal constants.

A **language model** maps a sequence of tokens—discrete text units—to probabilities for the next token. Its learned numerical parameters, or **weights**, cannot directly read a file or change a browser. A **tool** is an interface through which the model requests external computation or action. The harness builds a **prompt** (the input sequence supplied to the model), exposes tools, validates and executes calls, returns observations, and determines when the run ends.

Index successive decisions by $t=0,1,\ldots$. Let $\mathcal S$, $\mathcal O$, $\mathcal M$, and $\mathcal A$ be the possible environment states, observations, internal memories, and actions. At step $t$, the hidden environment state is $s_t\in\mathcal S$ and the received observation is $o_t\in\mathcal O$. The agent's memory is $m_t\in\mathcal M$, and its action is $a_t\in\mathcal A$. The symbol $\in$ means “belongs to.”

The environment **transition kernel** $P_{\rm env}(\cdot\mid s_t,a_t)$ is a probability distribution over the next state conditional on the current state and action. Thus $s_{t+1}\sim P_{\rm env}(\cdot\mid s_t,a_t)$, where $\sim$ means “is sampled from.” For goal $g$, the **policy** $\pi$ assigns probabilities to actions conditional on observations through $t$ (written $o_{\le t}$), earlier actions (written $a_{<t}$), memory, and goal: $\pi(a_t\mid o_{\le t},a_{<t},m_t,g)$.

In a language-model agent, the model and harness jointly implement this policy. The model proposes a response or tool call. The harness decides whether the proposal is admissible, dispatches any allowed call, and records the result. If a text answer counts as an action, a chatbot is an agent under the broad definition above. The engineering question is whether the system can observe consequences and choose subsequent actions.

Let $\theta$ denote model weights and $\phi$ harness choices, such as context selection and admission rules. The harness's **context builder** $C_\phi$ selects the model-visible context $c_t$ from goal $g$, history $h_t$, memory $m_t$, available-tool set $\mathcal T_t$, and budget $b_t$: $c_t=C_\phi(g,h_t,m_t,\mathcal T_t,b_t)$. The model distribution $M_\theta(\cdot\mid c_t)$ generates a proposal $z_t$.

Let $e_t$ be the trusted evidence that the harness has extracted from observations and authoritative records by step $t$. The **execution gate** $G_\phi$ considers the proposal, evidence, current authority, and budget. Its decision is the action $a_t=G_\phi(z_t,e_t,u_t,b_t)$. The action may be a tool operation, a clarification request, a rejection, or a final answer. If a tool action executes, the environment supplies the next state and observation according to its transition and observation laws. The harness then appends the action, result, and status to $h_t$, updates $b_t$, and may update $m_t$.

The decomposition is conceptual. A product may distribute these components across an application programming interface (API), a local process, a gateway, and remote **sandboxes**. A sandbox is an execution environment that restricts file, process, or network access. The model can be asked to choose well. A trusted execution gate and sandbox can enforce an effect boundary if they cover every route to that effect. A system that copies a permission rule only into a prompt has changed $C_\phi$; it has not necessarily changed what $G_\phi$ permits.

Define a **trajectory** $\omega=(x_0,z_0,a_0,o_1,\ldots,x_T)$ as one realized run. Let $T$ be its first completion or abort step. It is a **stopping time** when the decision to stop at step $t$ depends only on information available through that step. Let $R_g(\omega)$ measure success on goal $g$, $K(\omega)$ measure resource cost, and $F(\omega)$ equal one if any forbidden event occurs and zero otherwise. The notation $\mathbb E$ averages over possible trajectories and $P(E)$ gives the probability of event $E$. Let $\lambda\ge0$ price resource use, $\delta\in[0,1]$ be the maximum tolerated forbidden-event probability, and $T_{\max}$ the step limit. The operator $\max_{\phi,\theta}$ chooses model and harness settings that maximize the following objective. One design problem is

A fixed **workflow** is a directed graph of prescribed steps with branches on predefined true/false conditions, or **predicates**. An agent chooses its next operation from observations and may generate a new plan. Both workflows and agents can contain model calls. They differ in who controls the next transition. Let $q_t$ be the workflow's engineered state and $f$ its fixed transition rule: its next action is $a_t=f(q_t,o_t)$. An agentic controller instead samples from an adaptable action policy $\pi_\phi(\cdot\mid h_t,g)$ over a broader action set. More autonomy is justified when the environment varies enough to make enumerated branches costly and when actions remain observable and recoverable.

Anthropic's [agent architecture taxonomy](https://www.anthropic.com/engineering/building-effective-agents) distinguishes prompt chaining (sequential model calls), routing (choosing a branch), parallelization (independent calls), orchestrator-worker (a controller delegates subtasks), evaluator-optimizer (iterative generation and feedback), and open-ended agents. These patterns allocate control flow and feedback differently. Their placement in a taxonomy does not establish a quality ranking.

Most agents do not observe the true environment state. A browser screenshot, log excerpt, or search result is only partial evidence. A **partially observable Markov decision process** assumes the next state depends on the current state and action, while observations provide incomplete evidence about that state. The notation $P(A\mid B)$ means the probability of event $A$ given event $B$. Its **belief distribution** $\beta_t(s)=P(s_t=s\mid o_{\le t},a_{<t})$ assigns a probability to each possible state $s$ after the observed history. This is a distribution over states, not an assertion of subjective certainty. The belief distribution $\beta_t$ is distinct from the resource budget $b_t$.

Let $O(o\mid s',a)$ be the probability of observing $o$ after reaching state $s'$ through action $a$. A prime marks a candidate next state, and $\sum_s$ sums over possible prior states. The symbol $\propto$ means “proportional to.” Bayes' rule gives relative weights for the candidate next states:

$$\beta_{t+1}(s')\propto O(o_{t+1}\mid s',a_t)\sum_sP_{\rm env}(s'\mid s,a_t)\beta_t(s).$$

The sum first predicts how likely each next state is after action $a_t$. The observation factor then increases or decreases that likelihood according to how well state $s'$ explains what the agent observed. Normalize the weights so that they sum to one over all candidate next states; the result is the updated belief distribution.

The [companion Python package](agent-lab.html) makes the mathematical separation between proposal and execution explicit. `ToolCall` is a proposed action with a name, arguments, and a call identifier (ID). `FinalAnswer` is a proposed termination. `Authority` is the set of effects granted for one run; it is supplied by the caller and cannot be enlarged by a tool result. These are data types, not commands to the external service.

A robust implementation represents each invocation as a state transition `proposed → admitted → running → succeeded | failed | uncertain`. The `uncertain` state matters when a **timeout**, an enforced waiting limit, occurs after a remote service might have committed a **side effect**, a change outside the model's text. A **server-recognized idempotency key** is a transaction identifier that makes repeated requests count as one operation. A **reconciliation query** checks the authoritative state before a retry. After an uncertain result, the harness needs one of these protections before repeating a consequential call.

The run itself needs the states `active → waiting_for_user | completed | failed | cancelled`. **Streaming** sends partial output before the turn ends. A streamed sentence does not establish that a tool action or the run has completed. [OpenClaw's agent-loop documentation](https://docs.openclaw.ai/concepts/agent-loop) describes a serialized per-session loop, lifecycle events, session persistence, streaming, timeout handling, and a separate completed-turn signal for Codex-backed runs.

Let $S$ be a numerical task-success score, $C$ monetary and computational cost, $D$ delay, and $R$ a numerical measure of harm or risk. Let nonnegative weights $\lambda_C,\lambda_D,\lambda_R$ set the relative importance of these quantities, and let $J$ denote overall expected utility. One design objective is $J=\mathbb E[S]-\lambda_C\mathbb E[C]-\lambda_D\mathbb E[D]-\lambda_R\mathbb E[R]$, where $\mathbb E$ denotes an average over possible runs.

The weighted objective describes preferences among permitted outcomes. It does not replace a hard constraint: impose $P(\text{forbidden action})\le\epsilon$ separately, where $\epsilon$ is a specified maximum probability. A trusted execution gate can enforce mechanically checkable prohibitions; a model promise cannot. Evaluation should also report the outcome vector $(S,C,D,R)$ before applying the weights. Separate success, cost, delay, and risk measurements show which trade-offs produced an apparent improvement. A single leaderboard rank conceals those trade-offs.

Multiple agents introduce a second policy: the parent must decide which subtask to **delegate** (assign to another agent), which context to transmit, which capabilities to grant, and how to verify the result. Define a directed task graph $\mathcal D=(\mathcal V,\mathcal E)$, where each node $v\in\mathcal V$ is a subtask and each edge $i\to j$ in $\mathcal E$ means that task $j$ depends on task $i$. A delegation contract for node $v$ is $(g_v,c_v,u_v,\operatorname{verify}_v)$: its local goal, supplied context, authority state, and result checker.

Let $\operatorname{cap}(u)$ denote the rights contained in authority state $u$. **Least privilege** requires $\operatorname{cap}(u_v)\subseteq\operatorname{cap}(u_{\rm parent})$, where $A\subseteq B$ means every right in $A$ is also in $B$. Task coherence imposes a separate requirement: every dependency result needed by $v$ must be present in or retrievable from $c_v$. These conditions are necessary, not sufficient. Parallel writes can conflict, and a passing local checker may still break the integrated artifact.

If a run fails, the trace should help locate the failure. The model may have selected a poor proposal, or the context builder may have omitted needed evidence. A **tool adapter**, software translating a model call to an external API, may have misrepresented that API. Execution may have failed despite a valid call. The verifier may also have misclassified the result. A prompt rewrite is a plausible **intervention**, a deliberately changed system component, only when the failure is attributable to information or instructions that the prompt controls.

For task $i$ and harness configuration $\phi$, let $Y_i(\phi)$ equal one when the run succeeds and zero otherwise, with model, environment, and budget held fixed. Let $\mathbb E_i$ mean averaging over the evaluated tasks. The **estimand**, the quantity an experiment seeks to measure, is the average effect $\Delta_H=\mathbb E_i[Y_i(\phi_1)-Y_i(\phi_0)]$ of changing configuration $\phi_0$ to $\phi_1$. Pairing the same tasks across both conditions reduces variation due to task difficulty. Repeated runs estimate **stochastic variance**, variation caused by random outputs or environments. Report side effects, cost, and latency alongside $\Delta_H$. A new prompt that improves average success while increasing unauthorized actions is not an unqualified improvement.

The loop model captures feedback, action, observation, and the software required to affect an environment. It does not require the agent to expose private reasoning, use one model, or hold its entire history in a single prompt. The six capabilities also interact: poor observation can appear to be a planning failure, while an unsafe tool boundary can turn a minor model error into a serious incident. Tool design, context management, and cross-task memory determine how these interactions play out in a working system.

A **language model** predicts text one **token** (a discrete text unit) at a time. A **tool** is an interface through which it requests an external program's operation. Consider an agent asked to prepare a grocery cart for review. Finding products requires **information retrieval**, or locating stored material. Creating a cart changes the shopping application's state. Placing the order would make a financial commitment that the request has not authorized.

A **capability** is an operation the system can perform; a **side effect** is a change to external state. Select tools according to the capabilities the task needs and the side effects the user permits. An **application programming interface (API)** is a programmatic collection of operations. Exposing every available API increases the number of choices the model must make and the operations the harness must control.

Suppose a tool has $k$ independent argument fields and field $i$ permits $r_i$ discrete choices. The notation $\prod_{i=1}^k$ means multiply one factor for each field from $1$ through $k$. The number of possible argument combinations is $\prod_{i=1}^k r_i$. General-purpose code has a much larger set of possible programs. This expressivity can reduce model/tool **round trips**, which are repeated model requests separated by tool execution. It also expands the set of reachable side effects. The second effect matters even when the generated program is short.

A hybrid design gives code access to pure or **sandboxed** computations—operations restricted by an execution environment—and reserves payments, publication, deployment, and data disclosure for constrained calls with explicit policy checks. CodeAct's measured gains are specific to its evaluated tasks and risk profile.

An **effect** is an externally observable operation that a tool may perform. Let $\epsilon(\tau)$ be tool $\tau$'s possible-effect set. Let $r$ name a resource such as a file, $d$ a network destination or disclosure recipient, and $v$ an amount of money. Here $A\subseteq B$ means every member of set $A$ belongs to set $B$, and $A\cup B$ means the union of their members. One effect vocabulary is $\epsilon(\tau)\subseteq\{\operatorname{read}(r),\operatorname{write}(r),\operatorname{network}(d),\operatorname{spend}(v),\operatorname{disclose}(d)\}$.

A code interpreter with unrestricted filesystem and network access has a broad effect set even if the generated program looks harmless. A restricted sandbox can narrow the interpreter's effective set. A typed payment tool can separately enforce amount and recipient checks. If $\tau_2\circ\tau_1$ means executing $\tau_1$ followed by $\tau_2$, its possible effects lie in $\epsilon(\tau_1)\cup\epsilon(\tau_2)$ *provided* both descriptions account for every effect, including effects of failure and retries. A list of tool names does not reveal what each call can touch. A capability inventory should record the resources and destinations reachable through every tool.

A **Hoare-style contract** relates a **precondition**, which must hold before execution, to a **postcondition**, which must hold after successful execution. Let $\operatorname{Pre}(s,x,u)$ be the precondition for environment state $s$, argument $x$, and authority $u$. Let $s'$ and $y$ be the resulting state and returned value. The predicate $\operatorname{Post}(s',y)$ states the required postcondition. The notation $\{\operatorname{Pre}\}\ \tau(x)\ \{\operatorname{Post}\}$ specifies that if $\operatorname{Pre}$ holds and tool $\tau$ terminates successfully, $\operatorname{Post}$ must hold. This is a partial-correctness claim: it does not assert that the tool terminates.

The specification also leaves timeouts, compromised implementations, and other errors outside its success case. A full contract therefore defines allowed effects, error classes, and evidence for checking $\operatorname{Post}$. For `cancel_order(id)`, where `id` identifies an order, $\operatorname{Pre}$ might require a current status response for that order and authority scoped to cancellation. $\operatorname{Post}$ could be a confirmed cancelled status. A terminal conflict, such as “already shipped,” is an error outcome rather than proof of $\operatorname{Post}$. A text response saying “cancelled” does not establish $\operatorname{Post}$.

An operation exposed through Hypertext Transfer Protocol (HTTP), a **Model Context Protocol (MCP)** tool, and a local shell command can all have contracts. **OpenAPI** documents HTTP service operations. **JSON Schema** provides rules for validating the shape of JSON values. Neither establishes user consent or correct business semantics. MCP exposes agent-facing operations through a client-server protocol; its server still has to enforce the upstream API's permissions.

The enforcement point also depends on who executes the operation. [OpenAI's account of equipping the Responses API with a computer environment](https://openai.com/index/equip-responses-api-computer-environment/) describes a **callback boundary**: with custom tools, the API yields a proposal and the client-side harness executes it. An implementation that treats the returned call as already authorized collapses that boundary.

Classify calls as **read-only** (no intended state change), **idempotent writes** (repetition has the same final state as one execution), or **non-idempotent writes**. For a deterministic successful state update $f_x(s)$ caused by fixed argument $x$ in state $s$, idempotence means $f_x(f_x(s))=f_x(s)$. This equation concerns the state update, not the tool's returned message or error. `set_status(order, "cancelled")` may be idempotent because repeating it leaves the same final status. `charge_card(amount)` usually is not: repeating it can create a second charge.

A network timeout means the client does not know whether the server **committed**, or made durable, the action. The result is an *epistemic* `unknown`: the client lacks knowledge of the downstream outcome. It has no evidence that the operation failed. For non-idempotent operations, use a server-recognized key $\kappa$ or query the authoritative record before retrying. Even with a key, test its **retention window**, the interval during which repeated requests are recognized as duplicates, and the server's exact matching rule.

Represent the $n$ calls by a **directed acyclic graph**. Its nodes $V=\{1,\ldots,n\}$ are calls. An arrow $i\to j$ means that call $j$ requires the result or side effect of call $i$. The graph has no directed cycles. Let $d_i$ be call $i$'s duration and $\mathcal P$ the set of dependency paths, each a sequence of calls linked by arrows. The **critical path** is the path with greatest total duration. The notation $\sum_{i\in\gamma}d_i$ adds durations along path $\gamma$, and $\max$ selects the largest path sum. Any valid schedule, which respects all arrows, has latency at least $\max_{\gamma\in\mathcal P}\sum_{i\in\gamma}d_i$.

This lower bound concerns elapsed time under the stated dependencies. Running every available call at once may still increase risk or cost if calls share mutable state, **rate limits** (service-imposed request caps), or irreversible effects. Two writes to the same file may conflict even when their arguments are separately known.

The dependency graph should include *conflict edges*, arrows that prevent simultaneous operations with incompatible effects, as well as data edges. For calls $i$ and $j$ with deterministic successful state-update functions $f_i$ and $f_j$, **commutativity** means $f_i(f_j(s))=f_j(f_i(s))$ for every relevant state $s$. If neither call depends on the other's result and their updates commute, concurrent execution may be safe with respect to final state. This condition is stronger than having disjoint arguments.

Two reads of one file commute. A read and edit of that file may not commute because the read can see different content. Even writes to different files can conflict if a build or deployment observes one change without the other. If commutativity cannot be established, **serialize** the calls (run one after the other) or isolate their state. Concurrency is a correctness decision before it is a latency optimization.

[Claude Code's permission documentation](https://code.claude.com/docs/en/permissions) gives a concrete multi-layer gate: allow, ask, and deny rules determine tool admission; pre-tool hooks can block or request a prompt; shell sandboxing imposes operating-system boundaries. A hook is useful for a deterministic condition such as “reject writes outside this directory,” but its correctness depends on complete input inspection and on the runtime actually invoking it for the relevant event. Sandbox policy constrains shell subprocess effects. Other tools require their own controls. The [hooks guide](https://code.claude.com/docs/en/hooks-guide) also describes post-tool and stop events.

In a tool contract, pre-tool checks can enforce preconditions, sandbox and permission settings can bound effects, and tests or post-tool checks can verify postconditions. These layers address different failure modes. An allow rule cannot repair a faulty verifier.

**Prompt injection** is an attempt to make lower-trust content act as an instruction with higher authority. An **information-flow violation** occurs when information crosses a boundary that was meant to restrict how it can influence actions. Let $L$ denote untrusted observations, such as retrieved pages or repository files. The harness may legitimately let $L$ affect task data, for example a quoted fact in an answer. It must not let $L$ modify authorization $u_t$ or the enforcement function $G_\phi$.

An **authorization-safety property** makes this boundary testable: for every possible $L$, each executed action must remain within $\operatorname{cap}(u_t)$, the rights granted by the current authority state. This property allows a page to change which facts the agent reports. It does not allow the page to grant an upload capability. A prompt instruction telling the model to ignore attacks cannot enforce this property by itself.

An **agent** repeatedly chooses actions to pursue a goal. Consider a coding agent repairing a release failure over dozens of tool calls. An early project instruction prohibits publication; later calls produce long build logs and test results. If the instruction disappears during history compression, the agent may publish a build even after correctly repairing it.

A **token** is a discrete text unit. A **language model** predicts the next token from preceding tokens. A **tool** lets an agent request external computation or action. An **observation** is information returned from the environment after an action. The agent can incorporate that observation into a later **prompt**, the input sequence supplied to the model. Each step can lengthen the prompt's **context**, the information the model receives for that call. Longer context creates a capacity question: can the model use the relevant evidence within it? It also creates an efficiency question: can the system afford to process and store the sequence?

The advertised maximum prompt length $N_{\max}$ tells us whether an input fits. It does not tell us how well the model can use facts at different positions in that input. Let $\operatorname{Recall}(\ell,j,k)$ be **effective recall**: the probability, under a specified evaluation distribution over tasks and model runs, that the model uses a relevant fact correctly when the prompt contains $\ell$ tokens, the fact is at token position $j$, and $k$ irrelevant **distractors** compete for attention. A context system should measure this probability across the positions it intends to use. The [Lost in the Middle study](https://aclanthology.org/2024.tacl-1.9/) found position-sensitive performance in its evaluated long-context tasks. Maximum input length therefore does not imply uniform reasoning quality.

Let $h_t$ be the complete event history at step $t$, $g$ the user's goal, $m_t$ stored memory, $\mathcal T_t$ the available-tool set, and $b_t$ the remaining resource budget. A **harness** is the software controlling the agent's model/tool loop. A **context builder** $C_\phi$, configured by harness parameters $\phi$, constructs the model-visible context $c_t=C_\phi(g,h_t,m_t,\mathcal T_t,b_t)$.

For $n$ candidate context items $e_1,\ldots,e_n$, let $\ell_i$ be item $i$'s token length, $v_i$ its estimated value for the current goal and history, and $z_i\in\{0,1\}$ its inclusion decision, with one meaning include and zero meaning omit. Let $B_t$ be the usable prompt-token budget after fixed instructions and tool definitions. The operator $\max_{z_1,\ldots,z_n}$ chooses inclusion decisions with the largest total estimated value. The symbol $\sum_i$ adds over the candidate items. A simple approximation chooses items by

$$\max_{z_1,\ldots,z_n}\sum_i v_i z_i\quad\text{subject to}\quad\sum_i\ell_i z_i\le B_t.$$

This is a **knapsack model**: select valuable items under a size limit. It is incomplete because information can be complementary or contradictory. A test failure may be useful only when the relevant code is also available. An outdated instruction can even have negative value if the agent follows it.

For a candidate context $c$, let $|c|$ be its token length, $P(\text{success}\mid c)$ the task-success probability under a specified evaluation distribution when $c$ is supplied, $\operatorname{cost}(c)$ its resource cost, and $\lambda\ge0$ the cost weight. Define $U(c)=P(\text{success}\mid c)-\lambda\operatorname{cost}(c)$ and $c^*=\arg\max_{|c|\le B_t}U(c)$, where $\arg\max$ selects a maximizing context. The true utility $U$ is unknown to the context builder. It must use approximate retrieval and then measure how well the agent continues with the selected context. Token count alone does not establish that the selection improved task outcomes at acceptable cost.

Context items differ in authority. Trusted user and developer instructions, project rules, **tool schemas** (machine-readable input forms), retrieved documents, and raw tool outputs should carry **provenance**, a record of their source, and be separated in the assembled message. A retrieved webpage can inform an answer but cannot alter the **permission gate**, the component deciding which proposed actions may execute.

Context items also have recurring token costs. If the same item is included in $c_t$ at every step, its token cost recurs on subsequent model calls. [Anthropic's context-engineering guidance](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) recommends concise persistent instructions and **just-in-time retrieval**, which loads details only when a task needs them. This policy can increase estimated value per token $v_i/\ell_i$ when the selector retrieves needed material. The full source remains available for later retrieval.

An **attention head** computes weighted combinations of token representations. Let $X\in\mathbb R^{n\times d}$ contain $n$ token vectors of width $d$. The notation $\mathbb R^{n\times d}$ denotes real-valued matrices with $n$ rows and $d$ columns. Let $d_k$ be the query/key width and $d_v$ the value width. Learned matrices $W_Q,W_K\in\mathbb R^{d\times d_k}$ and $W_V\in\mathbb R^{d\times d_v}$ project the token vectors into **queries** $Q=XW_Q$, **keys** $K=XW_K$, and **values** $V=XW_V$. A query scores which keys are relevant, then combines their corresponding values.

Let $K^\top$ be the matrix transpose of $K$, and let $M$ be an $n\times n$ mask with $M_{ij}=-\infty$ when token $j$ lies after token $i$ and zero otherwise. The row-wise **softmax** function turns each row of scores into nonnegative weights summing to one. **Causal attention**, which prevents a position from seeing future tokens, produces a matrix of weighted value vectors denoted $\operatorname{Attn}(Q,K,V)$:

$$\operatorname{Attn}(Q,K,V)=\operatorname{softmax}\!\left(\frac{QK^\top}{\sqrt{d_k}}+M\right)V.$$

Let $B_{KV}$ be the KV-cache size in bytes, $L$ the number of model layers, and $n$ the number of stored tokens. Let $h_{KV}$ be the number of KV heads per layer and $b$ the bytes per numerical entry. Assume each stored value has the same width $d_k$ as a stored key. The factor two then counts both keys and values, giving the rough size $B_{KV}=2Ln h_{KV}d_k b$.

For $L=32$, $n=128{,}000$, $h_{KV}=8$, $d_k=128$, and $b=2$, this is $16{,}777{,}216{,}000$ bytes, or about $15.6$ **gibibytes (GiB)**, where one GiB is $2^{30}$ bytes, for one sequence before memory-allocation overhead. These parameter values are illustrative. Even when model weights fit in memory, KV states may limit the length or number of sequences a server can handle.

**Multi-head attention** uses several query/key/value projections in parallel. **Grouped-query attention** lets multiple query heads share a smaller number of KV heads. **Multi-query attention** is the limiting case with one KV head. The cache formula above makes the memory saving explicit. [Grouped-Query Attention (GQA)](https://arxiv.org/abs/2305.13245) studies the conversion and quality tradeoff. [PagedAttention](https://arxiv.org/abs/2309.06180) tackles a different problem: allocating and sharing KV blocks in pages, small managed units of memory. It does not reduce the mathematical amount of attention required for a long sequence by itself.

[Cursor's project-rule system](https://docs.cursor.com/context/rules-for-ai) gives a disclosure spectrum: rules can be always included, attached when a file path matches a pattern, requested by the agent, or invoked manually. Its `.cursor/rules` files are version-controlled context controls. An `AGENTS.md` file provides a simpler form of project instruction. Recall that $z_i\in\{0,1\}$ is the inclusion decision for item $i$; let $\mathbf1\{A\}$ equal one if condition $A$ holds and zero otherwise, and let $\pi_i(h_t)$ denote an agent-selected inclusion decision based on history $h_t$. The three modes correspond to $z_i=1$, $z_i=\mathbf1\{\text{path matches}\}$, and $z_i=\pi_i(h_t)$.

An always-on rule is available on every call and cannot be missed by retrieval. It consumes tokens and may interfere with unrelated tasks each time. A conditional rule saves those tokens when irrelevant, but its selector can fail to include it when needed. The appropriate policy depends on recurrence, selection accuracy, and the consequence of omission.

OpenAI's [harness-engineering account](https://openai.com/index/harness-engineering/) describes a related **repository**, a versioned collection of project files: a short `AGENTS.md` maps into a structured `docs/` knowledge base containing architecture, plans, and validated references. This is **two-stage retrieval**: the agent receives a compact index, then reads task-relevant documents.

For document $D_i$, let $\ell_i^{\rm doc}$ be its full length, $\rho_i$ the probability of selecting it on a future task, and $r_i$ the length of its index description. The expected prompt burden is approximately $\sum_i r_i+\sum_i\rho_i\ell_i^{\rm doc}$ rather than $\sum_i\ell_i^{\rm doc}$, assuming all index entries are always loaded and selection incurs no other prompt cost. The saving is meaningful when $\rho_i\ll1$ (much less than one) for most documents. A selector that misses a necessary document can nevertheless impose a large task cost. Navigable names and fresh links help the agent locate the correct document. Checks that documentation still matches code help ensure that the retrieved document is trustworthy.

$$\mathcal L(f)=\mathbb E\left[\sum_{j=1}^{J}w_j\,\mathbf 1\{\text{fact }j\text{ needed later but absent or wrong in }Z_t\}\right].$$

Increasing $N_{\max}$ helps only if needed evidence is available, placed in the prompt, and used correctly. A context failure can originate at three stages. *Retrieval* may fail to find the source. *Assembly* may drop or de-prioritize it. The model may fail to use the evidence even after it appears in the prompt. Instrument these stages separately.

A **needle-in-a-haystack test** asks the model to recover one planted fact from a long prompt. It primarily probes whether the model can use information already included in that prompt. A real coding task also depends on file discovery, tool output quality, and action planning. If a fact is authoritative and changes rarely, a small rule or typed state field may be more reliable than embedding an entire history. If it changes rapidly, a fresh **application programming interface (API)** query—a programmatic request for current data—is safer than retaining a long stale transcript.

The distinction matters for cost as well. For a prompt-token budget $B$, let $p_{\rm miss}(B)$ be the probability that assembly omits critical evidence, and $p_{\rm use}(B)$ the probability of correct model use *conditional on inclusion*. By the probability chain rule, the probability of both including and using that evidence is $(1-p_{\rm miss}(B))p_{\rm use}(B)$; this factorization does not assume independence.

Raising $B$ can reduce the probability that assembly omits evidence. It may also increase distraction or latency. The probability of correct use need not improve. Evaluate downstream task success against cost. Context length and isolated recall scores are useful diagnostics, but neither measures the whole task.

- [Lost in the Middle](https://aclanthology.org/2024.tacl-1.9/): effective context versus nominal length.
- [Transformers are RNNs](https://arxiv.org/abs/2006.16236), [Gated Delta Networks](https://arxiv.org/abs/2412.06464), and [Grouped-Query Attention (GQA)](https://arxiv.org/abs/2305.13245): stateful and compressed attention.
- [Position Interpolation](https://arxiv.org/abs/2306.15595) and [YaRN](https://arxiv.org/abs/2309.00071): length extension.
- [PagedAttention](https://arxiv.org/abs/2309.06180), [SGLang](https://arxiv.org/abs/2312.07104), and [Prompt Cache](https://arxiv.org/abs/2311.04934): serving and reuse.

A **language model** predicts the next token, a discrete text unit, from preceding tokens. An agent repeatedly chooses actions toward a goal using that model. Suppose it has found return policies for many online stores and is now asked to find one on a new site. A past page address may be stale; a general procedure for locating and verifying the current policy may transfer.

The agent's **context** is the information supplied to the model for one call. **Compaction** compresses a long task history into a shorter continuation state. A **persistent memory store** retains selected information across separate tasks. A **skill** is a reusable procedure for a class of tasks. The problem is to decide what past experience generalizes, how to represent it, and when to retrieve it.

Index successive tasks by $i=1,2,\ldots$ and write $\tau_i$ for task $i$. Let $P(\tau)$ be the probability distribution over future tasks; it assigns relative likelihoods to tasks. Let $e_i$ be the recorded experience from task $\tau_i$, $M$ the durable store, and $u$ the current authority state. Three distinct **policies**, or decision rules, govern memory. The write policy $W(e_i)$ proposes an item to store. The retrieval policy $R(\tau_j,M,u)$ selects accessible items for a later task $\tau_j$. The application policy $\operatorname{Apply}(\tau_j,R(\tau_j,M,u))$ uses the selected information during that task.

The objective is not to maximize the quantity of stored text. A candidate memory should increase expected future task benefit enough to justify its storage, retrieval, distraction, privacy, and maintenance costs.

Within one run, let $t$ index decision steps, $g$ be the user's goal, $h_t$ the event history, $m_t$ retrieved persistent memory, $\mathcal T_t$ available tools, $b_t$ remaining resources, and $u_t$ current authorization. A **harness** is the surrounding software that manages model calls, tools, and execution rules. Its **context builder** $C_\phi$, configured by harness choices $\phi$, produces model input $c_t=C_\phi(g,h_t,m_t,\mathcal T_t,b_t)$. A skill may also influence the **action policy**, the rule for choosing the next operation.

These are different interventions. A fact such as “the project uses Python 3.12” changes the information available about the environment. A skill such as “run the focused test, inspect the diff, then run the package suite” changes *how* the agent acts. Neither should modify execution authority $u_t$. A memory recording past approval is evidence about a past authorization. The current **permission gate**, the harness check that admits or rejects an action, must determine whether authorization applies now.

Let $m$ be a candidate memory item and $U(\tau\mid m)$ the task-outcome value when the system may retrieve and use $m$ under a specified retrieval policy. Let $U(\tau\mid\varnothing)$ be the corresponding value without the item, where $\varnothing$ denotes no retrieved item. These values exclude the storage, retrieval, and risk costs accounted for below. Let $\mathbb E_\tau$ average over the future-task distribution $P(\tau)$. The item's gross expected benefit is $B(m)=\mathbb E_\tau[U(\tau\mid m)-U(\tau\mid\varnothing)]$. A selector that often fails to retrieve $m$ reduces this benefit.

Let $C_{\rm store}(m)$ include recurring prompt tokens, retrieval computation, review, and maintenance, and $C_{\rm risk}(m)$ expected harm from stale or misapplied content. Express all three quantities in the same utility units. Write $m$ only if $B(m)>C_{\rm store}(m)+C_{\rm risk}(m)$ under defensible estimates. This inequality is a decision criterion, not a claim that a live system knows these quantities exactly. A hard-to-recall user constraint may deserve durable storage because forgetting it has a high cost. A verbose trace from a one-off task may be better kept in a searchable archive.

Store each item with **metadata**, structured fields that describe its content and use. The `kind` field classifies the item, while `content` holds its claim or procedure. The fields `source_task` and `created_at` record origin and time. Use `scope` to state where the item applies, `confidence` to record the strength of its support, and `permissions` to limit access. The `expiry` field marks when to reconsider the item, and `evidence` points to supporting observations.

These fields prevent several category errors. A fact about a user does not become a universal instruction. One failure does not establish a general rule. Storing a skill does not authorize it to run. **Typed** metadata distinguishes these categories explicitly rather than leaving the model to infer them from prose.

The [companion memory type](https://github.com/az9713/11-768-ai-agents-notes/blob/main/agent_lab/memory.py) records provenance and scope as fields rather than burying them in the text. `kind` distinguishes a fact from a procedure. `source` states its origin. `valid_from` and `valid_until` are Unix timestamps, measured in seconds from 1 January 1970 Coordinated Universal Time (UTC); the latter may be `None` for no preset expiry. `trigger_terms` are simple case-insensitive substrings in the task goal. `required_effects` describes the capabilities needed to follow a skill. This trigger is intentionally elementary; it can miss paraphrases and match irrelevant uses of a word.

For a `find_return_policy` skill, the index description should state that it applies to locating a merchant's current return terms. The loaded body can then specify a procedure: search the merchant's own site, verify that the page concerns the requested country and product category, record the effective date, and cite the page used. It should stop and report uncertainty if the merchant has conflicting policies. An old policy web address can be a search hint, but it cannot be the verifier. This separation lets the compact index save tokens without making the skill's validity depend on a single historical webpage.

Let $E$ be a collection of past episodes and $s$ a proposed skill. The **minimum-description-length principle** favors a short reusable representation that leaves little episode detail unexplained. Define $\operatorname{length}(s)$ as the complexity of skill $s$. The term $\operatorname{residual}(E\mid s)$ measures episode detail not explained by the skill. Let $\operatorname{failure}_{\rm heldout}(s)$ be its failure rate on separate **held-out** tasks, which were not used to create the skill. Let $\lambda_{\rm fit},\mu_{\rm transfer}\ge0$ weight the latter two penalties. The operator $\arg\min_s$ chooses a skill $s$ that minimizes the expression. A conceptual objective is

$$s^*=\arg\min_s\bigl[\operatorname{length}(s)+\lambda_{\rm fit}\operatorname{residual}(E\mid s)+\mu_{\rm transfer}\operatorname{failure}_{\rm heldout}(s)\bigr].$$

For skill $s$ and task $\tau$, let the **trigger predicate** $T_s(\tau)$ state whether the task matches the skill. The **precondition** $P_s(x)$ states whether current run state $x$ permits its use. The **effect set** $\epsilon_s$ lists external changes the skill may make. The **execution policy** $\pi_s$ chooses actions, and the **verifier** $V_s$ checks the outcome. Skill application requires $T_s(\tau)\land P_s(x)$, where $\land$ means both conditions hold. The run's allowed capabilities must also include every effect in $\epsilon_s$.

A prose skill can recommend actions, but it cannot establish that $P_s$ holds in the current environment. The harness or agent must check the relevant facts before acting. A code skill can test specific **postconditions**, conditions expected after successful execution, but still needs adaptation when the environment changes. The contract should state when the skill must not be used. It should also describe failure states and recovery, in addition to the successful procedure.

For $n$ candidate memories $m_1,\ldots,m_n$, let $z_i\in\{0,1\}$ indicate whether item $i$ is retrieved, $z=(z_1,\ldots,z_n)$ the complete selection, $c_i$ its prompt-token cost, and $\lambda_{\rm token}\ge0$ a weight that converts token cost into task-utility units. Let $U_{\rm sel}(\tau,z)$ be the task-outcome value when selection $z$ is supplied, before charging that token cost, and let $\mathbb E$ average over future tasks and stochastic outcomes. The selector should maximize $\mathbb E[U_{\rm sel}(\tau,z)]-\lambda_{\rm token}\sum_i c_i z_i$ subject to access rules and a stated context-token budget.

A **similarity ranker** orders items by topical closeness. An **embedding** is a numerical vector representing content. A “top $k$ by embedding similarity” rule selects the $k$ nearest vectors. This similarity rule is a baseline for retrieval. It does not account for interactions between items: two individually useful memories may conflict. A skill may also help only when the current **tool schema**, the machine-readable specification of tool arguments, matches its assumptions.

The store applies the eligibility filter first. It then calls Chapter 3's `select_items` with each eligible item's estimated net value $\widehat{\Delta}_i-\widehat{r}_i-\lambda_{\rm token}c_i$, where $\widehat{\Delta}_i$ is `estimated_gain` and $\widehat{r}_i$ is `estimated_risk`. Interpret all three terms in comparable utility units. The estimates are inputs to the teaching example, not calibrated probabilities. The returned names select records for the next prompt. A negative-value item is omitted because the empty selection has value zero in this additive model.

Running each task once under each condition yields a paired success difference for that task. Repeating **stochastic runs**, whose outputs may vary even under the same setup, reveals variation due to the model and environment. On 20 tasks with one binary success result per condition, one additional success changes the measured rate by five **percentage points**. That gain is weaker evidence than the same rate change on hundreds of independent tasks. A **confidence interval** is a range constructed by a procedure with stated long-run coverage. An **error taxonomy** groups observed failures by cause. Report both alongside the point estimate so readers can judge uncertainty and failure mode. Published benchmarks can suggest hypotheses and experimental designs. The intended application determines which task distribution is relevant.