Publication · July 29, 2026

Context Is an Engineering Surface: How AI Agents Read a Website

AI agents that edit real client websites are only as good as what they can see, and what they can see is itself an engineering surface with its own failure modes, tests, and incidents. This note documents that surface through one week of our engineering record, July 22-29, 2026, together with one measurement that followed: a compiled strategy pack with one canonical writer, a read-order index whose silent overwrite made two context briefs invisible to every agent, a 24,000-line decomposition that made a new class of analysis structurally possible, a pipeline whose context aged in queues rather than in computation, and a content draft whose cost was dominated by reading, not writing.

10 min readJuly 29, 2026Heck of a Website Engineering

Context Is a Surface, Not a Prompt

The SEO Command Center (the autonomous SEO platform we build inside Zyan, our software arm) dispatches AI agents that perform consequential operations on real client websites: drafting and publishing articles, applying technical fixes, and researching and reviewing content strategy. The industry conversation about such agents concentrates on prompts and model choice. The defects this note documents, drawn from the week of July 22-29, 2026, lived in neither place. They lived in context: what an agent could see, whether it would actually read it, how old it was by the time it was consumed, and what it cost to read.

We now treat context as an engineering surface in its own right: designed, versioned, tested, and capable of failing in ways that no prompt review will catch. This note documents four failure modes (three from that week, and a cost measurement that followed on August 4), each with a date attached:

  • Invisible context: a file present in the workspace that no agent will ever read, because a second gate silently excluded it (July 29).
  • Unreachable context: evidence the pipeline computed but could not structurally deliver to the consumer that needed it, until a code decomposition opened the seam (July 29).
  • Stale context: stage outputs aging in a queue while the next stage waited for a scheduler tick (measured July 28).
  • Costly context: a content draft whose spend was dominated by reading, not writing (measured August 4).

The Compiled Strategy Pack

Every agent that works on a client site needs the same background: what the strategy for this client currently is, what evidence supports it, and what constraints bind any edit. The naive architecture, in which each dispatch lane assembles its own briefing from whatever tables it knows about, produces as many partial, drifting views of the client as there are lanes. On July 22-23, 2026, as part of the Strategy Center build, we replaced that with a compiler: one canonical code path renders the client's activated strategy and its supporting evidence into a multi-section context pack materialized directly into the agent's workspace.[1] Context files that predate the pack format are handled by adapters feeding the same compiler; legacy shapes receive a translation layer, never a second writer.

We describe the pack's sections categorically rather than by name, because the format is explicitly still evolving: the revision that shipped that week was already the second, rolled out behind a flag on July 22-23 and enabled by default on July 24, 2026.[1] Categorically, the material our record names in the pack is of two kinds:

  • Strategy: what the platform has decided about this client, namely the activated plan an agent is executing against, at the revision the system considers current.
  • Evidence: the measured basis for those decisions, comprising search-performance data, competitive observations, and site facts, so the agent reasons from the same record the planners did.

The third requirement, the constraints that bind any edit, is enforced on this platform by fail-closed verification gates around the agent's output. Whether constraint material also travels inside the pack is a detail our record does not pin down, so we do not assert it.

Doctrine: one writer per artifact

A context artifact receives exactly one canonical compiler. Legacy formats receive adapters onto that compiler, never a parallel writer. The incident in the next section is precisely what happens when this rule is violated by accident.

A Read-Order Index as a Second Gate

A pack in the workspace is necessary but not sufficient. Our interactive agents boot with an instruction to read only the files an index marks as available; the index enumerates each artifact as available or missing. That makes reading a two-gate operation: the file must exist, and the index must list it. The two gates are maintained by different code, and they can disagree.

On July 29, 2026, during a verification wave, we exercised a new proof technique: running the deployed code path in-process, read-only, on the production execution host (a Node service on Fly.io) rather than on any replica of it.[2] The proof exposed a genuine defect. Two conditionally generated context briefs, the client's activated-strategy brief and the competitor-landscape brief, were on disk in the workspace and invisible to every interactive agent. The index listed them neither as available nor as missing; per the boot instruction, no agent would ever open them.

The mechanism was a violated single-writer rule. The workspace-provisioning service wrote the correct bundle and the correct index. A front-end code path then rebuilt the same index from a hand-duplicated catalog of artifact entries and silently overwrote the server's file. The duplicated catalog lacked entries for the two conditional briefs, so the rebuilt index omitted them. Every layer appeared healthy (files present, index present, agents booting normally) while the freshest strategy material in the workspace went unread. We attributed the overwrite only after searching for the index's distinctive strings across every application that could plausibly have written it; the offending writer was not the service that owns the artifact.

Doctrine: existence and readability are different claims

"The file exists in the workspace" and "the agent will read it" are different claims and must be verified differently: a live proof must check both gates, not only the filesystem. Before concluding which code wrote an artifact, search for the artifact's distinctive strings across every application that could have written it; a hand-duplicated catalog that overwrites a server artifact silently eliminates features.

Decomposition as Context Engineering

The same day, July 29, 2026, we completed a decomposition wave over the platform's largest source files: roughly 24,000 lines redistributed out of monolith files into focused modules, with every moved function body byte-identical to its origin so reviewers could verify that moves were moves.[3] The main serverless entry file shrank from about 7,000 lines to about 1,300; the main front-end page from about 1,500 lines to roughly 50.

~24K
Lines redistributed, byte-identical moved bodies
9
Review input blocks after the wave (one newly reachable)
1
Recorded before/after quality datum from the change

A refactor belongs in an article about context because an agent's effective context is not what the codebase contains; it is what the assembly seams can deliver. Our strategy-review engine consumes a fixed set of input blocks. Before the wave, the monolith's structure made it structurally impossible to feed the competitor-gap artifact (evidence the pipeline was already computing) into the review engine. After the wave, wiring a ninth review block became a small change: the block cross-references competitor authority against the client's own backlink profile.

The wave's own live proof run that same day was a strategy review for a local service client in southern New Hampshire, and on that run the model cited the ninth block: one finding cross-referenced a competitor's authority against the client's backlink profile, an analysis it could not have produced the day before, because the input never reached it.[3] That is our one recorded before/after quality datum for context design, and we state its weight plainly: we lack a systematic quality metric for agent output beyond it. What we can state is narrower and solid: the decomposition made a class of finding possible, and the model produced one on the very run that proved the wave.

Latency Is Context Staleness

In a multi-stage research pipeline, each stage's output is the next stage's context. On July 28, 2026, the record shows our deep-research runs were taking 49 minutes to 3 hours end to end, while the compute inside each stage was minutes.[4] The difference was queue wait: after each stage completed, its output sat until the next 15-minute scheduler tick noticed it and dispatched the successor. Compounded across the pipeline's stages, that wait meant the dominant term in the age of the context each stage consumed was not computation — it was idleness.

49m-3h
Full research run, tick-coupled staging
15 min
Scheduler tick each stage waited for
6-8 min
Full run after instant dispatch + self-chaining

The fix shipped the same day: a completing stage dispatches its successor immediately, and the satellite function self-chains subsequent stages under one leased claim instead of returning to the queue between hops. A full run dropped to roughly 6-8 minutes.[4] We built it as a latency fix; in hindsight we describe it as a context-freshness fix. The measured effect is duration, and we hold the claim there, but the design lesson generalizes: when auditing an agent pipeline's context, audit the age of every input at the moment of consumption, and expect the scheduler, not the model, to be what makes it old.

The Economics of Reading

Context has a price, and the price surprised us in its direction. On August 4, 2026, while splitting writer models to cut drafting costs, we measured where a single content draft's spend actually went: it was dominated by roughly 1.6 million cache-read tokens, which represent context the agent read and re-read across its turns rather than text it wrote.[5] The agent reads far more than it writes. The immediate consequence, recorded the same day, was that switching the writer to a cheaper model alone saved little; with cost read-dominated, the substantive savings lay in other lanes.

~1.6M
Cache-read tokens on one measured content draft
n = 1
Drafts measured at this granularity (a single observation)

We hedge this as what it is: a single measured draft, without a recorded distribution across drafts or a stated measurement window, useful as an order of magnitude rather than a mean. Even as an order of magnitude, however, it reframes the design problem. Every artifact placed in a workspace is a recurring toll charged on every run that reads it, so context engineering is also cost engineering: the pack compiler is, among other things, a budget allocator deciding what is worth making readable at all.

What We Do Not Know

The failure modes above are real, dated, and specific. The affirmative evidence is much thinner, and we state so explicitly rather than imply otherwise:

  • We have no systematic output-quality metric. The ninth-block citation of July 29, 2026 is a single before/after observation, not a benchmark. We cannot state that better context packs produce measurably better content or analysis on average; we can only state what became structurally possible.
  • The pack format is still evolving. The section inventory has already changed once and will change again; we do not know the optimal size, ordering, or granularity of a pack, and we do not yet instrument which sections agents actually draw on in their outputs.
  • The reading-cost picture rests on one measurement. A distribution across draft types, sites, and pack sizes is future work, and it may move the 1.6-million figure substantially in either direction.

What the week of July 22-29, 2026 did settle is the framing. Context for agents that touch production websites is not an incidental adjunct to the prompt — it is a surface with writers that can collide, gates that can disagree, freshness that decays in queues, and a bill that arrives per read. We engineer it the way we engineer everything else on this platform: one canonical writer per artifact, live proofs that check every gate, and honest statements about the difference between what we have shown and what we merely believe.

Sources & Notes
  1. 1.

    Strategy Center build and activation records, July 22-24, 2026: strategy-pack compiler design, legacy-file adapters, staged format rollout. Internal engineering record · July 2026

  2. 2.

    Watch/verify wave record, July 29, 2026: in-process live proof on the production execution host; context-index overwrite diagnosis and fix. Internal engineering record · July 2026

  3. 3.

    Decomposition wave record, July 29, 2026: moved-line accounting with byte-identical bodies, ninth review block wiring, first live citation on a client strategy run. Internal engineering record · July 2026

  4. 4.

    Strategy pipeline wave record, July 28, 2026: research-run duration measurements before and after the instant-dispatch and self-chaining redesign. Internal engineering record · July 2026

  5. 5.

    Writer-model cost measurement, August 4, 2026: token accounting on a single content draft, cache-read dominance. Internal engineering record · August 2026