3 min · June 23, 2026
We're moving from building objects to building agents.
For most of software's history, we've built objects. I mean that almost literally. An object takes input, runs it through logic that's compiled in and produces output. The rules are fixed at build time. It's fast, predictable, testable and completely blind to anything its author didn't anticipate. Feed it something the rules don't cover and it doesn't reason about the gap, it either falls through or breaks. The intelligence lives in the developer who wrote the rules, not in the thing itself. The object only ever acts out what was decided for it in advance.
Lately I've been watching a different kind of system take shape. Same outer shape, input, tools, output, but the engine in the middle is no longer just compiled rules. It's a reasoning engine: an LLM or an ML model that can actually weigh a situation it wasn't explicitly programmed for. Call these agents. The agent isn't limited to the branches someone hard-coded. It can interpret messy input, choose among tools, and handle the case nobody foresaw.
Take a service that sends emails. The object version takes a template and some variables, fills the slots and sends. Hand it a missing field, a malformed date or a situation the template didn't plan for and it ships something broken without noticing, because noticing was never in its rules. The agent version is given an intent, "tell this customer their settlement is delayed and reassure them", and it reasons about tone, works around the missing data, asks for what it needs, maybe decides not to send at all. Same job. A fundamentally different engine doing it.
It's tempting to call this progress and leave it there, agents are simply better objects. I'd argue differently and my point matters most in the work I do.
First, it's a spectrum, not a switch. Classic objects sit at one end, fully deterministic. Pure reasoning agents sit at the other. Most of what we've actually built for years, the ML models scoring fraud or credit risk, lives in the middle: not hard-coded, not reasoning, just a learned function. The interesting engineering is usually in choosing where on that line a given problem belongs.
Second, and this is the part I'd underline for anyone working in fintech or anything regulated: a reasoning engine buys adaptability by giving up determinism and that trade is often a bad one. An object-driven money transfer is boring and unbreakable. The same input always produces the same output. You can test it exhaustively, audit it and a regulator can trust it. An agent can hallucinate a figure, behave differently on two identical runs and fail in ways you can't fully enumerate ahead of time. It also costs more, in compute to run and in scrutiny to trust, every reasoning call is a bill and a thing you have to verify. For the parts of a system that must be exact, "more flexible" is not an upgrade. It's a risk you may not want.
So the way I see it now, the agent doesn't replace the object. It wraps it. The reasoning engine is excellent at the fuzzy edges, interpreting intent, handling the unforeseen, composing something that feels human. But underneath, it should still be calling deterministic, object-driven tools for anything that has to be correct every single time. The agent decides what to do. The object guarantees how it's done. I'm not alone in landing here, it's close to the advice in Anthropic's own guide to building effective agents: start simple, stay deterministic where you can and reach for autonomy only where the problem genuinely needs it.
Which means the real skill emerging right now isn't "become an agent engineer instead of an object engineer." It's knowing which parts of a system deserve a reasoning engine and which parts must never have one. The future belongs to the engineers who can draw that line well.
An agent decides what to do; an object guarantees how it's done. The craft now isn't choosing one over the other, it's knowing which part of your system needs to reason, and which part must never be allowed to.