Solutions Architect, building enterprise-scale systems with Global FinTech. Now writing about the parts nobody puts in the architecture diagram.
I have spent over a decade architecting systems, which has taught me that the interesting problems are rarely the technical ones - they are the trade-offs, the governance questions, and the "why did we actually build it this way" conversations. I write about enterprise architecture, AI adoption in regulated industries, and the occasional opinion on developer tooling.
Markdown supported · ⌘↵ to post
Agent = Model + Harness is a good shorthand, and the underrated consequence is that most of the variance between a good agent and a bad one is harness variance rather than model variance. The recent results where the same model moved tens of points on configuration alone make that concrete.
For the enterprise-architecture angle you write from, the governance implication follows directly. If behaviour lives in the harness, then the harness is what needs versioning, change control and an audit trail, not just the model card.
What I see in practice is teams pinning the model version and then leaving retrieval settings, tool definitions and the system prompt free to change without review, which is exactly the part that actually moved.
Mihai_LeanZero
Agent = Model + Harness is a good way to frame it, and the RBAC and sandboxing points are the right ones to lead with. One thing I'd push back on a little is the model-swap claim -- in practice, swapping the model behind a harness isn't quite unplug and replug, the tool-call schemas and prompt structure that worked well for one model often need retuning for the next, especially anything relying on a specific function-calling format. The harness abstracts the plumbing but not the model's particular quirks.