They can search databases, call APIs, modify tickets, draft code, update records, trigger workflows, and interact with production systems.
When an LLM only generates text, a bad answer is usually just that: a bad answer.
And I think one of the most useful principles for production AI agents is surprisingly simple:
The same probabilistic system is effectively doing two jobs: deciding what it believes should happen; authorizing that thing to happen.
Those should not always belong to the same component. Don’t use an LLM when deterministic code is enough
One of the easiest mistakes in AI engineering is using the model simply because the model is available.
lower latency lower cost easier debugging predictable behavior deterministic regression testing
Use intelligence where intelligence is actually required. Make reasoning structured
If another system component needs to inspect the model's output, don't make that component parse a paragraph.
Schema-constrained output changes how the rest of the application can interact with the model.
That distinction becomes increasingly important as agent workflows become more complex. Grounding does not automatically mean relevance
Imagine the query concerns a concurrency bug, but the vector search returns three vaguely related caching incidents.
The LLM can still build an extremely confident, beautifully cited, completely wrong explanation from them.
“The model cited a real source” and “the model cited evidence that supports its claim” are different guarantees.
A RAG system can be perfectly citation-valid and still be badly grounded. A second LLM can review the first — but it shouldn’t necessarily control the gate
permission scope severity thresholds resource ownership allowed operations schema validation rate limits approval state
These are usually better represented as explicit program state than as natural-language judgment. Put safety checks inside the execution boundary
If approval existed only as orchestration logic, you just removed the safety control by changing one edge.