Enterprise AI Anti-Patterns | AetherStaff
AAetherStaff
Enterprise Agent Engineering · Anti-Pattern Catalog
Chapter 10 · Anti-Patterns

Enterprise AI Anti-Patterns

Common design shortcuts that appear reasonable in prototypes but create security, reliability, cost, governance, and scalability failures in production.

Anti-patterns are recurring architectural choices that hide complexity, delay control, or trade short-term delivery speed for long-term fragility.

10.1 How to use this catalog

Review every anti-pattern against the current system, not only the target architecture. A platform may have a secure gateway while one connector still uses shared credentials, or a formal governance process while one business unit runs unregistered agents.

Reference basis: this catalog synthesizes official guidance from Microsoft’s cloud antipattern catalog, AWS production generative-AI guidance, OWASP’s LLM risk taxonomy, and NIST’s AI risk-management framework.

ArchitectureHigh impact

10.2 The monolithic agent

One component handles prompts, retrieval, planning, memory, tools, policy, workflow state, and output rendering.

Typical symptom. A small prompt or tool change alters unrelated use cases, and the team cannot isolate the regression.
Why it emerges

Agent frameworks make it easy to place all logic inside one loop.

Production consequence

Brittle releases, broad blast radius, weak testability, and unclear ownership.

Replace with: modular orchestration, separate context services, durable workflow state, a capability gateway, and independent policy enforcement.
SecurityOWASP-aligned

10.3 Prompt-only security

The system prompt tells the model not to reveal data, exceed permissions, or follow malicious instructions, but no deterministic service enforces those rules.

Typical symptom. Requirements such as “never access another tenant” exist only in natural language.
Why it emerges

Prompt edits are faster than IAM, policy, connector, and workflow integration.

Production consequence

Prompt injection, inconsistent enforcement, and weak audit evidence.

Replace with: identity claims, policy-as-code, scoped credentials, schema validation, egress control, and structured approval.
AgencyCritical

10.4 Unlimited agency

The agent has excessive functionality, permissions, or autonomy and can expand scope without a bounded resource or action budget.

Typical symptom. The agent can “do anything needed” using broad database, HTTP, file, shell, or administrative tools.
Why it emerges

Broad tools make demonstrations flexible.

Production consequence

Unexpected side effects, excessive agency, and difficult incident containment.

Replace with: task-scoped capabilities, maximum steps, action budgets, resource binding, approval, and emergency suspension.
DataPerformance

10.5 Context dumping

The system sends entire repositories, long histories, or all retrieved documents to the model “just in case.”

Typical symptom. Context size grows with every feature while latency, cost, confusion, and disclosure risk increase.
Why it emerges

Large context windows create the illusion that retrieval discipline is unnecessary.

Production consequence

Extraneous fetching, stale evidence, higher cost, and sensitive-data leakage.

Replace with: permission-aware retrieval, context budgets, ranking, compression, provenance, and source manifests.
IntegrationCritical

10.6 Raw tools presented as business capabilities

The model receives arbitrary SQL, shell execution, generic HTTP, broad file access, or low-level administrative APIs.

Typical symptom. The tool description says what the model should do, but the tool accepts broad targets and parameters.
Why it emerges

Raw primitives avoid the work of building domain adapters.

Production consequence

Privilege escalation, SSRF, code execution, data exfiltration, and target-system instability.

Replace with: versioned business capabilities, anti-corruption adapters, destination-specific connectors, and post-condition verification.
WorkflowReliability

10.7 Conversation history as workflow state

The model conversation becomes the record of completed steps, approvals, retries, and enterprise operations.

Typical symptom. The system cannot say definitively whether an operation committed or which approval version applied.
Why it emerges

Conversation memory appears to provide state for free.

Production consequence

Duplicate actions, lost approvals, unreliable recovery, and weak audit evidence.

Replace with: durable workflow state, operation IDs, idempotency keys, event history, and explicit state transitions.
PerformanceDistributed systems

10.8 Synchronous everything

Long model calls, retrieval, tool sequences, and approvals remain behind one blocking request.

Typical symptom. Timeouts are increased repeatedly instead of changing the interaction pattern.
Why it emerges

Synchronous APIs are easy to prototype.

Production consequence

Thread exhaustion, poor UX, unknown transaction state, and cascading failure.

Replace with: asynchronous request-reply, queues, durable workflows, progress states, and cancellation.
ReliabilityHigh impact

10.9 Blind retries and retry storms

Each layer retries independently, or the agent repeats a write because it did not receive a response.

Typical symptom. Gateway, SDK, orchestrator, connector, and worker all have separate retry defaults.
Why it emerges

Retries appear to improve resilience.

Production consequence

Retry storms, duplicate side effects, quota exhaustion, and extended outages.

Replace with: coordinated retry policy, exponential backoff, circuit breakers, idempotency, and reconciliation.
Multi-tenancyData security

10.10 Shared memory, cache, or index without isolation

Responses, embeddings, conversation memory, or evidence are reused across users or tenants without incorporating access and policy into the key.

Typical symptom. Cache keys include prompt text but omit tenant, user scope, policy, model, or source version.
Why it emerges

Shared caches improve cost and latency in testing.

Production consequence

Cross-user leakage, stale authorization, and inconsistent evidence.

Replace with: partitioned memory and indexes, policy-aware cache keys, expiry, and deletion propagation.
QualityGovernance

10.11 No evaluation system

Teams test a handful of prompts manually and deploy when responses “look good.”

Typical symptom. Quality is discussed through anecdotes and screenshots rather than a versioned evaluation suite.
Why it emerges

Manual review is fast during early development.

Production consequence

Silent regressions, unverifiable improvement, and unsafe tool behavior.

Replace with: curated and adversarial cases, system-level evaluation, canaries, business outcome metrics, and incident-derived regression tests.
Operating modelEnterprise risk

10.12 Shadow AI by prohibition

The organization bans external AI but provides no usable approved alternative or onboarding path.

Typical symptom. Policy says “do not use AI with company data,” while employees face strong productivity pressure.
Why it emerges

Prohibition is easier than enablement and governance.

Production consequence

Untracked disclosure, unmanaged accounts, inconsistent quality, and no incident evidence.

Replace with: a sanctioned platform, clear data rules, rapid use-case onboarding, training, and monitoring.
ValueManagement

10.13 Vanity metrics as business evidence

The program reports prompts, tokens, generated words, licenses, or registered agents without linking them to cycle time, quality, risk, revenue, or cost.

Typical symptom. Adoption is rising, but the organization cannot identify which workflows improved.
Why it emerges

Usage data is easy to collect.

Production consequence

Resources flow to popular demos rather than measurable value.

Replace with: completion rate, cycle time, verified outcomes, correction rate, escalation burden, risk events, and cost per successful outcome.
PlatformPortability

10.14 Model provider as the enterprise architecture

Identity, workflow state, tools, memory, evaluation, and business logic are tightly bound to one provider-specific runtime.

Typical symptom. Replacing the model requires rewriting authorization, connectors, and workflow behavior.
Why it emerges

Provider frameworks accelerate early delivery.

Production consequence

Lock-in, difficult fallback, and limited lifecycle control.

Replace with: stable enterprise contracts for identity, capabilities, context, state, and traces; isolate provider-specific logic behind adapters.
OperationsDistributed systems

10.15 “We will add observability later”

The team logs only final answers or application errors. Retrieval, model routes, policy decisions, tools, approvals, and post-conditions are invisible.

Typical symptom. A wrong action is reported, but the team cannot reconstruct the evidence, model, policy, or connector path.
Why it emerges

Telemetry is treated as pilot overhead.

Production consequence

Slow incident response, unverifiable quality, weak audit, and unowned cost.

Replace with: distributed traces from ingress to outcome, structured redaction, cost attribution, security telemetry, and immutable action evidence.
GovernanceLifecycle

10.16 Governance after launch

Ownership, data classification, model approval, access review, incident response, and retirement are deferred until the use case proves value.

Typical symptom. The pilot becomes business-critical before anyone owns the agent, permissions, evaluation suite, or recovery process.
Why it emerges

Governance is seen as a gate that slows experimentation.

Production consequence

Orphaned agents, uncontrolled changes, unknown residual risk, and difficult shutdown.

Replace with: risk-tiered governance from inception, named owners, registries, release gates, review dates, and retirement procedures.

10.17 Anti-pattern detection matrix

SignalLikely anti-patternReview question
One service owns prompts, retrieval, tools, memory, and policyMonolithic agentCan one component change without retesting the whole system?
Security rules appear mainly in promptsPrompt-only securityWhich deterministic service enforces each rule?
Agent has generic SQL, HTTP, shell, or file toolsUnlimited agencyWhy is a narrow capability insufficient?
Client timeout leads to repeated writeBlind retryHow is unknown transaction state reconciled?
Cache key omits tenant or policyShared memoryCan users receive data generated under different access?
Release approval relies on screenshotsNo evaluationsWhich tests prevent regression?
Program KPI is prompt volumeVanity metricsWhich business outcome improved?
No trace links source, model, tool, and outcomeObservability laterCan an incident be reconstructed end to end?

10.18 Architecture review checklist

Reasoning, state, policy, connectors, and evidence are separated.
Every security requirement has deterministic enforcement.
Agents receive only task-specific capabilities and resource scope.
Context is permission-filtered, ranked, versioned, and freshness-aware.
Raw administrative primitives are removed or isolated.
Workflow state survives restart and model replacement.
Long-running work uses asynchronous or durable workflows.
Retries are coordinated, bounded, and idempotent.
Cache design includes tenant, policy, model, and source version.
Every release is protected by repeatable evaluation.
Employees have a usable sanctioned AI platform.
Metrics measure outcomes rather than activity alone.
Provider-specific components sit behind stable contracts.
Distributed traces connect intent to verified outcome.
Agents, capabilities, models, and sources have owners.
Recovery and retirement are designed before launch.

10.19 Chapter summary

Enterprise AI anti-patterns share a common structure: they hide a control decision inside a convenient component. Identity is hidden in the prompt. Workflow state is hidden in conversation memory. Business capability is hidden inside a raw API. Quality is hidden behind anecdotes. Governance is hidden behind the assumption that the pilot is temporary.

The corrective architecture makes identity, policy, context, state, capabilities, evaluation, observability, ownership, and recovery explicit and measurable.

Core conclusion: the fastest prototype architecture is rarely the fastest path to production.

Reference foundations

  1. Microsoft Azure Architecture Center — Performance testing and antipatterns.
  2. Microsoft Azure Architecture Center — Cloud design patterns.
  3. AWS Prescriptive Guidance — Architecting generative AI applications for production.
  4. OWASP GenAI Security Project — Excessive Agency.
  5. OWASP Top 10 for Large Language Model Applications.
  6. NIST AI RMF Generative AI Profile.
© 2026 AetherStaff. Enterprise Agent Engineering.
Vendor-neutral anti-pattern guidance for production enterprise AI.