Case packet
Neutral case identifier: case-d88171537c6fb6
The possible directed relationship from Artifact A to Artifact B is under review.
Artifact A
Design for the first-time human, except on access cost
A useful default when designing any system an LLM agent consumes is to treat the agent as a competent human using the system for the first time. Most of what makes a system good for a newcomer — clear naming, discoverable organization, orientation cues, honest labels, readable prose — serves the agent equally well, and human ergonomics are easier to reason about than agent behaviour. So the newcomer human is a cheap, reliable proxy for the agent: a default, not a law, holding where the two consumers share a profile and breaking where their profiles diverge.
The sharpest divergence, and the one with a clean fix, is access cost. A competent human reads a large artifact sublinearly — skim the headings, scroll to the region, Ctrl-F to the few lines that matter — so a large but well-organized artifact stays cheap. An agent reading that same artifact pays linearly: every byte enters [bounded context] whether it is relevant or not, and the irrelevant bulk adds interference, not just volume. So an artifact that is cheap for a newcomer human can be context debt for the agent, and you cannot read the agent's cost off human ergonomics.
The real divider is access mode, not human versus agent: sublinear, paying only for the slice you consult, versus linear, paying for every byte. Humans default to sublinear because their tooling makes it the path of least resistance; agents default to linear because the cheapest primitive is "read the whole thing into context." But that pairing is not fixed — an agent given a query or search interface reads sublinearly, and a human handed an unstructured blob reads linearly.
So the fix is not to pick a winner between the consumers. Give each a materialization with sublinear access over the slice it needs, behind a single source of truth: a human gets a rendered, browsable view with find-in-page; an agent gets a scoped query or search path. A large reference index, for instance, need not sit on the agent's default read path to earn its keep — it can be materialized for the human and reached by the agent through a query instead, routed to the consumer whose access mode makes it cheap, not deleted.
Access cost is not the only place the proxy breaks: agents also treat read text as possible instruction where a human treats it as inert, and confabulate where a human would ask. This note isolates access cost because it has a clean structural fix — not because it is the most frequent exception.
Relevant Notes:
Artifact B
LLM context is a homoiconic medium
In the LLM context window, instructions and data share the same representation — natural language tokens. A system prompt, a user message, a tool output, and a piece of content being analyzed are all just text. There is no type-level distinction between "program" and "data." This is homoiconicity: the medium used to express programs is the same medium used to express the data they operate on.
Precedents
Lisp's homoiconicity. Code and data share the same representation — lists. A list is both a data structure you can inspect and a program you can evaluate. In an LLM-based system, a markdown file is both content you can read/link/analyze and instructions you can hand to a sub-agent for execution. Lisp macros — code that writes code — map to instructions that produce reports containing further instructions. Quote/eval — toggling between treating something as data vs executing it — maps to reading an instructions note vs handing it off.
Emacs as ad hoc extension culture. Emacs is written in Elisp — the system and its extension language are the same thing, so there is no boundary between built-in functionality and user extensions. The init file mixes configuration and ad hoc programs. The constraining trajectory is the same: inline snippet in init.el → extracted function → published package. The KB's equivalent: [ad hoc instructions note → extracted skill → registered tool].
Smalltalk's live image. The image is both the program and the development environment, and you modify the running system from inside itself using the same language. The KB has the same property — its methodology is written in the same markdown it operates on.
Other homoiconic languages. Prolog (programs are clauses in the same database as facts), Tcl (everything is a string, including code), Rebol/Red (code is data blocks), XSLT (XML transforming XML). All share the property that the boundary between using and extending the system is fluid.
What homoiconicity enables
The common thread across these systems: blurring the boundary between using and extending makes the system more adaptable than systems with rigid extension points. In the KB, [ad hoc prompts extend the system without schema changes] precisely because instructions and content share the same medium. No registration, no type system gatekeeping, no compilation step — write a markdown file and it's both content and executable spec.
What homoiconicity costs
The same lack of boundary that enables extensibility creates hazards:
Scoping failures have no guardrails. [LLM context is composed without scoping] — and homoiconicity makes it worse, because there is no structural way to distinguish "this is a binding the sub-task should see" from "this is leftover from an earlier computation." Both are just tokens. The [constraining gradient from instructions to scripts] is one response — codifying practices into deterministic code imposes structural boundaries that the homoiconic medium itself does not provide.
Prompt injection. The most direct consequence: if instructions and data are the same medium, data can contain instructions. This is the LLM equivalent of SQL injection, and it exists for the same structural reason — the program/data boundary is conventional, not enforced.
Discoverability. Emacs's .emacs files are notoriously personal and opaque, Lisp macros can make code unreadable, and ad hoc instructions notes are invisible unless you know they exist. When everything can be both program and data, it's hard to know what a system actually does.
Relevant Notes:
- [context efficiency is the central design concern in agent systems] — intensified by: homoiconicity means instructions and data compete as equal tokens, removing any priority mechanism for protecting instructions from dilution
Under-review context phrase
the closing text-as-instruction exception rests on there being no program/data boundary in the window, so any loaded text can act as instruction