The constraint was never in the prompt

Anthropic has published new rules of context engineering for its latest generation of models. The headline is striking: it removed more than 80% of Claude Code’s system prompt for those models, with no measurable loss on its coding evaluations.

The article describes six changes. Rules give way to judgement. Examples give way to designed interfaces. Context is loaded progressively rather than all at once. Tool guidance is written once rather than repeated. Memory becomes automatic. Simple specifications are replaced with richer references such as code, tests, rubrics and working artefacts.

The most important change is not that the prompt became shorter. It is that more of the work moved out of prose.

That is also the path Solario has been taking. We began with Markdown documents and regular expressions. We added syntax-aware parsing. We introduced YAML and JSON artefacts, typed execution contracts and schema-constrained model outputs. We then made a more consequential decision: where an artefact drives execution, the structured record should become canonical and the Markdown should become a projection for people.

The migration is not finished. That is precisely why it is worth describing.

Markdown got us moving

Markdown was a good starting point for an AI software factory. It is readable, versionable and easy for both people and models to produce. A product owner can review a requirement. An architect can annotate a plan. An engineer can inspect a task list in a pull request.

It also allowed us to move quickly. Regular expressions could recover identifiers, headings, file targets and traceability links from documents that remained pleasant to read.

But the approach asks one file to perform two different jobs.

For a person, a sentence can be clear because its meaning is understood in context. For a machine, the same sentence is only executable if its structure and completion conditions can be recovered without interpretation. A task such as improve error handling may be reasonable advice. It is not a bounded execution contract. It names no exact deliverable, no observable check and no decidable end state.

Regular expressions can find labels. They cannot turn an ambiguous promise into a contract.

Better parsing was an intermediate step

In April, we introduced a shared Markdown abstract syntax tree. This removed a class of fragile parsing problems. Tables became tables rather than rows matched with text patterns. Code fences, headings, comments and prose could be distinguished structurally. Governance checks could inspect the relevant part of a document instead of searching every character equally.

This was materially better than regex alone. It was not the destination.

An abstract syntax tree tells the system what kind of Markdown node it is reading. It does not necessarily tell the system what the record means. A heading can be recognised as a heading while the requirement beneath it remains untyped. A table can be parsed correctly while two consumers still interpret one of its columns differently.

The parser had become more reliable, but Markdown was still being asked to serve as both the human view and the machine authority.

The contract started moving upstream

By July, we had begun moving control from instructions into contracts.

Model calls stopped carrying arbitrary sampling numbers at each stage. A stage declares a bounded intent, which resolves through a validated model configuration. Workflow tasks gained explicit input and output contracts. Deterministic gates began checking properties that a model should not be allowed to certify about its own work.

The architectural decision became explicit in early August: records are canonical; human-readable documents are projections.

The task artefact now demonstrates the complete pattern:

1. The model produces structured output against a JSON Schema.
2. The application parses the result into typed records.
3. Zod validation rejects anything outside the application contract.
4. The validated records are persisted as the authoritative JSON artefact.
5. Markdown is rendered deterministically from those records for human review.
6. The Build phase reads the typed manifest, not the rendered Markdown.
7. A consistency guard detects divergence between the authority and its projection.

This changes more than the file format. Structure survives the stage boundary.

The model cannot silently invent a new task shape. A later stage does not have to rediscover file targets from punctuation. A renderer cannot become an accidental source of execution semantics. If the human view and the machine record disagree, the disagreement is detectable.

JSON Schema constrains what may be generated. Zod is the last line of defence when that output enters the application. Typed consumers preserve the contract after persistence. Deterministic gates decide whether the result may advance.

Each mechanism has one job. Together they remove a large amount of prose that previously tried to do all four.

The document remains, but its role changes

JSON-first does not mean replacing every document with an object dump.

People still need a legible specification, plan and task list. They need hierarchy, rationale and the ability to review a change without opening an internal data structure. Markdown remains an effective review surface.

The important distinction is authority.

When Markdown is canonical, every consumer must parse it and recover its own interpretation. When a structured record is canonical, every view can be generated from the same validated source. The document becomes a projection: stable enough to review, disposable enough to regenerate, and never mistaken for the execution contract.

This is similar to compiled software. People work with expressive source material, but production does not execute an interpretation of the documentation. It executes an artefact produced through a defined transformation.

The same principle should apply to software intent.

A structured file is still not a gate

Anthropic is right that tools, schemas, code and test suites can give a model richer and more precise context than another page of instructions. A well-designed interface often teaches correct use better than several examples.

There is still a boundary between context and control.

A JSON Schema included in a prompt is context. A JSON Schema enforced by the decoder constrains generation. A Zod schema evaluated by the application validates the boundary. A test suite shown to a model is a reference. The same suite executed independently, with its result routed through approved policy, is a control.

The file may be identical. Its operational role is not.

This is where context engineering meets governance. The model receives the smallest useful set of structured evidence. The system independently validates what comes back. Policy determines whether the result advances, stops or reaches a human checkpoint. The audit trail records which contract, inputs, controls and decisions applied.

Prompts guide judgement. Structured artefacts preserve meaning. Executed controls establish evidence.

Shorter prompts are an outcome, not the objective

Anthropic carefully scopes its findings to a new generation of its own models. That matters. Different models need different amounts and forms of scaffolding, especially when workloads must run on open-weight models inside a customer’s perimeter.

We should not turn one vendor’s prompt reduction into a universal instruction to remove context.

The durable rule is to remove prose that duplicates an enforceable contract. Keep context that contributes information the model cannot obtain elsewhere. Load specialised material when it becomes relevant. Adjust the density to the model and task. Keep the same independent gates underneath.

That gives us a better optimisation target than prompt length. We can ask whether every instruction has a unique role:

• Does it supply necessary context?
• Does it define a structured interface?
• Is it already enforced by a deterministic control?
• Can it be loaded only when needed?
• Can the system measure what happens when it is removed?

If a paragraph merely repeats a rule that a schema or gate already enforces, it is probably waste. If removing it changes an open-weight model’s ability to produce a valid record, it is still useful scaffolding. The decision should be measured, not fashionable.

The migration is the product work

Solario is already mixed by design and by history. Important paths are contract-bound and JSON-first. Other artefacts are generated as structured records but still lose that structure after rendering. Some downstream consumers still read Markdown because their canonical record has not yet crossed the stage boundary. The plan family remains more prose-shaped than the task path.

The next step is not to declare the migration complete. It is to keep moving authority towards structured records, migrate consumers away from projections, and connect those records to the specification graph and the controls that evaluate them.

That work produces a system in which requirements, architecture decisions, contracts, tasks, code and tests can be related without reparsing the narrative at every stage. It also makes progressive disclosure safer: the factory can assemble the precise records relevant to a decision rather than placing an entire project history into a prompt.

Our previous article argued that the gate has to scale with machine-generated work. This is how the material reaching that gate becomes reliable enough to judge.

Anthropic’s prompt reduction is useful validation. The deeper transition is from asking a model to remember the rules to building a production system in which the important rules have a structure, a validator and an owner.

The constraint was never in the prompt. It was in the contract the prompt could not talk its way past.