Introduction

The world of intelligent agents is rapidly transforming how businesses operate, promising a future of enhanced efficiency and personalized interactions. We’re currently in an exciting, yet exploratory phase. While most implementations are standalone or simple, single-topic agents, and agent-to-agent communication (like standards such as MCP and A2A) are just emerging, the industry is still establishing its dominant platforms, much like the early browser wars.

To truly unlock the power of agents, we must architect for a future where multiple agents work in concert, both with users and with each other. This means understanding the diverse internal architectures and terminologies that are evolving across different agent platforms.

The multi-agent future

The fundamental shift towards a multi-agent future necessitates a clear understanding of agent principles and thought into how they are architected so that they work together.

The true potential of agents will be realized when they move beyond isolated tasks to become interconnected members of a digital workforce. Imagine a future where a sales agent seamlessly hands off a complex customer query to a support agent, who then coordinates with a backend inventory agent to resolve the issue, all without human intervention. 

This requires robust communication protocols and shared understanding between disparate agents. Agents are different from other generative AI tools because they can plan, reason, and use tools with or without human intervention. They are dynamic and can adapt to different situations, environments, and information. 

Agents can also be autonomous, acting without human intervention, or can be guided to involve a human in the loop. Agents need to understand how and when to hand back to a human, but also be able to provide the context so the human can pick up where the agent left off.

Agent is a confusing term

The diverse landscape of agent platforms means we’re seeing different approaches and terminology for their internal structures. This is potential confusing, particular as to what an agent is. 

The agent from a user’s perspective is what they engage with. The agent could perform a range of tasks “Account Management Agent” or a single job “Summarize account, and create prioritized todos agent”.

So when we talk about multi-agent systems, we are referring to a narrowly scoped agent that delivers a Job To Be Done (JTBD) – “Summarize account, and create prioritized todos”, or “List accounts in order of renewal attrition risks and draft emails for top 5”. 

And based on the level of the agent, it will determine how it is architected. The broader the scope of the agent, the simpler it is easier for the user it is to deal with. The user doesn’t need to work out what they are trying to do. They just engage the agent, and then the agent then calls another agent to deliver the work. This is why there are agent-to-agent standards emerging like A2A and MCP.

Alternatively, if the agent is a smaller, tighter scope and delivers a task. They are easier to architect, but the user needs to know which agent to use.

Architecting Agentforce

Anatomy of an Agentforce Agent

Agents are what the user engages with. This could be inside Salesforce, through Slack, or externally-facing websites such as Experience Cloud. An Agent can have one or more Topics. These deliver the JTBD. A Topic has one or more actions, delivered through a Flow, Prompt Template, Apex, and API call.  Other action types are being added all the time. Topics also have instructions.

A critical architectural and design decision involves defining the scope of the Agent and the scope of the Topics within it. This choice impacts user experience and agent performance. 

The scope of the Agent is based on the user experience you want to deliver. The scope of a Topic is not negotiable. It is a JTBD. This means the scope of the Agent determines how many Topics are within it. The broader the scope of the Agent, the more Topics it has. Ultimately there is a limit to the number of Topics in an Agent as it will impact the performance. Agent reliability will also drop if there are overlapping Topics because the Agent won’t know which Topic to use.

Agentforce architecture

Agentforce is powerful as it can tap into Salesforce core data and metadata, but also data from 3rd party systems via Data Cloud. It can also access other agents via the A2A and access tools via MCP protocols. As you can see from the diagram below there are “a lot of moving parts”. Whilst this can seem overwhelming, you can start small with tight use cases. But you need to ensure that you consider the architecture for the multi-agent future. Which is the purpose of this document.

Establishing Agent Use Cases

Complexity vs risk

While many conversations around agents focus on appealing, high-profile, customer-facing examples, like Saks agent helping you return a sweater and swap for a different one. But these often come with huge deployment risks. Such scenarios are typically very complex, involving numerous moving parts and integrations with multiple data sources. And the risk to reputation of getting it wrong is high.

The smart approach is to pick low-deployment risk agents to start with. It’s important to understand that low deployment risk doesn’t necessarily mean low complexity. For instance, we’ve successfully deployed an internal 26-step, 6-action sales coach agent that is complex in its internal workings but carries low deployment risk.

Conversely, a seemingly low-complexity agent, like a customer-facing FAQ on pricing and licensing, can carry huge deployment risk. A simple error in pricing information, despite the agent’s basic function, could have significant negative consequences for brand reputation and trust.

We created an agent that was a “cocktail connoisseur” for a swanky Salesforce event in NYC. It was customer-facing, but a limited audience of those at the event. And was relatively low deployment risk because it was recommending cocktails. It took less than a day to design and deploy. And it was a great showcase for Agentforce. Win. Win. Win.

Here is a way of thinking about use case selection.

Where to start

Therefore, the ideal starting point is to pick use cases that are easy to implement, high-value, and low-deployment risk. A prime example? An employee FAQ for the expenses policy. This offers high internal value, reduces queries for HR, and has minimal external exposure, making it an excellent pilot for agent adoption. Agents are best when the environment or context can change dynamically, multiple decisions or branches are possible based on data, and AI needs to replace or assist human judgment in making a choice or taking action.

We have deployed an internally-facing agent with multiple topics and are seeing a huge uptake. But more importantly, it has shown the business what is possible and it has generated demand for agents across the business we’d not considered. We are strengthening our agent-building muscles.

Designing Agents and Topics

Topic is a JTBD within Agent

The scope of the Agent is determined by the user experience you want, as we’ve already discussed. Within an Agent, a Topic represents a Job To Be Done (JTBD). This means it has a clear starting point (user engagement) and a defined outcome. Think of it like “instructing a bright intern” – you give them a specific task with a clear objective. Topics are the foundation of your agent’s capabilities, defining what it can do and the types of requests it can handle. They have specific expertise, tools (Actions), and guidelines (Instructions).

Examples

• Bad (Too Broad): “Account Management.” This scope is far too wide. A Topic this broad would encompass a large number of actions and instructions, making it difficult for the Agent to perform reliably and incredibly challenging to debug. The ambiguity would lead to frequent errors.
• Good: “Evaluate account and create follow-up actions.” The instruction is precise: “For an account, review the open cases, the past sales, open opportunities, and most recent correspondence. Then create a summary and list of action points, and allocate them to the correct people.” This clearly defines the input and the expected output.
• Bad (Too Granular): “Create action.” This is too specific. If an Agent had to switch between multiple such granular Topics to complete the JTBD, the process would become slow and inefficient, and a poor user experience.

There’s no performance or cost benefit to having a very wide-scoped Topic that mimics an entire department rather than a specific JTBD. In fact, such broad scopes only introduce downsides, making the agent slower and less reliable. It also increases the risks when making changes because there is so much regression testing. It is like having a Flow with 100 nodes!!!

Think like an intern

When defining topics, always think like an intern, not a developer. “How would you instruct an intern to do the job?”

Consider a Legal Agent for a ISV that covers diverse use cases such as:

• HR-related legal queries
• Contract reviews for customers and partners
• Intellectual Property (IP) litigation
• Property contracts

A developer might look at this and say that they all start with a request and have a case, so they are essentially the same. This means each of these should be combined into one Topic.

While all these might start with an inbound inquiry and involve a case being raised and worked until closure, the specific steps and information required between inquiry and closure are vastly different for each. Therefore, they should be separate Topics. These Topics may share Actions, of have Actions that reuse metadata. Designing them as tightly focused Topics makes them easier to design, debug, and improve. Safer and faster.

AI Agents are NOT Magic Boxes, but Digital Employees

Before we trust AI agents with production work, we need to treat them like digital employees. That means:

• Clear job descriptions – what are they responsible for?
• Transparent training materials – how do they make decisions?
• Explicit performance safeguards – how do we ensure they don’t fail silently?

This clarity is non-negotiable in any high-performing team. The same applies to AI. Digital Employees NEED clear instructions. By using a process-led approach explicitly, architects can:

• Break down complex behaviors into understandable building blocks
• Separate reasoning steps (done by agents) from deterministic actions (performed by systems)
• Improve reliability by identifying logical flaws, ambiguous prompts, and missing safety checks
• Align stakeholders – business, developers, and AI engineers – around a shared visual contract.

With instruction diagrams, AI becomes interpretable, auditable, and a trustworthy blueprint, not a mysterious black box!

Structured design approach

Adopting a structured process approach to designing Agentforce agents, while it might initially seem to take longer for the initial build, will ultimately get you to deployment much faster. We are seeing 90% improvement than an iterative build approach. 

Agents isn’t about iterative building; it’s about a distinct design phase, followed by a build phase, with iteration reserved for fine-tuning. Don’t rush into the build. Resist the urge to open Agent Builder until you have thoroughly agreed upon and signed off on the design and architecture.

Architecting the Agent and Topics

There are a number of benefits of mapping the process out with stakeholders. Map out the Agent in an AIM (Agent Interaction Map). This shows the Agent and its Topics. Each Topic is a box and you can drill down to the Topic, which is an AID (Agent Instruction Diagram).

Since a Job To Be Done (JTBD) inherently represents a process, utilize a process diagram to visualize and think through the overall flow. This includes mapping out the necessary Actions, Instructions, Variables, and Filters, as well as identifying points where a handoff back to a human is required. 

The AID makes it very easy to visualize the overall flow. But you can see the “happy path” where it all works well, but can then add in the feedback loops. On the diagram there are 3 different color-code elements:

Agent Instruction Step Use this shape to define what the Agent is supposed to do using probabilistic reasoning. This represents the core “job to be done” where the Agent must interpret the user’s or system’s input, decide on intent, and act accordingly using large language models.

Agent Action: This shape represents actions that the agent should trigger. Currently an Action could call a Flow, Apex, Prompt Template, or API.  But over time this list will increase to enable the Agent to perform more complex tasks.

The diagrams are a design canvas. Drill-down form any box if you want to use a lower level diagram to design the Flow or Prompt Template. You can attach notes, documents or links to any activity box. You can drag sticky notes onto the diagram

Process diagram: trust and transparency

A well-crafted process diagram is invaluable, serving as both a critical design and governance document. Its benefits include:

• Engage business users & agree scope: It provides a clear visual representation that business stakeholders can understand and validate.
• Design topic: Actions vs. Instructions vs. Guardrails, Variables / Filters, and handoff back to human: It forces clarity in defining the agent’s capabilities and boundaries.
• Generates unambiguous, tight instructions: The diagram translates directly into tighter, less ambiguous Topic instructions with no gaps or conflicts.
• Debug during test / evaluation: A visual flow simplifies identifying where the Topic needs improving.
• Evaluate end-to-end scenarios: It generates scenarios of all the possible paths and outcomes.
• Demonstrate compliance & audit trail: Provides a clear record of the Topic’s intended behavior for regulatory and internal audits.
• Explain behavior & get sign-off: Helps articulate the Topic’s function to non-technical stakeholders and secure their approval.
• Agent platform agnostic: The principles of process diagramming apply regardless of the underlying agent platform.

Drawing the diagram (AID)

Use the Elements.cloud free Agent Designer to draw the diagram.  There are several reasons why Salesforce Professional Services recommends it use and why SIs and clients are using it:

• Hierarchical so supports AIM – AID – Flow/Prompt Template structure
• It automatically creates Instructions from the AID
• It builds a change log
• It coaches and suggests improvements
• You can link any box to supporting information and org metadata
• AI can generate User Stories for Actions
• Access controls; edit vs view rights
• Share, collaborate and comment on diagrams
• …..

There are several ways to create the diagram. Some are automated and generate the “happy path”. You then review this diagram, provide feedback, and add fault paths. From this refined diagram, you can then generate instructions and test scenarios, and even manage versioning, making the initial design phase remarkably efficient.

Business Analysis Agent

Our team has developed a Business Analysis Agent that significantly streamlines this design process. It can engage in a discussion with you, then automatically draw the first cut of the process diagram, focusing on the “happy path.” 

Configuration Mining

Configuration Mining generates a process diagram using metadata (objects, fields, automations, Apex, permissions etc etc) which explains how your org works. It then identifies opportunities to agentify. What would take months of manual effort is delivered in minutes.

AI generation from existing Topic

Take the Scope, Classification Description and Instructions from an existing Topic, and AI will interpret it and draw a diagram. The diagram will also have the suggested improvements. 

AI generation from sketch / screenshot  / image

Take any image: a handwritten sketch, a photo of a whiteboard, a Lucidchart or flowchart. AI will read it, interpret it and draw a diagram optimized for an agent. It is not a direct copy

AI generation from text

Take any textual input and AI will read it, interpret it and draw a diagram optimized for an agent. The text could come from any source: SoW, call transcript, SOP, or procedure.

Template

Start with pre-built templates of working Topics. 

Manual drawing and snippets

Simple drag and drop is fast enough to use in live workshops with stakeholders. Copy and paste agent snippets from their diagrams to construct like LEGO bricks.

Testing, and deploying Agent and Topics

Testing cycle

You evaluate the Topic within an agent. If you need to make changes because the Topics are not performing as expected.  This could be during the initial build phase or even when it is in production.

DO NOT change the instructions in Agent Builder. Instead go back to the diagram (AID) and make changes there and regenerate the instructions. There are several reasons why:

• It is quicker to highlight the issue looking at the diagram than reviewing lines of instructions
• Making changes to the diagram working with stakeholders is easier
• You can use the coach to check you are not introducing conflicts into the instructions
• The change log is updated, maintaining governance
• The instructions and test utterances are regenerated automatically
• It is easier to sign off the changes with stakeholders

Deployment

The deployment lifecycle for agents, or at least their underlying Topics, will iterate quickly both during development and once in production. A tight, governed implementation lifecycle is absolutely essential to manage this velocity and stay in control.

• You can version an Agent in Production or in a Sandbox environment inside Agent Builder. While helpful, there’s currently a limit of 20 versions. You can activate any available version. This versioning control is managed within Agent Builder.
• The ability to push an Agent and all its associated metadata (Topics, Actions, and Instructions) from a Sandbox into Production streamlines the deployment process. A clear understanding of how this impacts existing versions in production is crucial for consistent deployments.

When you version the Agent, you can also version the diagrams. This is a more detailed level of governance than the change log. ThHis is not included in the free Elements.cloud Agent Designer.

Agentforce Governance

Effective governance is paramount for building reliable and scalable Agents.. The rapid iteration of Agents, especially Topics, through development and production demands a disciplined implementation lifecycle.

Metadata reuse

Maximizing metadata reuse is key to efficiency and consistency in agent development. 

• Standard Topics are available to use. You should copy a Standard Topic to create a Custom Topic to ensure it meets your needs and you can iterate it quickly.
• Standard Actions can be reused across multiple Topics, promoting consistency and reducing redundant development. But you need to be sure that they support the use case 100%. You cannot currently use a Standard Action as the basis of a Custom Action.
• The reusability of Actions across Topics needs to be clearly documented and managed to avoid issues when changes are made. 
• Crucially, foundational metadata such as Flows, Apex code, and Prompt Templates can be reused across Actions. This allows core business logic and data interactions to be consistently applied wherever needed. For example, a Prompt Template can be used as an agent action to invoke an LLM to generate a response, using RAG. Flow can be used for low-code rules-based automation and record retrieval, and Apex code for pro-code rules-based automation and record retrieval. Mulesoft API and External Service can retrieve data from legacy systems and external applications.

Metadata dependencies

Documentation and tracking the impact of changes become even more critical with agents, primarily because failures might not always be immediately apparent. The interwoven nature of agent components means a change in one place can ripple through seemingly unrelated parts of your system.

As you can see from the image above, you can quickly have dependencies.  And these are only between and across agents.  But Flow-1 migh be used in Salesforce and is called independently when a picklist value changes elsewhere in the system.

If that Flow is modified because the business requires different behavior when that picklist value changes, it will inadvertently alter the behavior of both Topic-1 and Topic-2. The agent might behave unexpectedly, or it might simply “work around” the Flow. If the agent is customer-facing, the customer might not say anything or even realize that something is wrong. This silent failure can erode trust and lead to unaddressed issues.

This simple example will very rapidly become complex as more and more Agents are deployed. It is a well-understood issue currently in Salesforce orgs. This is why Elements.cloud has powerful metadata dictionary and dependency capabilities that cover Agentforce Data Cloud, Indusry Couds and the core Salesforce platform.

Metadata dictionary

You need a robust metadata dictionary that actively tracks Agentforce dependencies and all their downstream impacts. This includes understanding how an Action calls a Flow (which might call other Flows and use specific data) and how an Action calls a Prompt Template (which might use data from a platform object or a Data Cloud DMO).

The impact assessment must be bidirectional:

• If I change this metadata (Flow, Field), what uses it and is impacted?
• If I change this Agent, what metadata do I need to consider?

Documentation

Ultimately, agents will be able to read metadata documentation to build and improve themselves autonomously. This means good documentation of objects/fields for data and Flow, Apex, and Prompt Templates for actions will be non-negotiable. 

Elements. cloud is now able to draw process diagrams that describe how your org works. It is called Configuration Mining. It analyzes the 1,000s of metadata items and their dependencies. 

When you’re building Prompt Templates, it’s vital to know you’re accessing the correct fields. WIth many implementations having 100s of fields on an object where the field names are similar it makes it difficult to be sure that the correct data is being accessed. Without good documentation, it is hard to verify the data source and its exact meaning without additional documentation. This highlights the urgent need for comprehensive, easily accessible metadata documentation.

The final word

Agentic AI, while immensely powerful, introduces a new layer of complexity to system building. They demand strong architectural and design skills and rely heavily on robust data governance, as agents often pull information from multiple systems. Furthermore, for agents to perform reliably, they require well-documented and deeply understood business processes and the underlying metadata. The choice of Topic scope is absolutely critical, and the Topic Classification Description, Scope, Instructions, and Action instructions must be meticulously crafted to eliminate any ambiguity. You’re essentially programming a complex application using natural language.

Done well, agents can be hugely powerful, delivering a staggering positive return on investment. However, poorly architected and designed agents can have a devastating impact on your brand, trust, and reputation.

Are you ready to embrace a structured approach to building your next-generation intelligent agents?

Photo by Igor Omilaev on Unsplash