The architecture flip I keep seeing: code no longer calls the LLM — the LLM calls the code

I spend a lot of time around client companies, and over the last few months I've noticed an interesting shift in how some teams build internal automation The old architecture was straightforward: if a company needed an internal process automated, somebody built a product. Backend, database, deployment, interface, the whole thing. LLMs initially changed very little. Teams added model calls to otherwise deterministic pipelines, wrapped them in structured output, retries, monitoring, and validation, and kept the rest of the architecture intact. Now I'm seeing some teams invert that model. Instead of building a dedicated application, they use: Codex, Claude Code, OpenCode, or another general agent as the orchestrator, running on a VPS or the user's machine A repo, containing instructions, deterministic data-processing scripts, and connectors to systems like gsheets, email, slack, or CRM a scheduled job that starts the agent, or a human who opens it and describes the task in plain language instead of clicking through a custom UI The funny inversion is this: Previously, deterministic code was the system and it occasionally called an LLM Now the agent is the system and it calls deterministic code when it needs precision Code no longer calls the LLM. The LLM calls the code. Why are the teams doing this? 1. Runtime flexibility If some data is missing, the agent can look in Gmail, Notion, Jira, the CRM, or analytics – assuming it has been given access. You do not need to encode every possible path in advance 2. Change becomes cheaper A process change may require editing an instruction file, changing the available tools, or updating a small script instead of rebuilding a workflow and its UI 3. The system can capture new operating knowledge If the agent encounters an edge case and resolves it, the workaround can be reviewed and added to the relevant instructions or skill. The next run starts with more context instead of rediscovering the same problem 4. The entry barrier is much lower Sales, marketing, and operations people can assemble automations that previously sat in an engineering backlog for months. They still need permissions, review, and guardrails, but they do not necessarily need a new application for every process This architecture is obviously not universal Red flags: Many users. Shared mutable state. Strict reproducibility requirements. High execution frequency or tight latency requirements. Stable contracts and a process that is already fully formalized. Green flags: Input data changes shape frequently. The task requires judgment based on context. Sources and rules change often. A human currently performs the task manually because "you have to look at the situation." If the task resembles a conveyor belt, a deterministic service is probably still the right answer. If it resembles the work of an operator or assistant, the agent-first architecture starts to make sense. Previously, automating a process meant formalizing it into a rigid algorithm first. Now some processes can be automated while they are still only partially formalized. Are you seeing the same inversion in real systems, or does it still collapse into a conventional application once the prototype meets production?