If you have ever sat beside a coding agent while it digs through Postgres, you have seen something product demos almost never name. It invents SQL. It stacks a grep, a regex, a sample harness. After a handful of runs it surfaces a shape of the data nobody would have scoped as a three-week discovery project. You are not watching a chatbot with a database plugin. You are watching an intelligence manufacture a way to see.

That is the load-bearing claim: an agent’s hidden core problem is not merely choosing the next action. It is engineering how the world appears to itself.

How do I make the relevant part of reality legible to myself?

Thirteen gigabytes is not a thought

Raw reality at machine scale is cognitively useless to a model. A multi-gigabyte store still sits in tables and indexes. The model’s working memory is a context window — a bounded attention budget, not a magic mirror. Industry context-engineering guidance puts this bluntly: models draw on a limited attention budget when parsing large volumes of tokens, so the craft is curating the right set of tokens, not dumping everything that exists.¹

So the agent does not “look at” the database. It forges a probe. The probe returns a representation. The representation enters context. Only then does cognition get a purchase:

WORLD → SENSOR / PROBE → REPRESENTATION → CONTEXT → COGNITION

We call the higher craft perceptual engineering: the runtime construction of representations that make the next cognitive step possible. The mechanism underneath is epistemic tool forging — manufacturing a disposable deterministic instrument for the question you have right now.

Epistemic tool forging

The loop is almost boring once you write it down, and almost always ignored when people talk about “giving the agent tools”:

QUESTION
   ↓
can't perceive the answer directly
   ↓
FORGE PROBE → MEASURE → INTERPRET
   ↓
NEW QUESTION → FORGE NEXT PROBE

In a lived archaeology session, the shape looks like this. A store on the order of thirteen gigabytes is opaque. First SQL returns thousands of messy rows — still almost useless. Group by sender: newsletters dominate. Exclude automated classes. Sample bodies, trim, project date/sender/subject/first characters. Arrive at on the order of a dozen patterns the model can hold. Then the only job language models are truly for: recognition. “Oh. That’s the structure.”

Industry is edging toward the same shape from a different door. Guidance on code execution for agents emphasises processing and filtering data in an execution environment before results enter the model — so intermediate mess never spends the attention budget.² They are solving token economics. You can read the same pattern as perceptual engineering: determinism narrows the world until the retina is usable.

Fixed mega-tool menus are a poor substitute. Benchmarks of agentic tool use keep reminding us that a larger action space is not free — performance can degrade as the haystack of tools grows.³ A purpose-built filter forged for this question often beats browsing a catalogue of generic connectors.

AI narrows the question. Determinism narrows the world.

Most arguments still frame a false choice: more AI, or more deterministic software? The freakish sessions sit in the oscillation:

AI          → decides what needs measuring
DETERMINISM → measures it exactly
AI          → interprets
DETERMINISM → reshapes / filters
AI          → recognises a pattern
DETERMINISM → tests at scale
AI          → changes the hypothesis

Pure LLM without contact produces plausible essays about your database. Pure deterministic output produces row counts that sit like untranslated tablets. Together you get intelligence in contact with reality.

AI narrows the question. Determinism narrows the world.

From the outside, an observer draws boxes: SQL → AI → SQL → AI → regex → AI. From the inside, the agent is thinking: too many newsletters; filter them; better; what is that; oh. It does not experience itself as a component in an AI pipeline. The workflow is the trace left behind by thinking — it precipitates from contact with reality rather than being designed first and executed second.

Public engineering notes already half-describe this. Agents dynamically direct tool usage across many turns on open-ended problems — not single-shot completions.⁴ Code-execution work stresses filtering outside the model so only the reduced product spends context.² What they under-name is the reciprocal half: the model must also re-ask better questions. Without that, you get eternal SELECT loops.

The resolution axis

Even the right family of instrument can ruin cognition in two opposite ways:

TOO MUCH WORLD  ←── useful perception ──→ TOO LITTLE WORLD
100k raw rows      representative evidence    one COUNT(*)
context pollution  texture + structure         no texture

Blinding: a hundred thousand lines poison attention; patterns disappear into volume. Long-context research shows length is not free — relevant information in the middle of a long context is easy to under-use.⁵ Tool-description bloat is the same disease at another layer: schemas crowd out project context.⁶

Starving: COUNT(*) = 4827 is exact and almost content-free. Metrics are eyes with a very particular blur — lethal when the question requires recognising what a thing is.

Useful perception is engineered into a middle band: representative samples with structure. On codebases, a repository map of signatures without full bodies is the same idea — navigate a tree larger than the window without drowning in lines.⁷ After every probe, ask: am I blinding or starving?

Eyeball it

Here is an instruction primitive operators invent when English fails. Say “review this” and agents often hear “perform another deterministic test” — another grep, another count. Say eyeball it and you mean something else: stop manufacturing measurements; put the evidence in context; apply semantic judgment.

Pure deterministic systems can SELECT forever. The model is the component that can say: show me thirty examples — ah, I see it. If your instructions keep saying “review” and “validate,” you may be accidentally forbidding that return. Teach a dialect: when I say eyeball, you read; when I say measure, you probe; when I say validate, you assert against a named rule.

Text as cognitive membrane

For coding agents, the world must become context — and that context is overwhelmingly textual. The agent writes text (code) to see different text (probe results). Multimodality can get the world through the door — a boot-screen screenshot that says INACCESSIBLE_BOOT_DEVICE — after which the working state should usually come home to text.

Multimodality gets the world through the door. Text is where the model takes its coat off and starts thinking.

Default text without absolutism: text should be the default cognitive representation; other modalities are sensors when non-textual structure itself is the payload. We have already written the home-turf field note and the skeleton-of-a-visual move (structure without pixels); full modality-conversion pipelines are a sibling craft with their own boundary conditions.⁸⁹¹⁰

Operate the retina

1. Name the question the eye must serve.
2. Forge the smallest probe that could confirm or wreck the hypothesis.
3. Read the result on the resolution axis — blinding or starving?
4. Re-forge until you have representative evidence.
5. Eyeball when instruments are good enough and meaning is missing.
6. Let the next question emerge — do not force a pre-drawn pipeline.
7. Dispose of instruments that served their cognitive purpose.

Phrase bank: “Eyeball the sample — don’t grep again.” “Too much world — compress to patterns.” “Too little world — I need texture, not only counts.” “What would I need to see to know the next step? Forge that eye.”

Close

An agent’s hidden core problem is engineering how the world appears to itself. It forges disposable deterministic instruments to compress unreadable reality into a textual sensorium tuned between too much world and too little. The freakish capability is the oscillation: AI narrows the question; determinism narrows the world. The workflow you admire from the outside is usually the fossil of that thinking — not a topology anyone fully designed first.

Your job is not to become a better SQL artist than the model. Your job is to treat representation construction as first-class work, to tune resolution on purpose, to say eyeball it when measurement has done enough, and to refuse the comforting lie that more tools, more tokens, or more multimodal pixels will substitute for a well-forged eye.

Make reality legible at the right resolution. Everything else is commentary.