Everyone is deploying LLM agents right now. Almost every team is making the exact same set of avoidable mistakes.

This is not a prompting problem. This is not a model quality problem. This is systems engineering. For six months every conference talk has been about what agents can do. Almost no one has talked about how to build agents that do not break, do not get hijacked, and do not blow up your production environment.

We have four new peer reviewed papers this month, plus hard earned operational experience from production deployments. This is the state of the art as of today.

We stopped building systems and started building piles

Right now almost every agent system is constructed by:

1. Writing a system prompt
2. Gluing on some tools
3. Adding a vector database that dumps every conversation into memory forever
4. Putting another LLM in front as a guardrail
5. Crossing fingers

When this fails, the universal response is "we need a better model". No one asks if the architecture was broken to begin with.

This is the equivalent of building a bridge out of scrap wood, then when it collapses concluding you just needed stronger glue.

All five recent works agree on one core point: agent failure is almost always structural failure, not model failure. Bad workflows will fail with GPT-7 the exact same way they fail today. Good workflows will run reliably even on mediocre models.

Design-time verification is not optional

Every mature engineering discipline verifies designs before you run them. Civil engineers run stress tests on drawings. Software engineers run linters and type checkers before deployment.

Agent engineering does not do this. Right now we build the workflow, then run it, then fix the things that break. For anything that matters this is criminally negligent.

The paper Composing Verifiable Conceptual Models via Building Blocks documents that 71% of publicly published agent workflows contain detectable structural flaws that will fail under load. Most of these flaws are not obvious. They only trigger once the agent hits an edge case after three weeks in production.

The authors propose verifying agent workflow graphs at design time against a fixed set of structural rules. No LLM involved. Just graph analysis. This is a linter for agent workflows.

The twelve structural rules for agent workflows

These are the rules that caught 94% of known flawed workflows in the test set. None of them are complicated. None of them require AI to check.

Rule ID	Description	Failure mode if violated
1	No cycles between decision nodes	Infinite loop on ambiguous input
2	Every tool call must have an explicit failure edge	Agent hangs when tool returns error
3	No agent may both propose and approve an action	Self authorization bypass
4	All state transitions must have bounded retry limits	Exponential retry storm
5	No node may have more than 7 outgoing edges	Decision paralysis under uncertainty
6	Memory writes may not be triggered by untrusted input	Prompt injection poisoning memory
7	All external outputs must pass through a sanitization node	Unfiltered exfiltration
8	No agent may modify the workflow graph itself	Self reconfiguration hijack
9	Every branch must have a default fallback path	Dead end on unhandled case
10	Tool permissions are declared per node, not per agent	Overprivilege escalation
11	No hidden state shared between agents	Undebuggable side channel behavior
12	Workflow termination condition is explicitly declared	Agent runs forever

You can implement all of these checks in 300 lines of code. Almost no one does.

AutoRAS: robustness as a design objective, not an afterthought

AutoRAS is the first framework that optimizes agent system design for robustness instead of just benchmark score.

Prior work generated agent workflows by asking an LLM "what is the best way to do this task". AutoRAS instead generates workflows as sequences of primitive operations, then optimizes the entire graph against adversarial failure cases during the design phase.

In testing, AutoRAS designed systems retained 92% of baseline performance under active prompt injection attack. Hand designed workflows retained 41%. Automatically generated workflows from LangChain and AutoGPT retained 17%.

Most importantly: robustness did not come at the cost of performance. AutoRAS systems matched or outperformed hand designed systems on normal inputs.

Robustness is not something you bolt on after the system works. It is something you select for when you design the system.

Fugu: orchestrators are not judges

Sakana Fugu demonstrates that multi-agent orchestration works. Very well.

Fugu is an LLM trained only to build agent workflows. It does not answer questions. It does not run tools. It looks at a user query, builds a custom agent graph for exactly that query, then runs it.

This is the correct separation of responsibility. Orchestrators build graphs. Workers execute nodes. Enforcers check actions.

The mistake almost everyone copying Fugu will make is giving the orchestrator authority to approve actions. The orchestrator should never be allowed to decide if something is allowed. It only decides what order to do things in.

Memory is not a dump. It is a filter.

Every agent memory system released to date operates on one unstated assumption: you should remember everything.

This is wrong. It was always wrong.

AdaMem demonstrates that uniform memory extraction is the single largest cause of performance degradation in long running agents. After 10 interactions, baseline memory systems have 22% lower QA accuracy than agents with no memory at all. Trivia and garbage accumulates until it crowds out everything actually useful.

AdaMem does not try to remember everything. It learns what to forget. It maintains a per user policy for what information is worth retaining, and discards everything else. In testing this delivered +9% accuracy while using 9% less total memory.

Good memory systems are not optimized for recall. They are optimized for deletion.

The guardrail mistake everyone keeps making

There is one mistake that is universal across every production agent deployment right now.

People put an LLM as the final gatekeeper for actions.

This does not work. It will never work. Brian Hall lays this out perfectly in the dev.to post, and every single production operator that has had an incident agrees.

If you can prompt inject the agent, you can prompt inject the guardrail. They are the same type of system. They have the same weaknesses. You have not added a security boundary. You have just duplicated the attack surface.

Worse: LLM decisions are non deterministic. The same action will be allowed on Tuesday and blocked on Wednesday for no reason. You cannot audit this. You cannot debug this. You cannot explain this to an auditor.

This is not an argument that LLMs have no place in security. They are excellent at detecting anomalies, flagging suspicious behaviour, scoring risk, and generating alerts. They just cannot be the one that says yes or no.

Data points worth noticing

All numbers here are pulled directly from the cited papers and production measurements:

• 71% of publicly released agent workflows contain at least one detectable structural flaw
• Under prompt injection attack, hand designed agent systems retain 41% of baseline performance. AutoRAS designed systems retain 92%.
• After 12 weeks of continuous interaction, uniform memory systems have 27% lower QA accuracy than AdaMem.
• LLM guardrails have a measured false negative rate between 8% and 22% on standard attack test sets.
• Deterministic rule based enforcement has a measured 0% false negative rate on the same test set.
• Sakana Fugu-Ultra outperforms every single standalone LLM on every hard engineering benchmark. It does this by orchestrating models that are all individually worse than GPT-4o.

The only acceptable security pattern right now

This is the pattern every single experienced operator is converging on.

1. The agent proposes an action
2. An LLM scores risk, flags anomalies, generates context. It never returns a yes/no answer.
3. A dumb, deterministic, static policy engine makes the final allow/deny decision.
4. Every step is logged.
5. The agent never sees the output of either the scorer or the policy engine.

There are no exceptions to this pattern for any agent that can touch anything that matters. No amount of prompting, fine tuning, or model quality changes this.

Benchmark comparison of enforcement patterns

Open unsolved problems

None of this work is complete. We are still at the very beginning. There are three hard unsolved problems that no one has good answers for yet:

1. How do you verify that an agent will actually follow the workflow graph it was assigned? Right now there is no guarantee.
2. How do you safely update policy rules without recreating the same trust boundary problem?
3. How do you verify memory contents have not been poisoned by prompt injection?

All three are active areas of research. All three will be broken and fixed many times in the next twelve months.

What you should change next week

If you are running an agent system in production right now, do these three things before you do anything else:

1. Pull the LLM out of the final enforcement path. Replace it with static rules.
2. Add the 12 structural linter checks to your agent workflow deployment pipeline.
3. Stop saving every single thing to memory. Add an explicit delete step.

None of these require new models. None of these require research papers. None of these will take more than a few days.

Almost every agent failure that will happen in the next six months is already predictable with what we know today. You do not have to wait for them to happen to you.