6 Ways to Ruin a Perfectly Good AI Agent

We get it. Building AI agents is exciting and thanks to a budding ecosystem of low-code tools like Agentforce Builder, it’s never been easier to get started. Spinning up a working agent probably takes less time than your morning commute. But that ease of entry is a double-edged sword. As gratifying as it is to get an agent demo up and running in two hours, getting that same agent to work reliably in production, at scale, with real users and real-world problems is an entirely different challenge. 

Production is where seemingly minor architectural choices compound into dire reliability problems. These can often be hard to spot when building, but as more organizations adopt agentic AI, we’re seeing clear patterns emerge. 

This post explores 6 of the most common implementation missteps we’ve seen in live Agentforce deployments, and how to nip them in the bud. 

1. Instruction bloat 

The problem: One of the most common mistakes we see is cramming everything into the agent instructions—hundreds or even thousands of words trying to cover every possible scenario, edge case, and behavioral nuance. The intent is good: you want the agent to have all the context it needs. But in practice, this creates several problems:

• The agent can’t effectively parse or prioritize information 
• Token limits get consumed by instructions rather than runtime context
• It becomes nearly impossible to maintain or update the agent as requirements change
• Performance degrades as the agent struggles to identify what’s relevant

What to do about it: Be ruthless about what goes in the instructions. They should contain only the core behavioral guidance — the agent’s purpose, personality, and high-level decision-making principles. Everything else should be externalized:

1. Put detailed procedural knowledge in knowledge articles
2. Store data and records in Salesforce objects 
3. Use Actions to encapsulate complex business logic
4. Let the agent retrieve information dynamically rather than front-loading everything

Think of instructions like a job description: clear, focused, and concise. If you find yourself writing “If the customer says X, do Y, but if they say Z, do A,” you’re probably doing too much in the instructions.

It’s worth noting that Agentforce Builder’s addresses a meaningful subset of this problem. By separating the agent’s planning and execution steps, hybrid reasoning reduces the burden on instructions to anticipate every scenario — the agent can reason its way through novel situations rather than relying on exhaustive upfront guidance. That said, hybrid reasoning isn’t a substitute for good instruction hygiene. It helps with reasoning under uncertainty; it doesn’t compensate for poorly structured or bloated instructions that were always doing the wrong job.

2. Negative constraints 

The problem: Another tempting approach is to list everything the agent should not do: “Don’t answer questions about pricing. Don’t provide medical advice. Don’t make commitments on behalf of the company.” The list grows longer as you discover new edge cases during testing.
The problem runs deeper than just growing unwieldy. LLMs are trained to generate, not suppress — asking a model to “not do X” requires it to hold that constraint in the working context while simultaneously producing output, which is inherently less reliable than giving it a positive target to aim at. There’s also a subtler issue: negative constraints can draw the model’s attention toward exactly what you’re trying to avoid. It’s a bit like telling someone not to think about something specific.

This approach is problematic because:

• It’s impossible to anticipate every negative scenario
• Negative instructions can confuse the model or produce unexpected behavior
• It focuses on limitations rather than capabilities
• It creates a defensive posture that can make the agent less helpful

What to do about it: Focus on positive, affirmative instructions that define what the agent should do. Instead of “Don’t discuss pricing,” say “For pricing questions, collect the customer’s requirements and create a case for the sales team to follow up.”

Frame constraints as guardrails and scope boundaries:

1. “You help customers troubleshoot technical issues with our product”
2. “You answer questions using information from our knowledge base”
3. “You escalate to a human agent when a customer requests a refund”

This isn’t just about structure — it’s about how LLMs process language at the model level. Negative instructions like “don’t do X” are genuinely less reliable than affirmative patterns like “when X, do Y,” even in well-architected agents. While Agentforce Script allows users to define deterministic guardrails, positive instruction framing handles the probabilistic reasoning layer where natural language instructions live. The two approaches complement each other: AgentScript enforces boundaries, and positive framing guides the model’s decision-making within those boundaries. Both deserve explicit attention in your agent design.

3. Monolithic agents 

The problem: It’s tempting to build one powerful agent that can “do everything” — handle customer service, process orders, answer technical questions, manage returns, schedule appointments, and more. But while monolithic agents seem efficient at first, they quickly become unmanageable:

• Instructions become bloated and conflicting 
• It’s unclear which Actions and knowledge sources are relevant for which tasks
• Different teams can’t own or update their domains independently
• Performance and reliability suffer as complexity increases
• Testing and debugging become exponentially harder

What to do about it: Design focused, purpose-built agents with clear boundaries. Think about your organizational structure and customer journey:

1. A Service Agent that handles troubleshooting and technical questions
2. An Order Management Agent that tracks orders and processes changes
3. A Scheduling Agent that books appointments and manages calendar availability

These agents can hand off to each other when needed, creating a multi-agent system where each component is maintainable and testable. This also enables different teams to own and iterate on their respective agents independently. The key is finding the right level of granularity — not so broad that you have a monolith, but not so narrow that you have dozens of micro-agents that create coordination overhead.

4. Overprivileged agents and hidden data dependencies

The problem: One of the most critical implementation missteps we see is overprivileged agents, where builders give an agent access to more data than it needs “just to be safe.” The thinking is: “I’m not sure what data it might need, so let’s give it access to everything,” which is particularly common when builders aren’t deeply familiar with the Salesforce data model. 

Conversely, hidden data dependencies are an especially sneaky threat that can cause agents to pass testing but fail in production when they encounter inaccessible data. Here’s a real-world example: An agent built to manage case assignments worked perfectly in testing with access to the Case object. But in production, it failed because it needed to query case comments for context. Case comments live in a separate CaseComment object that requires its own permissions—something that wasn’t apparent until the agent hit real-world scenarios.

These issues lead to:

• Security risks from over-permissioning
• Silent failures when the agent can’t access needed data
• Debugging nightmares where the agent works for some users but not others
• Compliance and audit concerns

What to Do Instead: Take a methodical approach to agent permissions:

1. Start restrictive: Begin with minimal permissions and add only what’s needed
2. Map the data flow: Identify every object and field the agent will need, including related objects
3. Test with realistic personas: Use test users with production-like permission sets
4. Document dependencies: Keep a clear record of why each permission exists
5. Review related objects: For any object the agent uses, check if it has related objects (comments, attachments, history, custom relationships) that need separate access

When you encounter permission errors, resist the urge to grant broad access. Trace the specific need, grant the minimum required permission, and document why it’s needed.

5. Integrating flows and agents

The problem: Many organizations have invested heavily in Salesforce Flows — automations that handle everything from lead routing to approval processes to data updates. When building agents, it’s natural to want to leverage these existing Flows. But here’s where things get tricky.

Flows were designed for deterministic, rules-based automation. They follow predictable paths: if A, then B; if C, then D. When you connect an agent to a Flow, you’re introducing probabilistic elements into a system built around the assumption of predictability. 

Flows connected to agents can fail in ways that traditional Flows never would:

• The agent might pass unexpected input that the Flow wasn’t designed to handle
• Edge cases that never occurred with rules-based triggers suddenly appear with AI interpretation
• Error handling that worked for predictable inputs breaks with creative agent reasoning

Many flows have latent issues that never surfaced because they operated in controlled, predictable environments. When an agent starts interacting with them in more varied ways, these hidden problems become visible.

What to do about it: Treat flows connected to agents as critical integration points that need extra scrutiny:

1. Audit your flows: Before connecting an agent, review the Flow for error handling, input validation, and edge cases
2. Build defensive flows: Add validation and error handling that assumes inputs might be unexpected or malformed
3. Test extensively: Don’t just test the happy path — test with variations in phrasing, edge cases, and scenarios you didn’t anticipate
4. Monitor in production: Watch how the agent actually uses the Flow and iterate based on real behavior
5. Embrace the exposure: When agents reveal issues in Flows, view it as valuable discovery, not a failure

The goal isn’t to blame the Flow or the agent — it’s to recognize that combining deterministic and probabilistic systems requires extra care. This same principle applies to any integration: APIs, custom Apex, external systems. When AI is involved, assume less and test more.

6. Set it and forget it

The Problem: There’s a natural human tendency to think about AI projects like traditional software deployments: you build it, you test it, you launch it, and then you move on to the next project. The agent is “done.”

But agents are fundamentally different. They’re learning systems operating in dynamic environments with evolving user behavior and changing business needs. An agent that works perfectly at launch will drift over time as:

• User patterns and expectations change
• New edge cases emerge that weren’t in your testing
• Business processes and requirements evolve
• The underlying data and integrations shift

What to do about it: Build a culture and practice of continuous agent refinement:

1. Instrument everything: Use Agentforce’s built-in analytics and logging to understand how your agent is actually being used
2. Review conversations regularly: Don’t wait for complaints — proactively review agent interactions to identify patterns and issues
3. Create feedback loops: Make it easy for users to report problems or suggest improvements
4. Iterate in production: Treat the launch as the beginning of the learning process, not the end
5. Assign ownership: Designate someone responsible for monitoring and refining the agent over time

Agentforce’s Testing Center makes the “review regularly” principle actionable — label your test cases with expected topics, actions, and responses and you have a regression suite you can run after every change. Combined with Enhanced Event Logs capturing real production conversations, you get both a forward-looking test harness and a backward-looking diagnostic. One caveat: Testing Center currently works on single-turn interactions, so complex multi-turn flows still need manual testing to complement it.

Think of agent maintenance like gardening: it requires regular attention, pruning, and care. The best agent teams review performance weekly, make small adjustments monthly, and do deeper refinements quarterly.

Building with intention

These implementation missteps share a common thread: they emerge from underestimating what it takes to build agents that work reliably at scale. Low-code tools make it easy to build something quickly, but building something that works well requires intention, discipline, and ongoing care. 

The good news? Every one of these pitfalls is avoidable with the right approach:

• Keep instructions focused and leverage knowledge and Actions for details
• Frame guidance positively rather than listing prohibitions
• Design focused agents with clear boundaries rather than trying to do everything in one
• Be methodical about permissions and data access, understanding the full dependency chain
• Recognize that flows and integrations need extra scrutiny when connected to AI
• Treat launches as the beginning of refinement, not the end

As the Agentforce ecosystem matures, we’ll continue to learn and refine these patterns. The key is approaching agent development with humility — test thoroughly, monitor closely, and iterate continuously. The agents that succeed aren’t necessarily the ones built fastest; they’re the ones built with care and maintained with attention.