OpenCode Doesn't Send Prompts. It Assembles Context.

Prompt engineering was a two-year detour. Teams built libraries of templates, argued over phrasing, and hunted for the magic sentence that would unlock better reasoning. The assumption was simple: the quality of the answer lived in what you typed. It didn't.

The most interesting AI systems being built today spend almost no effort on the prompt. They spend it on everything that happens before the model generates a single token. That is what makes OpenCode feel different from a chat window. It does not start with reasoning. It starts with understanding the environment where the work actually lives.

Reasoning is the ability to work through a problem. Knowledge is everything true about the specific situation you are working through. A frontier model supplies the reasoning. It arrives knowing how to think and knowing almost nothing about your problem. The knowledge has to come from somewhere else, and that somewhere is context. When a system produces a genuinely intelligent answer, the model supplied one half of it. The context supplied the other. The industry spent two years obsessing over the half the vendors sell and ignoring the half we actually control.

From the outside, OpenCode looks like any other prompt. Inside the terminal, the model is the last thing to get involved. Before OpenCode calls Claude, GPT, or Gemini, it assembles the context: the repository, the active branch, the project structure, the configuration files, the frameworks in use, the recent commits, and which files actually matter. This context is assembled, not written. Where developers once built it by hand, pasting logs and stack traces into a chat window and hoping they had remembered everything, OpenCode reconstructs it from the workspace itself. A custom command like prime-context does nothing more than run git ls-files and read the README, and the model wakes up already knowing the shape of the project. Even bugs work this way: instead of trusting a developer's description, the terminal pulls real diagnostics straight from the language server. Through the Model Context Protocol that same discovery reaches past the repository into GitHub, Cloudflare, Kubernetes, and whatever else a real system runs on. Context stops being something the developer describes and becomes something the system discovers.

That is why this matters beyond developer tooling. Every frontier model is converging on the same capability, reaching your competitors on the same terms the same afternoon at a falling price. Reasoning is becoming a utility. What it reasons over is not. Almost all of that assembled picture is proprietary. Your codebase. Your infrastructure. Your incidents. The way your business actually works. No subscription hands that to a rival. A gap remains: OpenCode assembles context in the moment and then discards it, rebuilding the same picture every session. Fine for a tool, useless for compounding an advantage, because nothing accumulates. If that context is the asset, it has to persist, and that is a format problem. One early answer already exists.

The Open Knowledge Format treats a unit of knowledge like source code. Each concept is a single markdown file with a short YAML header on top. The header holds the structured fields a machine can filter and index on. The body underneath is plain markdown, the prose a person reads and a model loads. The file lives in git, so it carries its own history, provenance, and freshness. No vendor sits in the middle, because it is just files you own and move. Assembly gets you through today. A format is how knowledge stops evaporating.

Naming the asset is not the same as holding it. Most companies cannot say where their knowledge actually lives or who keeps it current. Today it is trapped in databases that store the data but not its meaning, in wikis behind logins, and in the heads of a few senior people. A dashboard can show this quarter's bookings as a single number. It cannot tell you which column that number should come from, or that summing the obvious one silently triples it. That second layer, what the data means and why, is the part that decides whether an answer is right, and it is exactly the part no system owns.

The Open Knowledge Format is built to fix that. Google Cloud published it and shipped a second version within weeks. The approach gives that meaning the same treatment as code. Each concept lives as a file in a git repository, written by the person who knows it, approved in a pull request, and dated. Because it is only a file, an agent can read it into context and write back to it. The knowledge stays alive through business changes instead of rotting in an abandoned wiki. The deeper consequence comes from the format being shared and vendor-neutral. Knowledge stops being trapped inside one company. A provider can ship its catalog as a bundle your agents read with no integration. A team can pass years of accumulated knowledge to a new partner or its own future systems without translating anything. It becomes portable capital the company owns outright.

Here is what one of those files looks like, a single sales metric a person can read and an agent can load verbatim:

---
type: metric
name: Bookings (GAAP)
owner: finance@
verified: 2025-06-10
status: current
---
Bookings is the value of signed contracts in the quarter. Do not sum the `total_contract_value` column. That column includes multi-year deals at full face value. Use `qty * mrr` instead.

The header is the part a machine filters and trusts: what type of thing this is, who verified it, and whether it is still current. The body is the part no database holds: the one warning that keeps a wrong number off the next board slide. Data lives in the warehouse. What the data means lives in the file.

Do that for a few years and the model becomes the interchangeable part. You feed your knowledge to whatever engine reasons best this quarter and replace it next quarter without losing a thing. The company that started writing its knowledge down early is compounding. The one still comparing models is starting over every time the leaderboard moves.

The first generation of AI was about learning to write better prompts. The next one belongs to whoever owns the better knowledge.