An agent does not know things. It predicts them. That distinction sounds academic until you're debugging a production failure at 2am and your agent confidently told a user the wrong thing in a way that felt completely reasonable.

The mental model most developers bring to agents is borrowed from APIs: you send a request, you get a response, the response is correct or it isn't. But that's not what's happening. What's happening is a statistical process — the model is generating tokens that are likely to follow from the input, shaped by everything it was trained on and everything you put in the context window. When it's right, it's right for the right reasons only some of the time. When it's wrong, it's wrong in ways that look like confidence.

This matters because it changes how you design. If your system downstream trusts the agent's output the way it would trust a database query, you've built on sand. The output needs validation layers — not because the agent is unreliable in the way a junior developer is unreliable (makes mistakes, gets tired, misunderstands specs) but because it's unreliable in a probabilistic way, which is harder to reason about and harder to catch.

People who've worked with neural networks before agents get this intuitively. People coming from rule-based systems often don't, not at first. They expect determinism and when they get fluency instead, it reads as reliability. Fluency is not reliability. A model that phrases things clearly and consistently is not a model that is consistently correct.

The practical implication is to treat every agent output as a distribution, not a value. Sometimes that distribution is tight — the task is well-constrained, the prompt is precise, the model has seen a thousand examples of this exact thing. Sometimes it's wide — the task is ambiguous, the context is thin, the domain is niche. Your job is to know which kind of output you're dealing with and build accordingly.

That means evals. It means test cases. It means monitoring what the agent actually does in production, not just what it does in the happy path demo. It means designing your system so that when the agent is wrong — and it will be — the damage is limited and recoverable.

None of this is a reason not to use agents. The probabilistic nature is also why they're useful: they handle ambiguity, generalize from examples, navigate edge cases that no rule-based system would ever anticipate. But you pay for that generalization in predictability.

The developers who are best at working with agents have made peace with this. They don't expect the agent to be a deterministic machine. They expect it to be a very capable collaborator who is sometimes confidently wrong, and they build systems that can absorb that.

Magic would be simpler. Probability is what you've got.