Context is the new code

Models sit at the bottom like operating systems — raw intelligence, a commodity primitive. Tools turn models into agents: CLIs, MCP servers, APIs, chosen because they are cheaper and more reliable than asking the model to do the work itself. Context guides the model. Harnesses are deterministic software wrapping the probabilistic model — they load the rules, constrain the model, and their hooks can block any tool call. And harnesses compose into factory lines: feature request in, shipped feature out.

Three content types recurred in every talk: policies (what we agreed — security postures, API design rules), specs (what we are building, especially fast-moving interfaces), and workflows (how we do review, or incident response — wanted for consistency, not capability). Three ways to load them: always-on rules files, skills loaded on demand, and passive docs found by search. Which mode carries which type is a design decision, not an accident.

Of the whole stack, only two things are new compute entities: the models, and the context that goes into them. One speaker's equation made the practical point: agent = f(model, harness, context) — you rarely get to change the first two, so context is where you work. It is also the only layer that can carry knowledge the model was never trained on.

Do a task once, prompt; do it repeatedly, make a skill. Public skill counts went from roughly zero to an estimated two million inside a year. That explosion is the raw material for the second concept page — skills need an SDLC.

The sharpest operational rule of the track: guidance that fires weekly or rarer does not belong in context at all. "Don't use console.log" stuffed into a rules file loses to a lint rule that fires at the mistake. Every sentence of standing context competes for attention with every other — spend it on what is genuinely always relevant.

Assay makes one of the conference's three context types a first-class, machine-checkable artifact: the brief is a spec as a work unit — typed IDs, explicit dependencies, a parseable Verify table, lint that fails when fields drift. Speakers described specs as the most valuable and least maintained context type; in Assay they are the unit of work itself.

The methodology ships as installable skills — one body per role, small and single-purpose. The bodies are deliberately neutral: house-specific values resolve from the adopting repository's own configuration layer, and a lint fails on any unresolved value. That structure is the conference's "extend, don't edit" rule enforced by tooling instead of convention.

Assay's guardrails are two layers with different authority: client-side hooks that advise, and the server-side layer — rulesets, branch protection, per-role application permissions — that binds. A refused action is a stop, never a prompt to route around. This is "deterministic software wrapping a probabilistic model" stated as architecture.

When a failure class recurs, the Assay answer is to promote it out of prose and into a mechanical check — a lint rule, a CI assertion, a board check. Standing prose is the exception, not the default, which is the placement rule the conference arrived at from the other direction.

8 of 21 talks shown — the ones that reach the most concepts in this theme. Every sighting, per talk, is on the concept pages above.