Rewritten to be read outside the feed, in three languages. The canonical always points here.
Fine-tuning is often the first fix proposed when an AI feature underperforms. Most of the time the model lacks context, not capability — and without an eval set you cannot even tell whether tuning helped.
In agent projects the binding constraint is rarely the model. It is the ERP that holds the company's data — reading is the easy half, writing is where integrity, identity and the budget live.
Most multi-agent systems take one problem, split it into parts, and hand the coordination to a model at runtime. The glue is where reliability and cost go to die.
An AI agent passes the demo on accuracy. In production, cost per task decides whether it survives — tokens, tool calls, retries, and a loop that can spiral.
Putting a person on the approve button feels like control. Under load, automation bias turns review into a rubber stamp — and the setup keeps no evidence of what was actually checked.
Every part of your codebase has a safety net except the one making the decisions. Why non-deterministic behavior still needs an eval harness — golden inputs, asserted properties, a score you gate on in CI — and why that is a different guarantee from an auditable log.
An agent decides its own next step in a loop; a workflow runs a fixed path and calls the model only where the input is fuzzy. Why the workflow is usually cheaper, more testable, and easier to audit — and when an agent is actually justified.
A demo runs the happy path on hand-picked data. Production runs everything it excluded: retries, idempotency, service identity, backpressure, and proof of what the agent actually did.
One architecture uses the chain as a data source, the other as a notary. They solve opposite problems and fail in opposite ways. Most pitches confuse the two.
.NET software houses don't turn down blockchain and AI agent work because it's a bad idea. They turn it down because building that capability is a two-year detour.