Shape, patterns, corpus: the words around AI agents
The vocabulary around AI agents got loose fast. Words like shape, patterns and corpus get used as if everyone agreed on them, usually by people selling something. Most of them do have precise meanings, and knowing those meanings changes how much you trust what comes out the other end.
Here’s the working glossary, in the order that makes them build on each other.
Corpus
The body of text a model learned from. Every public repo, every Stack Overflow answer, every manual and blog post and argument, flattened into training data.
The corpus is why a model can write a Dockerfile it has never seen before, and it’s also why it will confidently write one for a version of Docker that stopped existing in 2021. A model doesn’t know things the way a database knows things. It absorbed a very large amount of writing about things, and the corpus has a horizon — it ends on a date, and everything after that date is guesswork dressed in the same confident tone as everything before it.
Practical consequence: the fresher and weirder your problem, the thinner the corpus underneath it.
Patterns
The regularities a model extracted from that corpus. Not facts — regularities. That a function definition is usually followed by a docstring. That an HTTP handler that opens a file usually checks whether it exists. That an error message shaped a certain way is usually followed by a certain fix.
This is the actual mechanism. A model isn’t retrieving your answer; it’s producing the most plausible continuation given everything it has seen. When people say a model “understands” your codebase, what’s happening is closer to: your codebase looks like a lot of other codebases, and it’s very good at what usually comes next.
That’s not a criticism. Pattern-matching at that scale is genuinely powerful. It’s just important to know it’s what you’re buying.
Shape
The structural form of an answer, independent of whether the answer is correct. This is the most useful word in the whole list, and the one worth being paranoid about.
A model is exceptionally good at shape. Ask for a REST endpoint and you get something with the right route, the right status codes, the right error envelope, the right comment style — it looks exactly like the thing you asked for, because shape is precisely what patterns capture. Whether it also checks that the caller owns the record it’s about to hand over is a different question, and shape will not tell you the answer.
This is where hours go. A wrong answer that looks wrong gets caught in seconds. A wrong answer wearing the right shape gets read, nodded at, and shipped — and then it’s found in production by someone who didn’t write it. The failure mode of AI-generated work isn’t gibberish. It’s plausibility.
Everything else in this post is easier to understand once you hold that distinction: shape is not correctness, and shape is what you get for free.
Tokens, context window, inference
Tokens are the chunks text gets cut into — roughly ¾ of a word each, so “unbelievable” might be three of them. Models read and write in tokens, and pricing and limits are counted in them.
The context window is how many tokens the model can hold at once: your prompt, the conversation, the files it read, the tool output, and its own reply, all in one budget. It isn’t memory — it’s a desk. Anything you want considered has to be on the desk. When the desk overflows, something falls off, and models are notably bad at telling you what fell.
Inference is a single run of the model — text in, text out. It’s stateless. Every apparent memory across a conversation is somebody re-sending the earlier turns.
Temperature and non-determinism
Temperature controls how much randomness is allowed when picking each next token. Low means predictable and repetitive; high means varied and prone to wandering.
The consequence people underestimate: the same prompt does not reliably produce the same output. Software engineering assumes determinism almost everywhere — same input, same build. Agents break that assumption. A prompt that worked yesterday isn’t proof it works; it’s one sample.
Agent, tool use, the loop
Tool use (or function calling) is a model being handed capabilities — read a file, run a command, hit an API — and choosing when to invoke them. The model doesn’t run anything itself; it emits a request, something outside runs it, and the result comes back as more context.
An agent is what you get when you put that in a loop with a goal: decide, act, observe the result, decide again, until done. That’s the whole idea. A chatbot answers; an agent acts and then looks at what happened.
The loop is where the leverage is — and where the failure modes get interesting, because now a plausible-but-wrong answer doesn’t just sit on screen. It writes files.
Hallucination
Output that’s fluent, confident, and false. A cited paper that doesn’t exist, a library method that was never in the API, a config key invented because that’s what a config key usually looks like there.
The word is a bad one — it implies a malfunction. Nothing malfunctioned. The model produced a well-shaped continuation, which is the only thing it ever does. There is no internal flag separating recalled from invented, which is exactly why the confidence is identical either way.
Grounding
Tying output to something that can actually be checked. A test that runs. A compiler. A live API that answers. A schema that validates.
Grounding is the answer to everything above. You do not fix pattern-matching with better patterns, and you don’t fix hallucination by asking the model to be more careful — you fix it by putting the output in front of something that can’t be talked into agreeing. A test doesn’t care how well-shaped your function is.
This is the whole design principle behind how TransistorKit works. Builders write code, and then something indifferent grades it: the app compiles, the tests run, the emulator inspects the actual machine state, the review re-runs every claim rather than quoting the commit message. Not because the models are bad — they’re remarkably good — but because good at shape and right are different properties, and only one of them survives contact with a user.
If you keep one thing: an AI agent produces the shape of a right answer by matching patterns learned from a corpus. That gets you most of the way, most of the time, and it will never tell you which time this is. That’s not a reason to avoid the tools. It’s a reason to build a machine that checks.