Your Agent Isn't Broken. Your Architecture Is.

The post-mortems we hear most often go like this: a business deploys an AI agent, it works well in demos, and then in production it starts doing strange things. It skips steps. It gives inconsistent answers to identical inputs. It occasionally does something that would get a human fired. The instinct is to blame the model and go shopping for a better one.

That instinct is almost always wrong.

Salesforce's own engineering team documented this precisely in a production cloud-cost optimisation agent they built and shipped. They found that roughly 86% of their containers were under-using CPU, and the agent's job was to find the right configuration file and fix the allocation. It kept producing different answers to the same input. The fix was not a new model or a cleverer prompt. It was an architectural change: they stopped asking the LLM to do everything, and started routing work to the right kind of tool. Ambiguous reasoning (which config file is actually in control here?) stayed with the LLM. Precise arithmetic (what is the optimal CPU value?) went to a deterministic solver. Same input, same output. Every time. You can read the full breakdown of the five patterns they extracted here: [https://engineering.salesforce.com/how-to-build-reliable-ai-agents-5-engineering-patterns-from-a-production-system/](https://engineering.salesforce.com/how-to-build-reliable-ai-agents-5-engineering-patterns-from-a-production-system/)

Separately, a Salesforce benchmark called CRMArena Pro tested LLM agents on realistic CRM tasks, and the results were bad in a specific way. Agents failed not just on accuracy but on confidentiality, leaking data across user accounts. That is not a model intelligence problem. It is a missing policy enforcement problem. The Register covered it here: [https://www.theregister.com/2025/06/16/salesforce_llm_agents_benchmark/](https://www.theregister.com/2025/06/16/salesforce_llm_agents_benchmark/)

What 'Sloppy Architecture' Actually Looks Like

In practice, we see the same three mistakes repeatedly:

• Asking the LLM to do maths, enforce rules, and reason, all in the same pass. Language models are probabilistic. They are brilliant at navigating ambiguity and producing plausible-sounding text. They are not calculators, and they are not policy engines. Mixing these responsibilities into a single prompt is not a shortcut; it is a fault waiting to surface under load.

• Treating context as an afterthought. Stuffing every available piece of information into the context window feels thorough. It is actually one of the most reliable ways to degrade output quality. The Salesforce team explicitly flag context management as an architectural concern, not a prompting tweak.

• Using another LLM to validate LLM output. A reviewer agent checking a worker agent's output sounds sensible. But if both agents share the same failure modes, you have added latency and cost without adding correctness. Real validation means objective checks: does the code compile, does the record update succeed, does the output satisfy a deterministic schema?

A recent paper from Alibaba makes this concrete. Their "Blueprint First, Model Second" framework puts ordinary Python code in charge of workflow logic, and only calls the LLM at steps that genuinely require flexible reasoning. On the TravelPlanner benchmark, constraint violations dropped by 96% compared to the previous best approach. The principle is simple: the code is the boss, the LLM is a specialist called when needed. [https://arxiv.org/abs/2508.02721](https://arxiv.org/abs/2508.02721)

The LedgerAgent paper takes the same idea into customer-service tool-calling: every time a tool returns data, results go into a typed structured store rather than back into free-form prompt text, and a policy gate checks every write action before it executes. Across airline, retail, telecom, and telehealth scenarios, pass rates improved by 6-16 points with zero extra LLM calls. [https://arxiv.org/abs/2606.20529](https://arxiv.org/abs/2606.20529)

What We Think

We have been watching the "just upgrade the model" response to agent failures for long enough to know it is usually a distraction. GPT-4 doing your arithmetic is no more reliable than GPT-3.5 doing your arithmetic; a deterministic function doing your arithmetic is reliable every time.

For SME deployments specifically, the stakes of a sloppy architecture are higher than most people realise. A data leak across CRM accounts, a workflow that skips a compliance step, an agent that gives a customer the wrong refund amount because floating-point arithmetic ran through a language model: none of these are fixed by a prompt revision or a model swap. They require structural answers. Separate your reasoning layer from your computation layer. Enforce policy with code, not with instructions to the LLM. Validate outputs against objective criteria.

Salesforce's production evidence points in exactly one direction. The reliability gap in agentic systems is an engineering problem.

What to Watch

The pattern to track is the formalisation of "deterministic shells" around LLM cores, whether that is Python blueprints, typed ledgers, or policy gates. As Agentforce and similar platforms mature, we expect these patterns to become first-class primitives, not workarounds. The teams that build them by hand today will have a significant head start when the platforms catch up.