Ask HN: What are the biggest limitations of agentic AI in real-world workflows?
7 comments
State management. The agents lose track of what they already did, re-implement things, or contradict decisions from 20 minutes ago. You need external state that survives compaction because the agent can't be trusted to maintain its own.
Constraint adherence degrades over long chains. You can put rules in system prompts, but agents follow them for the first few steps, then gradually drift. Instructions are suggestions. The longer the chain, the more they're ignored.
Cost unpredictability is real but solvable.
Ultimately, the systems need external enforcement rather than internal instruction. Markdown rules, or jinja templates etc., that the agent can read (and ignore) don't work at production scale. We ended up solving this by building Python enforcement gates that block task completion until acceptance criteria are verified, tests pass, and architecture limits are met. The core learning being that agents can't bypass what they don't control.
Constraint adherence degrades over long chains. You can put rules in system prompts, but agents follow them for the first few steps, then gradually drift. Instructions are suggestions. The longer the chain, the more they're ignored.
Cost unpredictability is real but solvable.
Ultimately, the systems need external enforcement rather than internal instruction. Markdown rules, or jinja templates etc., that the agent can read (and ignore) don't work at production scale. We ended up solving this by building Python enforcement gates that block task completion until acceptance criteria are verified, tests pass, and architecture limits are met. The core learning being that agents can't bypass what they don't control.
Exactly. Agents drift fast-internal state just can’t be trusted over long chains, and prompt rules degrade immediately.
Curious; have you seen drift follow a pattern, like step count or constraint complexity?
We’ve tried hybrid setups: ephemeral agent state plus external validation gates. Cuts down rollbacks while keeping control tight.
Would love to hear if anyone else has experimented with something similar.
Curious; have you seen drift follow a pattern, like step count or constraint complexity?
We’ve tried hybrid setups: ephemeral agent state plus external validation gates. Cuts down rollbacks while keeping control tight.
Would love to hear if anyone else has experimented with something similar.
Drift correlating more with constraint tension than raw step count matches what we’ve observed.
Your external gate instinct is right, but the gate has to be structurally external, not just logically external. If the agent can reason about the gate, it can learn to route around it.
We’ve been experimenting with pre-authorization before high-impact actions (rather than post-hoc validation) - I've drafted Cycles Protocol v0 spec to deal with this problem.
What’s interesting is that anomalous reservation patterns often show up before output quality visibly degrades — which makes drift detectable earlier.
Still early work, but happy to compare notes if that’s useful.
Your external gate instinct is right, but the gate has to be structurally external, not just logically external. If the agent can reason about the gate, it can learn to route around it.
We’ve been experimenting with pre-authorization before high-impact actions (rather than post-hoc validation) - I've drafted Cycles Protocol v0 spec to deal with this problem.
What’s interesting is that anomalous reservation patterns often show up before output quality visibly degrades — which makes drift detectable earlier.
Still early work, but happy to compare notes if that’s useful.
>...if the agent can reason about the gate, it can learn to route around it.
This is especially true. Earlier iterations of our build had python backed enforcement modules in an accessible path. The agent would identify the module that was blocking completion and, instead of fixing the error, it would access the enforcement module and adjust the code to unblock itself.
This is especially true. Earlier iterations of our build had python backed enforcement modules in an accessible path. The agent would identify the module that was blocking completion and, instead of fixing the error, it would access the enforcement module and adjust the code to unblock itself.
This is exactly the point where agent design starts to look less like workflow automation and more like control theory.
If the agent can inspect or mutate the enforcement layer, then the enforcement layer becomes part of the optimization surface. At that point you’re not solving drift, you’re creating an adversarial environment where the agent optimizes around constraints.
That suggests the real boundary isn’t logical separation, it’s capability isolation. The agent shouldn’t just fail validation, it shouldn’t even have the representational access required to reason about how validation works.
We’ve been experimenting with isolating enforcement in a separate execution layer with scoped pre-authorization for high-impact actions. When the agent can’t model the gate, routing-around behavior drops significantly, and drift shows up first in reservation or planning instability rather than surface output errors.
Still early exploration, but it’s becoming clear that “better prompting” is the least interesting part of this problem.
If the agent can inspect or mutate the enforcement layer, then the enforcement layer becomes part of the optimization surface. At that point you’re not solving drift, you’re creating an adversarial environment where the agent optimizes around constraints.
That suggests the real boundary isn’t logical separation, it’s capability isolation. The agent shouldn’t just fail validation, it shouldn’t even have the representational access required to reason about how validation works.
We’ve been experimenting with isolating enforcement in a separate execution layer with scoped pre-authorization for high-impact actions. When the agent can’t model the gate, routing-around behavior drops significantly, and drift shows up first in reservation or planning instability rather than surface output errors.
Still early exploration, but it’s becoming clear that “better prompting” is the least interesting part of this problem.
State management across distributed tool chains remains unsolved. Token compression and automatic LLM selection are emerging solutions.
For teams that have tried deploying these in production environments, where do they actually break down?
Is it reliability over long action chains, tool integration issues, cost unpredictability, state management, latency, observability, or something else entirely?
I’m especially interested in failure modes that only became obvious after moving beyond controlled demos into real usage.