Each agent session starts with a cost that never shows up as its own line. Prior to drafting a PRD, tagging a batch of feedback, or scoring a backlog, the agent first loads context: what the product is, who it serves, what the fields in your data mean. Requested work only starts once that load is done.
The load's price is set by storage format. A product overview tokenized as Markdown costs 649 tokens. The same knowledge serialized as JSON climbs to 12,715. The product itself is unchanged.
Format by itself shifted the cost of knowing it by a factor of 20, and that charge repeats on every run.
Exact numbers from the format benchmark follow, along with why plain text wins, how loading context through MCP compares with reading a committed file, and why a Git repository is the cheapest and fastest home for the context your agents read.
The context tax on every run
Prompts are one-shots. Context is recurring.
A task prompt is written once per task. Behind it, the one-pager, ICP, metric definitions, and tag taxonomy load at the start of every agent session. A nightly feedback-tagging pipeline, a weekly changelog drafter, and an ad hoc strategy copilot each reread that same knowledge.
Once you multiply payload size by how often it runs, format is no longer a cosmetic choice. Verbose storage taxes every pipeline, every retry, and every teammate's session. Plain text holds the same knowledge at a fraction of that price.
Price is only half the harm. Recall gets worse as context grows; under the "lost in the middle" effect, facts buried in a bloated payload get skipped or misquoted. A 33,000-character JSON dump is not merely 19x more expensive than the Markdown version. It also hands the model 10x more surface in which to lose the fact you needed it to find.
One product context, four formats, a 23x token spread
Export the product knowledge a PM agent needs four ways: Markdown, CSV, JSON, and XML. Send each export through a tokenizer. This is what the model sees.
- Markdown: 3,359 characters, 649 tokens
- CSV: 4,630 characters, 1,100 tokens
- JSON: 33,922 characters, 12,715 tokens
- XML: 41,590 characters, 14,924 tokens
Relative to Markdown, JSON costs 19.6 times the tokens. XML costs 23 times. The gap is two effects stacked.
Structural bloat is the first. JSON and XML repeat every field name on every record, wrap every value in quotes or tags, and escape every URL. Those same words fit in 3,359 characters of prose and need 33,922 characters of JSON once braces wrap them. That is ten times the characters before tokenization even starts.
Tokenizer efficiency is the second. Because tokenizers were trained on prose, Markdown packs about 5.2 characters into each token. CSV manages 4.2. JSON and XML land near 2.7, as brackets, quotes, and escaped strings fragment into token confetti. Verbose formats therefore need more characters and compress each one worse.
Whatever agents reread on every run should sit in the format the tokenizer prices lowest. For product knowledge that format is Markdown, with CSV close behind for tables.
Markdown for prose, CSV for rows, JSON only as a bus
Do not read the benchmark as "make everything Markdown." Read it as each format having exactly one job in an agent workspace.
- Markdown wins for documents: one-pagers, PRDs, interview transcripts, research synthesis, changelogs. One record per file, named consistently (
2026-04-13-interview-acme-corp.md), so a glob pattern pulls the whole batch. People can read it, Git can diff it, and agents parse it at 5 characters per token. - CSV wins for rows and fields: feedback items, CRM contacts, experiment results, metric exports. Any spreadsheet opens it for a sanity check, and line-by-line diffs stay clean. The 1,100-token cost buys structure prose cannot offer.
- JSON is an intermediate bus, never a destination. APIs speak JSON, so pipelines will touch it. Convert to Markdown or CSV before committing. A pipeline whose last write is a JSON blob locks in a 20x tax on every later read.
- XML has no job here. At 23x the token cost of Markdown, nothing it offers a PM workspace justifies the price.
That split is how the product knowledge repository pattern works in practice: prose lives in Markdown files organized by lifecycle phase, tabular data lands as CSV next to a short schema file, and JSON exists only inside the pipeline scripts between an API and the committed artifact.
18 seconds via MCP, 2 seconds via script, 0 tokens
Format is one lever. Delivery path is the other, and that gap is larger.
In the Product Map agentic PM program, one deliverable fetches the same Notion page two ways and times both. Asking the agent in chat to pull the page through the Notion MCP server took around 18 seconds of wall-clock time and consumed roughly 6,200 model tokens on tool calls, pagination round trips, and block-by-block conversion. A 100-line Python pipeline hitting the Notion API directly wrote the same page as Markdown in about 2 seconds and consumed zero model tokens.
Once that page sits committed in the repo, the comparison tilts further. A local file read needs no authentication handshake, no rate-limit backoff, no tool-call negotiation, and no conversion step. The agent opens the file and the context is in the window at Markdown prices.
MCP still earns a role. When the agent needs a live answer shaped by the current conversation, such as finding every enterprise feedback item from last month that mentions onboarding, a live query beats any snapshot. The failure mode is treating MCP as the default channel for stable context, paying 6,200 tokens and 18 seconds to re-fetch a one-pager whose content changed three weeks ago. Snapshot the stable knowledge into Git on a schedule. Keep the live connection for questions only a live source can answer.
Where the context should live
A Git repository is the one storage layer both halves of an agent fleet read natively. A local agent in Cursor or Claude Code treats repo files as its default context source. A cloud agent clones the same repo and sees the identical bytes. No connector, no sync service, no per-seat integration.
Versioning arrives free. Each context change lands as a reviewed diff, so an agent never reasons from a draft nobody approved, and git log answers "what did we believe in March" without archaeology. A short INDEX.md at the root points agents at the right file instead of loading everything, which keeps even the Markdown bill small.
Stand up that structure once and reuse it. Product Map scaffolds it: connect a GitHub repository and the bot writes the phase folders, the starter one-pager, and the index into your repo. After that, every agent reads from and writes to the same version-controlled layer your team reviews as pull requests. That is the shared workspace discipline engineering teams already apply to code.
The blind spot: context cost multiplies across the fleet
Leaders budget for model choice and skip context format, yet the second decision often moves the bill more. Model prices are public and negotiated once. Context cost hides inside every run, and it scales with a figure almost nobody tracks: reads per week across the whole fleet.
Work a small setup. Five agents, twenty context loads a day each, is 700 loads a week. At Markdown prices that week is about 450,000 context tokens. At JSON prices the identical knowledge is 8.9 million. The extra spend bought nothing. The agents read the same facts, slower, with worse recall.
Prompt caching eases the hit and does not erase it. Cached reads still bill by size, caches expire between sessions, and every cache miss pays full price on the inflated payload. Shrinking the payload is the lever that works everywhere: cached or not, local or cloud, this model or the next one.
The compounding case also runs the other way. A small context layer stays cheap to include, so agents load more of it, so outputs ground in the real product instead of guesses. The teams getting the most from agents in 2026 are not the ones with the biggest context. They are the ones whose context is cheap enough to be everywhere.
Start with one file this week
Skip the migration project. Pick the document every agent should already know, most often the product one-pager, and write it as Markdown in a repo. Add an INDEX.md that points to it. Aim one agent at the repo and run a real task.
Then measure. Run /context in the agent session and note what the load cost. Export the same knowledge from whatever tool currently holds it, tokenize both, and put the two numbers side by side. That gap is the per-run saving, and it repeats on every run, forever. Few infrastructure decisions this cheap pay rent this often.
